背景

在云原生時代，國內(nèi)外眾多云廠商釋放出強大的技術(shù)紅利，如何利用廉價、穩(wěn)定且高效的云設(shè)施是當(dāng)今的一個主要命題。在云上，我們可以很方便地創(chuàng)建虛擬網(wǎng)絡(luò)、虛擬機、數(shù)據(jù)庫、消息隊列等基礎(chǔ)設(shè)施和中間件，也可以使用容器服務(wù)、EDAS、SAE、函數(shù)計算等PaaS和Serverless服務(wù)來減輕應(yīng)用管控的壓力。

但事情并不是一帆風(fēng)順的。應(yīng)用上云已是歷史大潮不可阻擋，但隨之而來開發(fā)者很快就體會到上云的另一面：由云上和云下網(wǎng)絡(luò)不通所帶來的開發(fā)體驗割裂感。在上云之前，開發(fā)者可以在本地完成代碼開發(fā)、測試、聯(lián)調(diào)等開發(fā)流程閉環(huán)；而上云之后，數(shù)據(jù)庫、緩存、消息隊列和其他微服務(wù)應(yīng)用都部署在云上的虛擬網(wǎng)絡(luò)之中，我們再無法在本地完成開發(fā)流程。

如果是中東土豪，他可能會考慮使用物理專線來打通網(wǎng)絡(luò)。因為他只需支付光纖鋪設(shè)費、樓內(nèi)光纜租賃費、端口占用費、流量費等百萬量級的錢，同時說服安全團隊來允許完全打通環(huán)境而已。

如果是專業(yè)運維人員，他可能會考慮搭建虛擬專用網(wǎng)絡(luò)來打通網(wǎng)絡(luò)。當(dāng)他花費精力搭建虛擬專用網(wǎng)絡(luò)服務(wù)器，發(fā)現(xiàn)同事們還是用不起來，紛紛抱怨：

“一打開虛擬專用網(wǎng)絡(luò)，整個本地系統(tǒng)網(wǎng)絡(luò)流量都轉(zhuǎn)發(fā)到云端了，其他事情干不了啦！”“除了配置虛擬專用網(wǎng)絡(luò)，還要配置應(yīng)用運行參數(shù)，太麻煩了！”“云端服務(wù)怎么調(diào)用不了本地服務(wù)，云端網(wǎng)絡(luò)路由添加了嗎？”...

看到這些問題，運維小哥內(nèi)心也感到心累...

而現(xiàn)在，我們提供了一個開箱即用的插件工具，無需你花費大量的金錢或者人力。你所需要的只是在IDE中一鍵開啟開關(guān)，然后通過IDE所啟動的應(yīng)用就能訪問到云端環(huán)境里的數(shù)據(jù)庫、MQ、緩存和其他微服務(wù)。所有的事情都由插件來幫你完成。

介紹

這款工具是我們自主研發(fā)的“端云互聯(lián)”插件，“端”指的是開發(fā)端，“云”指的是云上網(wǎng)絡(luò)，通過某種方式實現(xiàn)“端”和“云”的雙向互通，并且沒有傳統(tǒng)虛擬專用網(wǎng)絡(luò)的問題。

端云互聯(lián)功能集成在Alibaba Cloud Toolkit（簡稱ACT）這個上云工具產(chǎn)品中，并支持Intellij IDEA和Eclipse兩款I(lǐng)DE。你只需在插件市場中搜索“Alibaba Cloud Toolkit”進行安裝即可，例如在Intellij IDEA中搜索如下：

我們在2018年就開始了端云互聯(lián)項目的研發(fā)，這個過程中迭代了大大小小的版本，共經(jīng)歷了三個里程碑，至今有數(shù)十萬人次的使用。下面來介紹它的特性支持和實現(xiàn)原理。

端云互聯(lián)1.0

1.0階段解決了本地和云端雙向互聯(lián)的問題，使得本地服務(wù)不僅僅可訪問云端資源，還可以跟云端服務(wù)互相通信。

雙向互聯(lián)

以下為端云互聯(lián)的核心架構(gòu)，整體分為兩個模塊：通道服務(wù)和代理機。

其中，模塊功能如下：

