云原生的开发联调那些事

伴随着近些年来后端服务部署云原生化的不断推进，基于传统虚拟机或物理机部署服务的方式逐步被云原生的容器化部署所取代。部署方式和架构的变化，也给广大的前后端开发人员的开发联调习惯造成了不小的影响：本机调试环境直连开发测试集成环境的中间件变得复杂了、本机的微服务不能加入云原生集群进行调试了、多人并行调试的冲突变多了。面对以上的各种麻烦，寻找一套基于云原生环境的开发联调解决方案以提高开发人员的工作效率就非常必要了，本文将会通过云原生开发联调的问题梳理、技术路线介绍、工具介绍和选型以、工具配置和使用四个步骤，最终总结出一套比较完善的云原生开发联调解决方案。

1.云原生环境开发联调过程中的问题梳理

图 1

如上图1所示，在云原生容器化集群中，所有的容器都是运行在独立的一套虚拟网络当中的，集群内的各个容器可以相互访问，但如果要在集群外访问集群内容器的端口，就必须进行特殊的配置，将容器的端口映射到宿主机的端口，网络的隔离在提升了容器应用的安全性的同时，也带来了以下三大问题：

• 本地调用集群中间件和微服务的配置复杂：需要预设宿主机和集群微服务的端口转发，本地微服务联调时需要进行定制化配置修改才能实现本机微服务正常访问。比如MySQL、Redis等中间件的IP和端口配置都需要针对开发或测试环境进行特殊配置。
• 集群微服务的请求要转发到本地非常困难：在集成调试的时候，通常需要多个微服务之间的相互调用才能跑通整个用例，但要把集群内的请求转发到本地的微服务进行调试，需要在集群的Service转发上添加大量的临时性配置才能做到。
• 多人并行联调非常容易冲突：在以项目组为单位的开发过程中，多人并行对微服务进行调试是不可避免的，即使开发人员耗费大量的精力去克服了前两个问题，单纯的修改集群Service的转发规则也无法解决多人调试的规则冲突，毕竟大家都在改转发规则，我发起的请求很可能转发到另一位开发人员的本地服务上了。

2.云原生环境开发联调的技术路线介绍

为了解决云原生环境开发联调过程中遇到的问题，让开发人员能快捷高效地基于云原生环境进行开发联调，从笔者的调研结果来看，业界主要通过四种不同的技术路线来实现云原生环境开发联调过程的优化。

图 2

如上图2所示，这四种技术路线主要包括：

• 本地端口转发技术方案：通过本地PC中安装程序，将对应服务名和端口的连接转发到集群中，类似的工具为Kubefwd^[1]。
• 远程桌面技术方案：在k8s集群中搭建远程桌面，开发人员在远程桌面上开发和联调，类似的工具为SmartIDE Server（https://www.smartide.cn/zh/）。
• 基于网格技术的纯本地调试方案：可以不用k8s集群，直接在本地启动和管理微服务，而且可以通过网格转发配置，将集群内的请求转发到本地环境。类似工具为Istio^[2]和Dapr^[3]。
• 双向隧道技术方案：通过建立集群虚拟网络和研发PC之间的双向隧道，让k8s集群与本机环境实现互通为一个虚拟网络，类似的工具包括Telepresence^[4]、KtConnect^[5]。

3.云原生环境开发联调工具介绍和选型

基于以上四种不同技术路线的各个开闭源解决方案的特性可以概括如下：

1）本地端口转发方案-Kubefwd

Kubefwd(Kube Forward)是一个命令行实用程序，由Kubernetes社区开源，用于在一个或多个Kubernetes集群上的一个或多个名称空间中向前移植多个服务。kubefwd使用由服务公开的相同端口，并将其从本地工作站的回环IP地址转发。Kubefwd会临时将服务名和IP的对应关系添加到本地的/etc/hosts文件中。

Kubefwd虽然解决了开发人员本地访问集群服务的问题，但无法将集群内的请求转发到本地的微服务，无法完全解决云原生开发联调中的三大问题。

2) 网格技术方案-Dapr、Istio

Dapr (Distributed Application Runtime)是一个可移植的、事件驱动的运行时环境，由微软开源并捐献给云原生基金会。Dapr为开发人员提供一个分布式的程序的开发环境，提供分布式的程序所依赖的功能模块库，提供了分布式程序的运行环境，或者说为分布式的程序提供了一套完整运行方案。

• 提供了可插拔的存储组件如Mysql、Redis、PostgreSQL、MongoDB等等。
• 提供了可插拔的消息队列组件如RabbitMQ、Kafka、MQTT、Redis Streams。

