這個雲原生開發的痛點你遇到了嗎？

作者：納海

端雲互聯最佳實踐：

https://help.aliyun.com/document_detail/200032.html

背景  

在雲原生時代，國内外衆多雲廠商釋放出強大的技術紅利，如何利用廉價、穩定且高效的雲設施是當今的一個主要命題。在雲上，我們可以很友善地建立虛拟網絡、虛拟機、資料庫、消息隊列等基礎設施和中間件，也可以使用容器服務、EDAS、SAE、函數計算等PaaS和Serverless服務來減輕應用管控的壓力。

但事情并不是一帆風順的。應用上雲已是曆史大潮不可阻擋，但随之而來開發者很快就體會到上雲的另一面：由雲上和雲下網絡不通所帶來的開發體驗割裂感。在上雲之前，開發者可以在本地完成代碼開發、測試、聯調等開發流程閉環；而上雲之後，資料庫、緩存、消息隊列和其他微服務應用都部署在雲上的虛拟網絡之中，我們再無法在本地完成開發流程。

如果是中東土豪，他可能會考慮使用實體專線來打通網絡。因為他隻需支付光纖鋪設費、樓内光纜租賃費、端口占用費、流量費等百萬量級的錢，同時說服安全團隊來允許完全打通環境而已。

如果是專業運維人員，他可能會考慮搭建VPN來打通網絡。當他花費精力搭建VPN伺服器，發現同僚們還是用不起來，紛紛抱怨：

• “一打開VPN，整個本地系統網絡流量都轉發到雲端了，其他事情幹不了啦！”
• “除了配置VPN，還要配置應用運作參數，太麻煩了！”
• “雲端服務怎麼調用不了本地服務，雲端網絡路由添加了嗎？”
• ...

看到這些問題，運維小哥内心也感到心累...

而現在，我們提供了一個開箱即用的插件工具，無需你花費大量的金錢或者人力。你所需要的隻是在IDE中一鍵開啟開關，然後通過IDE所啟動的應用就能通路到雲端環境裡的資料庫、MQ、緩存和其他微服務。所有的事情都由插件來幫你完成。

介紹

這款工具是我們自主研發的“端雲互聯”插件，“端”指的是開發端，“雲”指的是雲上網絡，通過某種方式實作“端”和“雲”的雙向互通，并且沒有傳統VPN的問題。

端雲互聯功能內建在Alibaba Cloud Toolkit（簡稱ACT）這個上雲工具産品中，并支援Intellij IDEA和Eclipse兩款IDE。你隻需在插件市場中搜尋“Alibaba Cloud Toolkit”進行安裝即可，例如在Intellij IDEA中搜尋如下：

我們在2018年就開始了端雲互聯項目的研發，這個過程中疊代了大大小小的版本，共經曆了三個裡程碑，至今有數十萬人次的使用。下面來介紹它的特性支援和實作原理。

端雲互聯1.0

1.0階段解決了本地和雲端雙向互聯的問題，使得本地服務不僅僅可通路雲端資源，還可以跟雲端服務互相通信。

雙向互聯

以下為端雲互聯的核心架構，整體分為兩個子產品：通道服務和代理機。

其中，子產品功能如下：

• 代理機：負責雲端的流量轉發。端雲互聯方案對代理機的要求很低，一台普通規格的ECS就可以充當“乞丐版”的代理機。并且，Debian、Ubuntu、Redhat等Linux系統已經包含端雲互聯所依賴的底層庫，無需額外安裝其他軟體。
• 通道服務：負責本地的流量轉發。當我們打開端雲互聯開關并啟動應用時，插件會在本地拉起一個通道服務程序。這個程序的職責非常簡單，它隻負責本地應用和雲端代理機之間的流量轉發，無其他操作。

通道服務和代理機之間是使用加密通道來通信的，中間人無法竊取通道中的資料。而在微服務應用中，我們結合Java原生的代理參數和自研的流量攔截方案來将應用的流量轉發至通道服務。

開發人員在IDE中啟動應用時，端雲互聯插件會自動拉起通道服務，并注入相關參數至應用中。啟動後，應用流量自動轉發至通道服務，無需人工幹預。

從架構上來看，端雲互聯跟VPN有點類似，都分為服務端和用戶端。但實際上，兩者有很大的差異，下圖進行了對比總結：

其中，在“雲端通路本地”這一點上，雖然兩者都支援，但具體原理并不相同。如果采取VPN方案，那麼其他雲端服務通路本地服務時，需要手動配置網絡路由，否則網絡不可達。而端雲互聯通過改造微服務架構，可使得雲端服務調用代理機，再通過代理機轉發到本地應用中，無需設定網絡路由。在易用性和安全性上，端雲互聯都優于VPN。

