?云原生的開發聯調那些事

伴隨著近些年來后端服務部署云原生化的不斷推進，基于傳統虛擬機或物理機部署服務的方式逐步被云原生的容器化部署所取代。部署方式和架構的變化，也給廣大的前后端開發人員的開發聯調習慣造成了不小的影響：本機調試環境直連開發測試集成環境的中間件變得復雜了、本機的微服務不能加入云原生集群進行調試了、多人并行調試的沖突變多了。面對以上的各種麻煩，尋找一套基于云原生環境的開發聯調解決方案以提高開發人員的工作效率就非常必要了，本文將會通過云原生開發聯調的問題梳理、技術路線介紹、工具介紹和選型以、工具配置和使用四個步驟，最終總結出一套比較完善的云原生開發聯調解決方案。

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