代理機：負責(zé)云端的流量轉(zhuǎn)發(fā)。端云互聯(lián)方案對代理機的要求很低，一臺普通規(guī)格的ECS就可以充當(dāng)“乞丐版”的代理機。并且，Debian、Ubuntu、Redhat等Linux系統(tǒng)已經(jīng)包含端云互聯(lián)所依賴的底層庫，無需額外安裝其他軟件。通道服務(wù)：負責(zé)本地的流量轉(zhuǎn)發(fā)。當(dāng)我們打開端云互聯(lián)開關(guān)并啟動應(yīng)用時，插件會在本地拉起一個通道服務(wù)進程。這個進程的職責(zé)非常簡單，它只負責(zé)本地應(yīng)用和云端代理機之間的流量轉(zhuǎn)發(fā)，無其他操作。

通道服務(wù)和代理機之間是使用加密通道來通信的，中間人無法竊取通道中的數(shù)據(jù)。而在微服務(wù)應(yīng)用中，我們結(jié)合Java原生的代理參數(shù)和自研的流量攔截方案來將應(yīng)用的流量轉(zhuǎn)發(fā)至通道服務(wù)。

開發(fā)人員在IDE中啟動應(yīng)用時，端云互聯(lián)插件會自動拉起通道服務(wù)，并注入相關(guān)參數(shù)至應(yīng)用中。啟動后，應(yīng)用流量自動轉(zhuǎn)發(fā)至通道服務(wù)，無需人工干預(yù)。

從架構(gòu)上來看，端云互聯(lián)跟虛擬專用網(wǎng)絡(luò)有點類似，都分為服務(wù)端和客戶端。但實際上，兩者有很大的差異，下圖進行了對比總結(jié)：

其中，在“云端訪問本地”這一點上，雖然兩者都支持，但具體原理并不相同。如果采取虛擬專用網(wǎng)絡(luò)方案，那么其他云端服務(wù)訪問本地服務(wù)時，需要手動配置網(wǎng)絡(luò)路由，否則網(wǎng)絡(luò)不可達。而端云互聯(lián)通過改造微服務(wù)框架，可使得云端服務(wù)調(diào)用代理機，再通過代理機轉(zhuǎn)發(fā)到本地應(yīng)用中，無需設(shè)置網(wǎng)絡(luò)路由。在易用性和安全性上，端云互聯(lián)都優(yōu)于虛擬專用網(wǎng)絡(luò)。

端云互聯(lián)2.0

在1.0階段，我們實現(xiàn)了本地和云端的雙向互通，這滿足了最基本的開發(fā)需求。在實際業(yè)務(wù)中，客戶提出了更高的要求。

我們一個客戶有龐大的研發(fā)團隊，他們都使用端云互聯(lián)進行開發(fā)，但在聯(lián)調(diào)時發(fā)現(xiàn)一個問題：研發(fā)人員A發(fā)起的服務(wù)調(diào)用有時候調(diào)到別的節(jié)點去了，沒有到所期望的研發(fā)人員B的本地節(jié)點上。這個問題是由于微服務(wù)框架的路由機制引起的，當(dāng)環(huán)境中一個服務(wù)存在多個節(jié)點時，會使用隨機（或輪流）算法來進行調(diào)用。微服務(wù)模塊越多，鏈路越長，這個問題就越嚴重。

在2.0中，我們提供了多人精準聯(lián)調(diào)能力，此能力可使得服務(wù)請求“指哪打哪”，可大幅提高服務(wù)聯(lián)調(diào)效率。除此之外，我們還提供基于代理的遠程調(diào)試能力，方便本地對云端環(huán)境中的微服務(wù)節(jié)點進行調(diào)試，提高調(diào)試效率。

同時，通過橫向產(chǎn)品支持，端云互聯(lián)2.0可服務(wù)于云原生產(chǎn)品EDAS、SAE和MSE等開發(fā)者，受到廣泛好評。

多人精準聯(lián)調(diào)

下圖描述了多人聯(lián)調(diào)的一個典型場景：

小王負責(zé)服務(wù)A，小張負責(zé)服務(wù)B，在一次需求迭代中他們完成了代碼開發(fā)，正在進行聯(lián)調(diào)。由于微服務(wù)框架使用隨機（或輪流）策略進行調(diào)用，導(dǎo)致了兩個問題：