端雲互聯2.0

在1.0階段，我們實作了本地和雲端的雙向互通，這滿足了最基本的開發需求。在實際業務中，客戶提出了更高的要求。

我們一個客戶有龐大的研發團隊，他們都使用端雲互聯進行開發，但在聯調時發現一個問題：研發人員A發起的服務調用有時候調到别的節點去了，沒有到所期望的研發人員B的本地節點上。這個問題是由于微服務架構的路由機制引起的，當環境中一個服務存在多個節點時，會使用随機（或輪流）算法來進行調用。微服務子產品越多，鍊路越長，這個問題就越嚴重。

在2.0中，我們提供了多人精準聯調能力，此能力可使得服務請求“指哪打哪”，可大幅提高服務聯調效率。除此之外，我們還提供基于代理的遠端調試能力，友善本地對雲端環境中的微服務節點進行調試，提高調試效率。

同時，通過橫向産品支援，端雲互聯2.0可服務于雲原生産品EDAS、SAE和MSE等開發者，受到廣泛好評。

多人精準聯調

下圖描述了多人聯調的一個典型場景：

小王負責服務A，小張負責服務B，在一次需求疊代中他們完成了代碼開發，正在進行聯調。由于微服務架構使用随機（或輪流）政策進行調用，導緻了兩個問題：

• 測試同學小馬正在環境中進行功能測試，測試請求調用到小王和小張的本地節點上來了，導緻測試不符合預期；
• 小王發起的測試請求調到其他節點去了，沒到他和小張的節點上，聯調效率很低；

通過多人精準聯調能力，可以使得隻有小王發起的請求調到他的本地節點和小張的本地節點，而測試小馬的請求隻在雲端穩定環境中調用。

小王和小張需要做的事情比較簡單，他們隻需要在控制台開啟全鍊路流控功能，建立一個用于測試的流控環境。流控環境可配置請求識别規則，可通過Cookie、Header、請求參數等次元來判斷是否為測試請求，如果判斷通過則将請求調用到該環境中的節點中去。

然後小王和小張在IDE中将本地節點添加到這個測試環境中去即可，如下所示：

這樣配置完成後，那麼隻有符合特征的請求才會調用到小王和小張的節點，下圖中隻有Header包含“測試”的請求才會到他們節點中：

遠端調試

遠端調試（Remote Debug）一直都是排查問題的重要手段，但在雲原生環境裡遠端調試并不是一件簡單的事情。這是因為在預設情況下雲上的微服務節點通常不能被公網通路，如果需要進行遠端調試，我們需要對目标節點開放公網通路，并且設定安全政策以放通調試端口流量。

如果目前有A，B，C三個服務，每個服務有3個節點，那麼我們需要分别建立3個安全組，并綁定9個公網網卡到機器節點。如下所示：

這種方式存在以下問題：

• 浪費成本：每個微服務節點都需要綁定公網網卡，成本跟測試節點數成正相關。
• 配置複雜：在雲上往往采取彈性伸縮的政策來維護機器節點，達到“用時即建，用完即放”的按需使用目的。而每當建立新的機器節點我們都需要單獨配置公網網卡和安全組，使用上較繁瑣。
• 存在安全性隐患：如果微服務節點都對外暴露公網通路，會存在較大的安全風險。

甚至在有些場景下，由于安全要求内網機器節點不允許挂載公網網卡。對于這些問題，端雲互聯支援基于代理的遠端調試，如下所示：

調試請求通過通道服務來轉發給代理機，再由代理機轉發至目标調試節點。通道服務和代理機之間的通道是加密的。對于安全要求非常嚴格的場景，可以使用安全組（或白名單）政策來進一步提高代理機的安全水位。

在使用上，你隻需配置Alibaba Cloud Remote Debug，配置内容跟IDE自帶的遠端調試配置基本相同，但支援使用代理進行連接配接，如下所示：

其中有如下配置項：

• Proxy：指定雲端代理機。當運作時，插件會自動拉起通道服務連接配接代理機，無需人工幹預。
• Host：指定遠端調試的目标機器節點IP。圖中為172.16.0.1。
• Port：指定遠端調試的目标機器調試端口。圖中為5005。

雲原生産品支援

端雲互聯2.0支援了阿裡雲上微服務領域三大産品，EDAS（企業級分布式應用服務）、SAE（Serverless應用引擎）和MSE（微服務引擎）。這三個産品都支援微服務治理能力，滿足不同的企業需求，産品特性如下：

