责任编辑为 CSDN 写手「弱蛛小义」（黄鑫鑫：百度云 CODING DevOps 研制技师、Nocalhost 工程项目的核心理念合作开发人员）的创作者该文，并依照译者在 CSDN 云原生植物 Meetup 深圳站的演说文本展开了重新整理，主要就撷取 Nocalhost 在化解云原生植物合作开发难题上的路子和积极探索，并展现 Nocalhost 为云原生植物合作开发增添的崭新新体验。
云原生植物情景下的合作开发关键点
当他们的应用领域构架从现代应用领域过渡到云原生植物应用的这时候，会辨认出应用领域构架的复杂程度大幅提高了，原本的现代应用领域模块少，布署单纯，他们常常能在邻近地区合作开发完两个现代应用领域后，把它丢到服务工程项目器上就能跑出来。而对云原生植物应用领域而言，应用领域被拆分为两个两个发射率更小的微服务，各服务工程项目间有著错综的亲密关系，进而让合作开发自然环境的构筑和服务工程项目的增容显得极度十分困难。
邻近地区布署 VS 软件产业布署
当他们要合作开发云原生植物微服务工程项目应用领域时，怎样将他们的合作开发自然环境构筑出来呢？常用的有三种形式：邻近地区布署和集群布署。
邻近地区布署是将整套微服务工程项目应用领域布署到邻近地区的合作开发电脑上，如下表所示图右图：
此种形式会增添下列两个难题：
1. 负面影响合作开发电脑的操控性。微服务工程项目应用领域常常体量较为大，数十亿几百上千个服务工程项目，都泡在他们的合作开发机内可能会让电脑显得很卡，负面影响工作效率。
2. 自然环境无法共享，资源浪费严重。当他们需要在邻近地区布署起整套体量较为大的微服务工程项目应用领域的这时候，就需要使用配置较高的合作开发电脑，并且每台合作开发电脑的合作开发自然环境只有两个合作开发人员能使用，即便该合作开发人员只需要合作开发其中两个或某两个服务工程项目，也无法将其它使用不到的服务工程项目共享给其它合作开发人员使用。
3. 对一些体量很大的微服务工程项目应用领域，邻近地区电脑可能还没有办法跑出来。
另外一种形式将微服务工程项目应用领域布署到云上的 K8s 软件产业里，如下表所示图右图：
此种布署形式能较好地提高资源利用率，但是它会让合作开发和增容应用领域时的反馈链路被大幅拉长。
他们合作开辨认出代应用领域时的工作流是：在邻近地区编写好代码 -> 把代码展开编译 -> 运行程序查看结果，如下表所示图右图：
这个过程常常很快，所以他们能在做完一次代码的小改动以后，就把它运行出来查看结果。
但是在合作开发 K8s 软件产业上的应用领域时，工作流变成了：修改代码 -> 编译程序 -> 将程序打包到 Docker 镜像 -> 将 Docker 镜像推送到镜像仓库 -> 修改软件产业中容器的镜像版本，等待 K8s 将新版本的镜像布署上去 -> 查看结果，如下表所示图右图：
这个流程可能需要耗时几分钟，当这个循环反馈被大幅拉长了以后，无疑会让合作开发的效率大幅降低。
目前主流的云原生植物合作开发形式
手动打包推送镜像
此种形式是最原始的形式，工作流大体如下表所示：
编写完代码以后，在邻近地区编译生成二进制文件或者 jar 包之类，然后通过 Dockerfile 构建出 Docker 镜像，再将镜像推送到 Docker 仓库，再通过修改工作负载的 yaml 定义中镜像版本，布署新版本容器的任务则交给 K8s 去做，只不过布署调度的过程可能有点漫长，需要等待 K8s 将新版本的 Pod 调度运行出来之后，他们才能看到代码修改的效果。如果代码改动得频繁，这个流程显然是非常繁琐的。
CI/CD 流水线
此种形式和第一种形式的流程大体上是一样的，只不过是通过 CI/CD 的能力，把手动的操作改成了自动化的流程：
此种形式的工作流是：在邻近地区修改完代码，把代码推送到代码仓库，进而触发代码仓库配置好的 CI 流程，把代码编译构建成应用领域程序（如二进制或 Jar 包），并打包成镜像，之后会触发所谓的持续交付（Continuous Delivery）机制，将镜像推送到制品仓库里，最后再触发持续布署（Continuous Delivery）流程，将新版本的容器调度布署到软件产业中。虽然使用 CI/CD 以后，能减少大部分手工操作环节，但整个流程花费的时间仍然很多，事实上，CI/CD 更适合在发布应用领域环节使用，而不是在合作开发应用领域环节。合作开发环节更注重的是能够快速得到反馈进而验证他们的想法，当他们的修改需要提交到代码仓，在 CI/CD 流水线跑完了以后才能看到效果，会限制他们使用单纯的尝试，来从几种方案中找出最优的一种，或者定位 bug 的原因。
流量转发
流量转发的路子是：将软件产业里访问合作开发中服务工程项目的流量转发到邻近地区。如下表所示图右图：
当需要合作开发 D 服务工程项目时，将软件产业中访问 D 服务工程项目的流量转发到邻近地区合作开发电脑上的某个端口上，在邻近地区写完代码以后，直接将应用领域程序在邻近地区跑出来即可。实现此种形式的相关产品有：kt-connect 和 telepresence。
在邻近地区直接运行应用领域程序固然能缩短循环反馈，提高合作开发效率，但此种形式也有两个很大的难题：许多运行在 K8s 软件产业上的服务工程项目会依赖其它 K8s 资源，例如依赖 ServiceAccount、ConfigMap、Secret、PVC 等等，这样的服务工程项目要在邻近地区跑出来并不太容易。
在容器里展开合作开发
此种形式的路子是：当他们要对某个服务工程项目进入合作开发时，先让要合作开发的服务工程项目进入合作开发模式，然后将代码同步到容器中，直接在容器中把合作开发中的代码运行出来：
此种形式同时化解了合作开发循环反馈过慢和服务工程项目依赖软件产业难题，是目前云原生植物合作开发中较好的实践，也是 Nocalhost 支持的主要就合作开发形式之一。
Nocalhost 初新体验
第三部分主要就是以 Demo 演示的形式来带大家新体验 Nocalhost 的特性，感兴趣的同学能前往深圳站 Meetup 视频回放，从 01:26:15 处开始观看。
（https://live.csdn.net/room/csdnnews/yCHrYqnM）
Nocalhost 核心理念机制
Nocalhost 是怎样实现在容器中展开应用领域程序的合作开发的呢？在两个服务工程项目进入合作开发模式时，Nocalhost 所做的核心理念工作有下列 4 个步骤。
缩减副本数
合作开发应用领域程序时，他们只需要在两个容器里运行正在合作开发中的应用领域程序，如果存在多个副本，他们通过 Service 访问该服务工程项目时，就无法控制流量只访问到他们正在合作开发中的应用领域程序所运行的那个副本，所以 Nocalhost 需要先将工作负载的副本数缩减为 1。
替换合作开发容器镜像
生产自然环境运行的容器常常会使用很轻量级的镜像，镜像里仅包含运行业务程序所必须的模块，而缺少编译构建业务程序所需的相关工具（如 JDK）。在对某个工作负载展开合作开发的这时候，Nocalhost 会将容器镜像替换成包含完整合作开发工具的合作开发镜像。
增加 SideCar 容器
为了将邻近地区的源代码改动同步到容器中，他们需要在容器里运行两个文件同步服务工程项目器。为了使文件同步服务工程项目器进程和业务进程解耦，Nocalhost 将文件同步服务工程项目器运行在两个独立的 sidecar 容器中，该容器与业务容器挂载相同的同步目录，因此，同步到 sidecar 容器中的源代码在业务容器中也能访问。
启动文件同步客户端
由于文件同步服务工程项目器监听在容器里的某个端口上，他们在邻近地区无法直接访问，所以 Nocalhost 会把两个邻近地区随机端口转发到容器里文件同步服务工程项目器监听的端口，打通文件同步服务工程项目器和客户端的网络，然后再启动邻近地区的文件同步客户端。文件同步客户端启动后会通过刚刚转发的邻近地区随机端口和文件同步服务工程项目器建立通信，之后便会开始展开文件的同步。
在以上步骤完成后，Nocalhost 会自动打开两个进入到远程容器的终端，通过该终端，他们就能把实时同步到容器里到源代码直接运行出来。
Nocalhost 高级特性
Duplicate 合作开发模式
Nocalhost 默认的合作开发模式是将软件产业中原本正常运行着的服务工程项目给替换成合作开发容器，如下表所示图：
此种形式存在下列难题：
1. 合作开发时会负面影响自然环境的使用。当对某个服务工程项目展开合作开发时，该服务工程项目在合作开发过程中可能会由于代码修改有难题导致极度甚至奔溃，软件产业里又有其他服务工程项目依赖该服务工程项目，进而负面影响到整个自然环境的使用。
2. 无法支持多人合作开发同两个服务工程项目。
为此，他们能使用Duplicate 合作开发模式，此种模式下，Nocalhost 不会对原有的服务工程项目做任何修改，而是复制出和两个原有服务工程项目一样的副本来展开合作开发，如下表所示图右图：
此种模式下，多人能对同两个服务工程项目展开合作开发，每个人都拥有他们的合作开发副本，软件产业原有的自然环境也不会受到任何负面影响。
Nocalhost Server
Nocalhost 除了通过 IDE 提供方便合作开发 K8s 应用领域的插件外，还提供了两个适合企业级合作开发自然环境管理的 Nocalhost Server，下列是 Nocalhost Server 的管理界面：
Nocalhost Server 能提供软件产业、应用领域、人员权限上的管理，关于 Nocalhost Server 的详细介绍，能参考官方文档上的介绍。
Mesh 模式
前面他们提到，如果要实现多人合作开发同两个服务工程项目，能使用 Duplicate合作开发模式，但此种形式也有两个局限性，就是只能在邻近地区通过 API 接口请求去访问合作开发中的副本，没办法通过应用领域的入口地址来访问。对需要通过统一的应用领域入口来访问合作开发中服务工程项目的情景，他们能使用 Nocalhost 的 Mesh 模式。
Mesh 模式会为每个人分配两个 MeshSpace，不同的 MeshSpace 通过在流量中带入不同的 Header 来控制从应用领域入口进来的流量的访问链路。
使用 Mesh 模式要求合作开发自然环境通过 Nocalhost Server管理，并且应用领域需要有 Header 透传和使用 Istio 展开流量转发的能力，关于 Mesh 模式的使用能参考官网文档 （文档目前还不是很完善，更详细的信息能直接通过 GitHub 联系 Nocalhost 的合作开发团队）。