測試同學(xué)小馬正在環(huán)境中進行功能測試，測試請求調(diào)用到小王和小張的本地節(jié)點上來了，導(dǎo)致測試不符合預(yù)期；小王發(fā)起的測試請求調(diào)到其他節(jié)點去了，沒到他和小張的節(jié)點上，聯(lián)調(diào)效率很低；

通過多人精準聯(lián)調(diào)能力，可以使得只有小王發(fā)起的請求調(diào)到他的本地節(jié)點和小張的本地節(jié)點，而測試小馬的請求只在云端穩(wěn)定環(huán)境中調(diào)用。

小王和小張需要做的事情比較簡單，他們只需要在控制臺開啟全鏈路流控功能，創(chuàng)建一個用于測試的流控環(huán)境。流控環(huán)境可配置請求識別規(guī)則，可通過Cookie、Header、請求參數(shù)等維度來判斷是否為測試請求，如果判斷通過則將請求調(diào)用到該環(huán)境中的節(jié)點中去。

然后小王和小張在IDE中將本地節(jié)點添加到這個測試環(huán)境中去即可，如下所示：

這樣配置完成后，那么只有符合特征的請求才會調(diào)用到小王和小張的節(jié)點，下圖中只有Header包含“測試”的請求才會到他們節(jié)點中：

遠程調(diào)試

遠程調(diào)試（Remote Debug）一直都是排查問題的重要手段，但在云原生環(huán)境里遠程調(diào)試并不是一件簡單的事情。這是因為在默認情況下云上的微服務(wù)節(jié)點通常不能被公網(wǎng)訪問，如果需要進行遠程調(diào)試，我們需要對目標(biāo)節(jié)點開放公網(wǎng)訪問，并且設(shè)置安全策略以放通調(diào)試端口流量。

如果當(dāng)前有A，B，C三個服務(wù)，每個服務(wù)有3個節(jié)點，那么我們需要分別建立3個安全組，并綁定9個公網(wǎng)網(wǎng)卡到機器節(jié)點。如下所示：

這種方式存在以下問題：

浪費成本：每個微服務(wù)節(jié)點都需要綁定公網(wǎng)網(wǎng)卡，成本跟測試節(jié)點數(shù)成正相關(guān)。配置復(fù)雜：在云上往往采取彈性伸縮的策略來維護機器節(jié)點，達到“用時即建，用完即放”的按需使用目的。而每當(dāng)創(chuàng)建新的機器節(jié)點我們都需要單獨配置公網(wǎng)網(wǎng)卡和安全組，使用上較繁瑣。存在安全性隱患：如果微服務(wù)節(jié)點都對外暴露公網(wǎng)訪問，會存在較大的安全風(fēng)險。

甚至在有些場景下，由于安全要求內(nèi)網(wǎng)機器節(jié)點不允許掛載公網(wǎng)網(wǎng)卡。對于這些問題，端云互聯(lián)支持基于代理的遠程調(diào)試，如下所示：

調(diào)試請求通過通道服務(wù)來轉(zhuǎn)發(fā)給代理機，再由代理機轉(zhuǎn)發(fā)至目標(biāo)調(diào)試節(jié)點。通道服務(wù)和代理機之間的通道是加密的。對于安全要求非常嚴格的場景，可以使用安全組（或白名單）策略來進一步提高代理機的安全水位。

在使用上，你只需配置Alibaba Cloud Remote Debug，配置內(nèi)容跟IDE自帶的遠程調(diào)試配置基本相同，但支持使用代理進行連接，如下所示：

其中有如下配置項：

Proxy：指定云端代理機。當(dāng)運行時，插件會自動拉起通道服務(wù)連接代理機，無需人工干預(yù)。Host：指定遠程調(diào)試的目標(biāo)機器節(jié)點IP。圖中為172.16.0.1。Port：指定遠程調(diào)試的目標(biāo)機器調(diào)試端口。圖中為5005。

云原生產(chǎn)品支持

端云互聯(lián)2.0支持了阿里云上微服務(wù)領(lǐng)域三大產(chǎn)品，EDAS（企業(yè)級分布式應(yīng)用服務(wù)）、SAE（Serverless應(yīng)用引擎）和MSE（微服務(wù)引擎）。這三個產(chǎn)品都支持微服務(wù)治理能力，滿足不同的企業(yè)需求，產(chǎn)品特性如下：

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