• 企業級分布式應用服務 EDAS（Enterprise Distributed Application Service）：是應用全生命周期管理和監控的一站式 PaaS 平台，支援部署于 Kubernetes/ECS，無侵入支援 Java/Go/Python/PHP/.NetCore 等多語言應用的釋出運作和服務治理 ，Java 支援 Spring Cloud、Apache Dubbo 近五年所有版本，多語言應用一鍵開啟 Service Mesh。
• Serverless 應用引擎（Serverless App Engine，簡稱 SAE）：實作了Serverless 架構 + 微服務架構的完美融合，真正按需使用、按量計費，節省閑置計算資源，同時免去 IaaS 運維，有效提升開發運維效率。SAE 支援 Spring Cloud、Dubbo 等流行的微服務架構，支援控制台、Jenkins、雲效、插件等部署方式。除了微服務應用外，您還能通過 Docker 鏡像部署任何語言的應用。
• 微服務引擎(Micro Service Engine，簡稱MSE)：是一個面向業界主流開源微服務生态的一站式微服務平台， 幫助微服務使用者更穩定、更便捷、更低成本的使用開源微服務技術建構微服務體系。提供注冊中心、配置中心全托管(相容Nacos/ZooKeeper/Eureka)、網關(相容Zuul/Kong/Spring Cloud Gateway)和無侵入的開源增強服務治理能力。

是以，無論你是EDAS使用者、SAE使用者還是MSE使用者，都可以使用端雲互聯能力來提高上雲的開發效率。在插件上，這三個産品的配置步驟是基本相同的，除了産品自身的差異性以外。配置頁如下所示：

在未來，我們會支援阿裡雲上更多的雲原生産品進行互聯，同時也會服務于阿裡雲以外的雲原生開發者，敬請期待。

端雲互聯3.0

2.0版本解決了Java應用跟雲端互聯互通的問題，很多細節也打磨的比較完善，但它缺乏對容器領域和診斷能力的支援。這些能力我們在3.0階段進行了補齊。

如果你是Kubernetes使用者，那麼可以使用3.0插件的Kubernetes代理能力，無需額外配置雲端代理機。

如果你是非Java語言使用者，或者對應用運作環境有一定要求，那麼可以使用3.0插件的容器級互聯能力，來在本地使用Docker運作應用。在Docker容器中，應用可以正常通路雲端服務和資源，流量自動通過代理來轉發。

如果你對本地運作應用所發生的調用異常感到無從下手，那麼可以使用3.0插件的本地鍊路診斷能力，我們會統一收集本地應用的調用鍊路，調用異常一目了然。

下面來具體介紹這些特性。

Kubernetes代理

3.0版本的Kubernetes代理能力可基于Kubernetes叢集自動打通代理通道。

在面向Kubernetes的開發中，我們可以通過kubectl指令和kubeconfig配置檔案來跟API Server進行通信，并通路叢集中的容器。API Server會對請求進行身份認證、鑒權和加密處理。如果開放API Server的公網通路，那麼我們在本地通過kubectl執行互動式指令時，此時API Server将充當中間代理角色，如下所示：

基于此特性，端雲互聯3.0插件在應用啟動時，調用kubectl臨時建立一個代理容器。通過結合API Server和臨時代理容器進行打通，本地應用可通路雲端服務和其他資源。整體鍊路如下所示：

代理容器占用64MB ~ 128MB的節點記憶體，并在本地應用停止時自動删除。

而在插件配置上也非常簡單，你隻需在插件中設定kubeconfig配置檔案和選擇Kubernetes命名空間：

在啟動本地應用時，插件使用該kubeconfig配置檔案來調用kubectl建立臨時容器，并進行通道打通和流量轉發。在終止應用時，插件使用該kubeconfig配置檔案來調用kubectl删除該臨時容器。

容器級互聯

容器級互聯是指，本地會啟動Docker容器，并在容器内運作你的微服務應用，微服務應用可跟雲端環境進行互聯。如果你存在如下場景，那麼容器級互聯是你的最佳選擇：

• 非Java語言應用；
• 應用運作時對作業系統存在特定要求；

在此模式下，微服務應用和通道服務都使用容器來運作，整體互動如下：

在實作層面上，容器級互聯基于iptables來攔截和轉發流量到代理容器中的通道服務，通道服務再将資料通過雲端代理轉發至目标位址。在架構上，這種模式跟Service Mesh的Sidecar模式有點類似，應用容器把流量轉發給通道服務容器（sidecar容器）。不過端雲互聯的通道容器隻是做資料的透明轉發，而Service Mesh的sidecar可進行微服務發現和治理的能力，這一點有所不同。

