當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

这个云原生开发的痛点你遇到了吗？

發布時間：2024/9/3 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了这个云原生开发的痛点你遇到了吗？小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

簡介：上云從來都不是一片坦途，在此過程中我們總會遇到一些困難和挑戰，得益于云原生技術的日益成熟，這些問題一定會有相應的解法。

作者：納海

端云互聯最佳實踐：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版本，當中遇到了大大小小的問題和挑戰，但最終都一一解決了。此能力為公共云和專有云的開發者帶來了極大的便利，使其在本地就可以完成開發、測試和聯調閉環。

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

參考資料：

端云互聯：https://help.aliyun.com/document_detail/200032.html 。
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 。

原文鏈接：https://developer.aliyun.com/article/783911?

總結

以上是生活随笔為你收集整理的这个云原生开发的痛点你遇到了吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： MQTT 轻量版实例发布，满足更多移动互
下一篇：技术干货 | 轻松两步完成向 mPaaS