因此，無論你是EDAS用戶、SAE用戶還是MSE用戶，都可以使用端云互聯(lián)能力來提高上云的開發(fā)效率。在插件上，這三個產(chǎn)品的配置步驟是基本相同的，除了產(chǎn)品自身的差異性以外。配置頁如下所示：

在未來，我們會支持阿里云上更多的云原生產(chǎn)品進行互聯(lián)，同時也會服務(wù)于阿里云以外的云原生開發(fā)者，敬請期待。

端云互聯(lián)3.0

2.0版本解決了Java應(yīng)用跟云端互聯(lián)互通的問題，很多細節(jié)也打磨的比較完善，但它缺乏對容器領(lǐng)域和診斷能力的支持。這些能力我們在3.0階段進行了補齊。

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

如果你是非Java語言用戶，或者對應(yīng)用運行環(huán)境有一定要求，那么可以使用3.0插件的容器級互聯(lián)能力，來在本地使用Docker運行應(yīng)用。在Docker容器中，應(yīng)用可以正常訪問云端服務(wù)和資源，流量自動通過代理來轉(zhuǎn)發(fā)。

如果你對本地運行應(yīng)用所發(fā)生的調(diào)用異常感到無從下手，那么可以使用3.0插件的本地鏈路診斷能力，我們會統(tǒng)一收集本地應(yīng)用的調(diào)用鏈路，調(diào)用異常一目了然。

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

Kubernetes代理

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

在面向Kubernetes的開發(fā)中，我們可以通過kubectl命令和kubeconfig配置文件來跟API Server進行通信，并訪問集群中的容器。API Server會對請求進行身份認證、鑒權(quán)和加密處理。如果開放API Server的公網(wǎng)訪問，那么我們在本地通過kubectl執(zhí)行交互式命令時，此時API Server將充當(dāng)中間代理角色，如下所示：

基于此特性，端云互聯(lián)3.0插件在應(yīng)用啟動時，調(diào)用kubectl臨時創(chuàng)建一個代理容器。通過結(jié)合API Server和臨時代理容器進行打通，本地應(yīng)用可訪問云端服務(wù)和其他資源。整體鏈路如下所示：

代理容器占用64MB ~ 128MB的節(jié)點內(nèi)存，并在本地應(yīng)用停止時自動刪除。

而在插件配置上也非常簡單，你只需在插件中設(shè)置kubeconfig配置文件和選擇Kubernetes命名空間：

在啟動本地應(yīng)用時，插件使用該kubeconfig配置文件來調(diào)用kubectl創(chuàng)建臨時容器，并進行通道打通和流量轉(zhuǎn)發(fā)。在終止應(yīng)用時，插件使用該kubeconfig配置文件來調(diào)用kubectl刪除該臨時容器。

容器級互聯(lián)

容器級互聯(lián)是指，本地會啟動Docker容器，并在容器內(nèi)運行你的微服務(wù)應(yīng)用，微服務(wù)應(yīng)用可跟云端環(huán)境進行互聯(lián)。如果你存在如下場景，那么容器級互聯(lián)是你的好選擇：

非Java語言應(yīng)用；應(yīng)用運行時對操作系統(tǒng)存在特定要求；

在此模式下，微服務(wù)應(yīng)用和通道服務(wù)都使用容器來運行，整體交互如下：

在實現(xiàn)層面上，容器級互聯(lián)基于iptables來攔截和轉(zhuǎn)發(fā)流量到代理容器中的通道服務(wù)，通道服務(wù)再將數(shù)據(jù)通過云端代理轉(zhuǎn)發(fā)至目標(biāo)地址。在架構(gòu)上，這種模式跟Service Mesh的Sidecar模式有點類似，應(yīng)用容器把流量轉(zhuǎn)發(fā)給通道服務(wù)容器（sidecar容器）。不過端云互聯(lián)的通道容器只是做數(shù)據(jù)的透明轉(zhuǎn)發(fā)，而Service Mesh的sidecar可進行微服務(wù)發(fā)現(xiàn)和治理的能力，這一點有所不同。

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