在使用上，插件運作容器的Alibaba Microservice Container配置，互動如下所示：

如果你在應用容器中運作的是Java語言應用，插件還支援快捷的應用調試，無需額外設定具體參數。啟動應用時，插件會通過環境變量注入JDWP調試參數，以打開調試端口。插件進一步結合Intellij IDEA的智能檢測，可通過Attach debugger來一鍵調試容器中的Java應用，如下所示：

由圖可見，插件會将容器中應用的日志輸出列印在IDE視窗中，日志中的“Listening for transport dt_socket at address: 5005”表示容器中的Java應用已打開調試端口。點選Attach debugger，IDE将會連接配接到容器中Java應用的調試端口，接下來便可進行代碼調試，如下所示：

本地鍊路診斷

在開發過程中，你是否遇到過這個場景：下遊服務接口傳回了500，你隻知道接口調用失敗了，但具體原因并不知曉？找該子產品研發人員來排查時，他過了半天回複一句“現在有點忙，待會我看看”？等他有空排查後，發現問題出在另一個子產品，讓你去找另一個同學來排查？...

諸如此類的場景在開發過程中屢見不鮮，往往一個小問題要花費大量精力和時間來進行排查。這個場景是鍊路追蹤技術的典型場景。現在，我們把鍊路追蹤也內建到端雲互聯能力上，使得本地調用鍊路也能上報到雲端，當出現異常時問題一目了然。

比如，目前環境中有交易中心、商品中心和庫存中心三個服務，你正在和測試同學驗證新版本特性。測試同學在頁面測試下單流程時，發現下單失敗，如下所示：

由于涉及子產品多，問題排查耗時非常長。端雲互聯3.0插件內建了ARMS（應用實時監控服務）的Java Agent，它通過代碼無侵入的埋點機制來收集調用鍊路上的資訊并上報到ARMS服務端進行統一收集和智能分析。出現異常時，隻需在雲端根據TraceId來查詢調用鍊路，問題了然于胸：

TraceId是用于鍊路追蹤底層的概念，從前端頁面開始生成并透傳至下遊各節點。為友善使用，插件還提供了列印本地鍊路的開關，開啟後将會輸出本地應用服務調用鍊路的相關資訊，如下所示：

鍊路輸出中包含如下資訊：

• TraceId：用于标記請求的整體處理過程。在分布式微服務調用場景下，TraceId會從最前端的應用節點透傳至下遊鍊路各個節點，可根據此TraceId在 EDAS控制台 或 ARMS控制台 查詢整體鍊路處理過程。
• Service：目前應用的請求處理入口，如Spring Cloud服務、Dubbo服務、HSF服務等。
• API：鍊路處理過程中的方法簽名。
• Line：方法處理的具體行數。
• Cost：此方法及其下遊處理的耗時，機關毫秒。
• Ext：擴充資訊，包含請求處理狀态碼、資料庫通路SQL、資源目标位址等資訊。
• Console link：ARMS控制台上收集的此鍊路資訊，可點選此連結直接檢視全鍊路資訊。

點選Console link連結，可檢視此請求的上下遊處理鍊路，如下所示：

我們還可以進一步檢視每個服務内的處理詳情：

看到這裡，是不是感覺排查問題有更多思路了呢：）

寫在最後

雲原生浪潮浩浩蕩蕩不可阻擋，業務上雲也是企業的必經之路。但上雲從來都不是一片坦途，在此過程中我們總會遇到一些困難和挑戰。得益于雲原生技術的日益成熟，這些問題一定會有相應的解法。

在開發态這一領域，我們是國内雲廠商當中走在前沿的探索者。從2018年開始孵化端雲互聯1.0版本，到目前2021年的端雲互聯3.0版本，當中遇到了大大小小的問題和挑戰，但最終都一一解決了。此能力為公共雲和專有雲的開發者帶來了極大的便利，使其在本地就可以完成開發、測試和聯調閉環。

在未來我們會不斷提供更好用、更強大、更易用的雲原生工具來服務開發者，敬請期待。

參考資料：

• 端雲互聯： 。
• EDAS（企業級分布式應用服務）： https://www.aliyun.com/product/edas
• SAE（Serverless 應用引擎）： https://www.aliyun.com/product/aliware/product/sae
• MSE（微服務引擎）： https://www.aliyun.com/product/aliware/mse
• ARMS（應用實時監控服務）： https://www.aliyun.com/product/arms
• Arthas： https://github.com/alibaba/arthas