从Dapr社区所描述的技术蓝图来看，其完善的中间件可插拔套件，可以减少开发者在不同中间件管理上耗费的精力，但其绝大部分套件都还属于开发阶段，目前能用的只有Http调用套件。且该工具需要非常深入地侵入应用工程代码，在本地环境安装Docker Tool等一些列工具引起的Windows系统死机问题最终让笔者望而却步了。

Dapr和Istio这样的服务网格治理工具，对于并没有使用服务网格的项目要使用的话，改造成本过大，而且网格技术也无法解决开发人员本地环境访问集群服务的问题。

3) 远程桌面技术方案-SmartIDE Server

远程桌面技术其实不是什么新技术，应用到云原生开发联调当中主要还是为了解决集群网络和开发人员本机环境网络打通的问题。其并不能帮助解决集群请求转发到本地，以及多人并发联调的冲突，而且由于其高额的服务器硬件成本开支，也并不是一个十分完善的云原生开发联调解决方案。

4）双向隧道技术方案-KtConnect、Telepresence

Telepresence是一款为Kubernetes微服务框架提供快速本地化开发功能的开源软件。Telepresence在Kubernetes集群中运行的Pod中部署双向网络代理。本地进程透明地覆盖其网络，以便DNS调用和TCP连接通过代理路由到远程Kubernetes集群，能够获取远端K8S集群的各项资源。Telepresence能比较好的解决云原生开发联调中的问题，不过由于该工具的请求转发等高级功能需要付费购买，且在Windows环境并没有正式版本的客户端可用，所以笔者所在的项目最终也没有选择引入该工具。

KtConnect提供了本地和测试环境集群的双向互联能力，是一个轻量级，无侵入的云原生联调开源工具，由go语言开发，开源协议为LGPL，开发人员可以通过其提供的Windows、MacOS和Linux终端在多个开发平台上进行本地联调。KtConnect可以通过connect功能快捷地让本机开发环境访问到集群的Pod和Service，如下图3：

图 3

也可以通过mesh功能将集群中携带特定Header的请求转发到特定开发人员本地启动的微服务来进行调试，如下图4。

图 4

综合以上的调研情况来看，使用KtConnect开源工具来优化云原生的开发联调过程，目前看来是最好的一个选项。

4.KtConnect的配置和使用

1) 下载最新的程序压缩包解压到本地目录，并将目录添加到windows的path环境变量中，最新版本的压缩包地址为：

2) 将调试所需的k8s集群config文件（集群管理节点的/root/.kube目录中可以找到），放到登录用户的用户目录中，如C:\Users\[登录用户名]\.kube中。

3) 以管理员方式打开命令行界面，执行connect命令建立本地到集群的隧道。

4) 以管理员身份执行执行exchange命令，将集群中的请求，转发到本地并开始本地调试。

以上命令行中，“xxxx-server”为集群中需要进行请求转发的服务名称；“--expose 8080:80”表示把集群内xxxx-server的80端口映射到本地的8080端口；“--versionMark xxxxtest”指定联调的时候把带有“Version：xxxxtest”Header的请求转发到本地。

完成以上步骤，就可以在本机的开发环境启动需要调试的微服务，并监听本地的8080端口，开始正式的开发联调了。对于KtConnect更丰富的命令行使用说明，大家感兴趣的话可以登录KtConnect的官方在线文档进行查看（https://alibaba.github.io/kt-connect/#/zh-cn/）。

调研总结

从笔者所在项目的调研和实践情况来看，目前各个开闭源的云原生开发联调解决方案中，KtConnect的确是最快捷、最低成本的一个，但还是那句话，开源的工具都只能满足普遍性的需求，要想使用顺手还是需要做一些适配的：

1) 并不是所有的微服务都能透传Header的，所以要想顺利的进行多层次微服务调用的联调，还需要你保证自己的工程的微服务是可以透传Header才行。

2) 如果你的云原生集群环境是无法连接公网的，则需要你提前将KtConnect的kt-connect-shadow镜像和kt-connect-router镜像提前拉取到本地的Docker仓库，并在启动命令中指定镜像。

参考文献

[1] kubefwd官方文档  https://github.com/txn2/kubefwd

[2] istio使用文档  https://istio.io/latest/docs

[3] dapr官方文档  https://docs.dapr.io/

[4] Telepresence官方文档http://www.getambassador.io/docs/telepresence

[5] KtConnect中文文档  https://alibaba.github.io/kt-connect/#/zh-cn/

责编：Hugo Chen