如果你在應(yīng)用容器中運行的是Java語言應(yīng)用，插件還支持快捷的應(yīng)用調(diào)試，無需額外設(shè)置具體參數(shù)。啟動應(yīng)用時，插件會通過環(huán)境變量注入JDWP調(diào)試參數(shù)，以打開調(diào)試端口。插件進一步結(jié)合Intellij IDEA的智能檢測，可通過Attach debugger來一鍵調(diào)試容器中的Java應(yīng)用，如下所示：

由圖可見，插件會將容器中應(yīng)用的日志輸出打印在IDE窗口中，日志中的“Listening for transport dt_socket at address: 5005”表示容器中的Java應(yīng)用已打開調(diào)試端口。點擊Attach debugger，IDE將會連接到容器中Java應(yīng)用的調(diào)試端口，接下來便可進行代碼調(diào)試，如下所示：

本地鏈路診斷

在開發(fā)過程中，你是否遇到過這個場景：下游服務(wù)接口返回了500，你只知道接口調(diào)用失敗了，但具體原因并不知曉？找該模塊研發(fā)人員來排查時，他過了半天回復(fù)一句“現(xiàn)在有點忙，待會我看看”？等他有空排查后，發(fā)現(xiàn)問題出在另一個模塊，讓你去找另一個同學(xué)來排查？...

諸如此類的場景在開發(fā)過程中屢見不鮮，往往一個小問題要花費大量精力和時間來進行排查。這個場景是鏈路追蹤技術(shù)的典型場景。現(xiàn)在，我們把鏈路追蹤也集成到端云互聯(lián)能力上，使得本地調(diào)用鏈路也能上報到云端，當(dāng)出現(xiàn)異常時問題一目了然。

比如，當(dāng)前環(huán)境中有交易中心、商品中心和庫存中心三個服務(wù)，你正在和測試同學(xué)驗證新版本特性。測試同學(xué)在頁面測試下單流程時，發(fā)現(xiàn)下單失敗，如下所示：

由于涉及模塊多，問題排查耗時非常長。端云互聯(lián)3.0插件集成了ARMS（應(yīng)用實時監(jiān)控服務(wù)）的Java Agent，它通過代碼無侵入的埋點機制來收集調(diào)用鏈路上的信息并上報到ARMS服務(wù)端進行統(tǒng)一收集和智能分析。出現(xiàn)異常時，只需在云端根據(jù)TraceId來查詢調(diào)用鏈路，問題了然于胸：

TraceId是用于鏈路追蹤底層的概念，從前端頁面開始生成并透傳至下游各節(jié)點。為方便使用，插件還提供了打印本地鏈路的開關(guān)，開啟后將會輸出本地應(yīng)用服務(wù)調(diào)用鏈路的相關(guān)信息，如下所示：

鏈路輸出中包含如下信息：

TraceId：用于標(biāo)記請求的整體處理過程。在分布式微服務(wù)調(diào)用場景下，TraceId會從最前端的應(yīng)用節(jié)點透傳至下游鏈路各個節(jié)點，可根據(jù)此TraceId在EDAS控制臺或ARMS控制臺查詢整體鏈路處理過程。Service：當(dāng)前應(yīng)用的請求處理入口，如Spring Cloud服務(wù)、Dubbo服務(wù)、HSF服務(wù)等。API：鏈路處理過程中的方法簽名。Line：方法處理的具體行數(shù)。Cost：此方法及其下游處理的耗時，單位毫秒。Ext：擴展信息，包含請求處理狀態(tài)碼、數(shù)據(jù)庫訪問SQL、資源目標(biāo)地址等信息。Console link：ARMS控制臺上收集的此鏈路信息，可點擊此鏈接直接查看全鏈路信息。

點擊Console link鏈接，可查看此請求的上下游處理鏈路，如下所示：

我們還可以進一步查看每個服務(wù)內(nèi)的處理詳情：

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

寫在最后

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

在開發(fā)態(tài)這一領(lǐng)域，我們是國內(nèi)云廠商當(dāng)中走在前沿的探索者。從2018年開始孵化端云互聯(lián)1.0版本，到目前2021年的端云互聯(lián)3.0版本，當(dāng)中遇到了大大小小的問題和挑戰(zhàn)，但最終都一一解決了。此能力為公共云和專有云的開發(fā)者帶來了極大的便利，使其在本地就可以完成開發(fā)、測試和聯(lián)調(diào)閉環(huán)。

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