*作者：* *納海、孤弋*

## 前言

從 Kubernetes 誕生以來，以 DevOps、容器化、可觀測、微服務、Serverless 等技術為代表的雲原生，催生了應用架構新一輪的升級。有意思的是，與以往的技術迭代更新不同，原本是一個技術圈常規的一次技術實踐，在千行百業數字化轉型大背景，疊加持續疫情衝擊的雙重影響之下，加上部分傳統行業科技自主政策的催化；這一次的技術迭代幾乎變成了 IT 從業人員全民參與的一次盛宴。但是陡峭的學習曲線、複雜的技術體系、瞬態的基礎資源形態，讓企業的資訊體系建設在研發、構建、交付、運維等多方面都帶來了不少的挑戰。這些挑戰也加深了日益更新的技術棧與習慣於聚焦在一線業務開發的開發者之間矛盾，這個矛盾直接催生了最近的平臺工程理念的誕生。這個理念抓住這個衝突點，提出了“內部研發自助平臺”的構想：“企業應該以平臺化建設的方式，提供一系列的自助型工具，協助開發者在各個環節中解決遇到的各種技術問題”。這個說法一下戳中眾多開發者的癢點，這也是這一概念突然之間大火的原因之一。理念背後又引申出來了一個更為直接的問題：這個工具裡面應該有點啥？

## 揭開問題的面紗

早在 2018 年，EDAS 產研團隊拜訪一傢俱有百人研發團隊的客戶，當時客戶正在進行微服務拆分和遷移上雲，他們遇到了一些新問題：

-   本地因為依賴問題，沒法起動完整的環境，導致開發困難。

-   雲上環境呼叫關係複雜，無法做除錯。

客戶期望將特定的例項啟動到本地，雲端能調本地，本地調雲端，實現微服務端雲聯調。對於這些問題我們沒有任何準備，於是回來後趕緊開始調研分析，於是慢慢揭開了藏在水面下的冰山。

客戶的訴求很簡單，就是想把微服務應用起在本地，應用能跟雲端微服務互相呼叫，如下所示：

![1.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/63eda2d60ce74c65a361b594c8ea314e~tplv-k3u1fbpfcp-zoom-1.image "1.jpeg")

遷移上雲後，客戶的閘道器、應用、訊息佇列、快取、資料庫等元件模組都部署在雲端網路內，本地需要經過堡壘機才能進行訪問。在這種情況下，本地節點是不可能正常啟動的（因為連不通資料庫等關鍵元件），也是不可能跟雲端服務互相呼叫的。採取了雲原生架構之後，客戶卻再也回不去原來簡單高效的本地開發方式了。

這個問題只有這個客戶遇到嗎？不是的，這幾年我們跟很多客戶聊下來他們都有這個問題。但其實也不是一點解決辦法都沒有，最直接的辦法是：透過架設私有網路的方式，連通本地辦公網跟雲端網路，實現網路互通。但實際上這個辦法有三大缺陷，導致並不是很多客戶採用。

![2.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2d115a0483de4a4c96aa1509c45b163f~tplv-k3u1fbpfcp-zoom-1.image "2.jpeg")

-   **成本高昂**：搭建專線網路的投入相當大，相比於收益來說並不划算。

-   **安全性低**：打通本地到雲上網路，對本地辦公網和雲上生產網都帶來了不穩定因素，本質上擴大了安全域，也擴大了攻擊面。

-   **運維複雜**：網路運維是相當複雜的，在高度可伸縮的雲原生架構下打平本地和雲端網路，這個是很多網路工程師的噩夢。本地和雲端兩張網路必須做好規劃，兩邊網段不可衝突，同時雙向網路路由和安全策略都需要人工管理，複雜費力且容易出現問題。

對於這些問題，有的企業採取折中的辦法，在雲端找一臺機器作為 VPN 伺服器，搭建本地到雲端的 VPN 鏈路。這個方案同樣需要維護網路路由以實現網路互通，另外 OpenVPN 雖便宜但不穩定，專用 VPN 效能高但費用昂貴，魚與熊掌不可兼得。

意識到這些問題之後，我們便開始了“路漫漫其修遠兮”的探索之路。

## 端雲互聯，問題的初解答

在一開始我們就確定兩個目標：一是雙向打通本地和雲端鏈路，二是不需要對網路架構進行傷筋動骨的改造。

在歷經三個月的閉關研發之後，我們在 2018 年底研發出來了這個工具。它支援雙向聯通，而且是外掛化開箱即用，支援 Windows 和 MacOS 系統。我們把它命名為**端雲互聯**，其整體組成如下所示：

![3.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7b93ea026eef4d5a985ad90b9a534aa3~tplv-k3u1fbpfcp-zoom-1.image "3.jpeg")

端雲互聯外掛會在啟動微服務的時候拉起一個sidecar程式--通道服務，通道服務負責接收本地微服務的流量，並透過堡壘機轉發至雲端目標微服務。下面進一步說明其中三個核心要點。

### 本地微服務呼叫轉發到 sidecar

我們使用了 Java 原生的流量代理技術，透過注入啟動引數，可以使得本地微服務流量以 socks 協議轉發至通道服務 sidecar 上。關於具體引數細節，可閱讀 Java Networking and Proxies 來了解細節。

### sidecar 將呼叫轉發到雲端微服務

其實 SSH 本身就可以用來進行資料轉發，充當正向代理和反向代理。SSH 協議從下到上分為傳輸層、認證層和連線層三層協議：

-   **傳輸層協議（Transport Layer Protocol）** ：這層協議負責建立起安全的連線通道，是整個 SSH 的安全性基石。

-   **使用者認證協議（User Authentication Protocol）** ：這層協議負責完成遠端身份認證。

-   **連線協議（Connection Protocol）** ：這層協議實現 SSH 通道的多路複用和資訊互動，可以透過它來實現遠端命令執行和資料轉發等多種功能。

我們基於 SSH 的連線協議來使得通道服務 sidecar 將呼叫轉發到雲端微服務，雖然SSH底層原理有點複雜，但上層使用是挺簡單的，主流的程式語言也基本都有現成的庫來使用。

### 雲端微服務呼叫轉發到堡壘機

這裡我們利用了微服務的機制，將堡壘機的 IP 和特定埠作為本地微服務的地址資訊註冊到註冊中心。這樣雲端微服務呼叫時就會透過註冊中心發現堡壘機，併發起服務請求，再結合 SSH 的資料轉發就能回到本地微服務。

## 眾裡尋他千百度

端雲互聯工具上線後，受到了很多客戶的歡迎，但客戶使用過程中遇到了新的問題：

-   **NIO 流量代理問題**：Java Networking and Proxies 裡的流量代理引數只對 BIO 的流量生效，NIO 框架並不支援。這個問題影響面非常大，因為微服務應用基本都會直接或間接地使用 Java NIO 框架。具體簡單的例子，Netty 本身就是基於 Java Nio 的，而很多流行的中介軟體框架都使用 Netty 作為傳輸框架。

-   **域名解析問題**：對於域名解析，本地微服務應用在訪問之前會發起域名解析，而這些域名解析同樣是不支援 Java 流量代理的。也就是說，如果這個域名只能在雲端完成解析，那麼整個呼叫就會失敗。例如，K8s 裡的 service 域名只能在叢集節點上完成 DNS 解析，本地是無法解析的，從而導致本地無法呼叫 K8s service。

對於這些問題，業界通常的做法是採取容器來解決（例如 Telepresence），透過將應用跑在容器內，再結合 iptables 來攔截並轉發整個容器內的流量。這種方式是可行的，我們也支援了這種方式，整體架構如下所示：

![4.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/53d61517bebb450f900b659e5570d79a~tplv-k3u1fbpfcp-zoom-1.image "4.jpeg")

這個鏈路跟之前是差不多的，除了本地引入了容器技術之外。在上圖中，我們透過 docker network connect，可以使得應用容器和 sidecard 容器共享網路棧，這樣通道服務便可以透過 iptables 去攔截本地微服務程式的流量（包括 NIO 和 DNS 流量）並進行轉發。

方案很美好，但現實很骨感，很多客戶用不起來。究其原因，那就是：**本地開發需要引入容器這個重量級的依賴**。這裡有兩個問題，一個是“重”，另一個是“依賴”。“重”，是因為本地開發機器的算力是非常小的。Chrome、IDE 和通訊軟體等應用往往已經佔據了大部分的本地機器資源，在這背景下本地再啟動容器往往會導致當機。另外，Windows 和 MacOS 等主流作業系統也並不自帶 Docker 等容器軟體，開發者需要自己在本地自行安裝，由於網路頻寬等原因整個安裝過程也會遇到許多問題。

那除了使用容器，還有別的辦法來解決應用的流量代理問題嗎？還是有的，不過侷限性也非常大。例如 torsocks 這個工具就可以實現程式級別的 TCP 和 DNS 流量攔截並轉發，但問題是它並不支援 Windows 系統。MacOS 也存在問題。由於 torsocks 是基於 LD_PRELOAD/DYLD_INSERT_LIBRARIES 機制來改寫系統呼叫來進行流量攔截的，而 MacOS 系統本身有系統完整性保護，會阻止特定系統呼叫被改寫，因此並不是所有的流量都能被攔截到。

難道就沒有更好的方案了嗎？

## 那人卻在，燈火闌珊處

回顧一下我們所面臨的問題：Java 原生流量代理不支援 NIO 和 DNS 流量轉發。這裡有一個非常重要的資訊--Java。業界或者開源社群的流量攔截方案普遍追求通用性，從而引入了容器依賴，顧此失彼。

既然追求通用性有諸多問題，那麼聚焦到 Java 語言是否有更優的解法？答案是肯定的。**Java 可以透過 Agent 位元組碼技術，動態修改應用執行時的行為，而上層程式碼無需任何變動。** 比如像 Pinpoint、SkyWalking 等鏈路跟蹤工具，它們都是透過注入一個位元組碼Agent來實現無侵入的鏈路埋點的。再比如診斷領域流行的 Arthas 工具，它也是基於位元組碼技術來實現 Java 程式的呼叫跟蹤和 Profiling。

於是，我們開始探索基於位元組碼技術的解決方案。整個探索過程是艱難且有趣的。在微服務框架層面，我們需要適配 SpringCloud、Dubbo、HSF 甚至是 gRPC 等主流框架；在元件層面，我們需要支援微服務、資料庫、訊息佇列、任務排程、快取等等元件；在 JDK 版本上，我們需要相容從 JDK 1.7 到 JDK18 之間的版本...在這過程中，我們不斷進行迭代改進，也不斷收到客戶的正面反饋，讓工具日趨完美。

在經過 1 年時間的打磨之後，我們終於自研出基於位元組碼的 Java 流量代理技術，架構如下所示：

![5.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5fbfb127b86748459faf1b0e1bc58dd6~tplv-k3u1fbpfcp-zoom-1.image "5.jpeg")

這個方案只需要引入一個代理位元組碼 Agent，並沒有引入外部依賴。這個代理 Agent 相比於容器來說輕量得多，而且會在啟動階段被端雲互聯外掛自動拉取並注入，上層使用是無感知的。至此，我們終於很好地解決了本地微服務應用的流量代理問題。

## 獨上高樓，望盡天涯路

在這幾年裡，我們一直在低頭趕路，不斷地發現問題並解決問題。與此同時，雲原生社群也在逐步演進。同樣在 2018 年，kubernetes 社群發表了一篇名為 Developing on Kubernetes 的文章，上面對不同的開發模式有一個非常好的總結：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/48107921f728410c93d745c2c43e746d~tplv-k3u1fbpfcp-zoom-1.image "6.png")

remote 表示雲端，local 表示本地。cluster 為 K8s 叢集，dev 為開發環境。針對 dev 和 cluster 不同的位置，整體可分為四種開發模式：

-   **pure off-line**：這種模式表示你的 K8s 叢集和開發環境都在本地。K3s 、 Minikube和 EDAS Core（這裡先賣個關子，下文再進行介紹）都屬於這種模式，你可以在本地直接啟動一個輕量級的開發叢集。

-   **proxied**：這種模式表示 K8s 叢集執行在雲端，開發環境在本地，雲端叢集和本地開發環境透過代理進行互聯。這個模式的典型代表為社群的 Telepresence 和 EDAS 端雲互聯。在多語言通用性上 Telepresence 略勝一籌，而在 Java 上 EDAS 端雲互聯更加易用。

-   **live**：這種模式表示 K8s 叢集執行在雲端，開發環境在本地，原生程式碼透過 CICD 等方式來更新雲端的應用。這個模式是最常見的模式，也是普遍效率最低的模式。如果透過 CICD 部署，意味著你每次程式碼修改都需要經過漫長的構建和部署才能生效到叢集裡面。如果在開發過程中需要不斷修改程式碼來除錯，這個迭代部署過程是非常耗時的。

-   **remote**：這種模式表示 K8s 叢集和開發環境都在雲端。Cloud IDE 是典型的例子，程式碼和執行環境都在雲端，本地透過瀏覽器或者輕量級的端應用來編輯程式碼。實際上來看，這種方式仍未得到廣大開發者認可，本地 IDE 的體驗優於 Cloud IDE 體驗，本地開發仍然是主流。

在 proxied 模式上，我們已經把端雲互聯打磨的相當不錯了，但它不能解掉所有問題。這樣的場景並不罕見：**本地開發除錯都好好的，但一部署上去就是有問題。** 這種問題的根源是，本地執行的環境和雲端叢集裡執行環境是不一致的，這個不一致會產生種種問題。例如，本地能正常執行一個需要 2c4g 的 Java 程式，不代表雲上叢集也能正常分配一個 2c4g 的 Pod，因為當前叢集內可能是沒有多餘資源的。

這樣的問題有很多，不可一一列舉。這也促使我們進一步思考應該如何解決這些問題。在經過半年的調研、探索和研發，我們研發出**雲原生工具箱（Cloud Native Development Kit，簡稱 CNKit）** ，由它來解決這些問題，並提供雲原生架構下的開發、除錯和診斷能力。

## 雲原生工具箱（Cloud Native Development Kit）

我們解決問題的思路是，要解決環境不一致的問題，只能回到環境中去。一個應用在雲原生環境下啟動雖然看上去很簡單，但實際上是要經歷很多個步驟的。應用需要經過從 K8s 排程，到 Pod 初始化，再到服務拉起，最終才能完成應用執行。在這個過程中，你可能會遇到以下問題：

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2634d907e592472ca1c23972dabc553b~tplv-k3u1fbpfcp-zoom-1.image "7.png")

對於這些問題，我們進行歸納總結，沉澱出一套解決方案：透過 CNKit 來快速複製 Pod，然後進行迭代開發、部署、除錯和診斷。整體功能如下所示：

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d7b4665ecd8149f795321cb9dab9226c~tplv-k3u1fbpfcp-zoom-1.image "8.png")

透過與 EDAS 全流量流控整合，CNKit 可使得只有符合特定規則的除錯流量進入複製的 Pod，而不影響其他正常流量。對於複製的 Pod，你可使用 CNKit 開箱即用的部署、除錯和診斷能力，並且可以使用基於審計的命令終端。下面來具體說明覆制、部署、除錯和診斷能力。

### 複製

這個複製的 Pod 相當於我們自己的一個臨時工作空間，我們可以不斷透過瀏覽器或者 IDE 來部署自己的應用包，並進行除錯和診斷。複製 Pod 當前支援如下配置：

![9.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e045f7be4e764e45ac5b1c0aef67ecec~tplv-k3u1fbpfcp-zoom-1.image "9.jpeg")

具體作用為：

-   **啟動命令**：即 Pod 的啟動命令。預設下使用原映象的啟動命令，而如果需要進行迭代部署或者開啟除錯的話，需要自定義啟動命令。這是因為在生產環境中，原映象啟動命令往往會使用應用程式來作為 1 號程式，一旦應用退出或重啟，這個 Pod 就會隨之釋放。因此，需要設定一個特殊的啟動命令來防止 Pod 隨應用退出而被釋放。

-   **複製模式**：支援基於 Pod 複製或者從 Deployment 的 spec 進行建立。

-   **目標節點**：即 Pod 執行在那個叢集節點上。預設透過 K8s 排程來執行 Pod，但你也可以直接指定特定叢集節點來執行此 Pod。

-   **Pod 日誌**：配置將 Pod 日誌打到標準輸出或者重定向到檔案。

-   **流量控制**：透過全鏈路流控，可使得只有符合特定規則的請求進入該 Pod 節點。

-   **診斷選項**：支援應用啟動時立即執行 tcpdump 來進行監測、一鍵開啟 JVM 異常記錄和去除 Liveness 探針。

這些選項都是基於 EDAS 長年累月的客戶支援所總結出來的經驗，可能看上去並不酷炫，但卻是非常實用的。拿“去除 Liveness 探針”這個配置項來說明。如果應用啟動階段就出現異常，這種情況下 Liveness 探針是會失敗的，K8s 會直接 Kill 掉這個 Pod 容器並重新拉起。我們會陷入 Liveness 失敗，Pod 容器被殺死，然後容器重啟導致現場丟失，Liveness 又失敗的無限迴圈當中。去除 Liveness 探針之後，你就可以進去 Pod 容器中進行問題排查了。

這裡還有一個非常有意思的配置項--全鏈路流控。全鏈路流控是 EDAS 上微服務治理的殺手鐧，可以使得整體微服務鏈路的流量指哪打哪。對於複製的 Pod，我們可能會希望只有自己的請求才進入這個 Pod，而不影響其他人的呼叫請求。這種情況只需要在介面上勾選加入特定流控分組即可，使用上非常簡單。

### 部署

還記得最初的問題嗎？在雲原生架構下，我們每次部署都需要經過 CICD、EDAS 部署和 K8s 排程來拉起應用，這個過程是漫長而痛苦的。而且，我們在排查問題時往往需要來臨時安裝特定工具，每次拉起新的應用 Pod 意味著需要重新安裝所需工具。

對於這個問題，我們推薦採取“一次複製，多次使用”策略。在上面提到，我們可以透過複製 Pod 來建立出屬於自己的“臨時工作區”（實質也是一個 Pod），然後可以透過瀏覽器或者 IDE 來直接把應用包部署到臨時工作區，並且進行除錯診斷。基於 CICD 和 CNKit 的開發流程是截然不同的，如下所示：

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f8537d9548fc44f2b8dc6c21f3a60a0f~tplv-k3u1fbpfcp-zoom-1.image "10.png")

CICD 部署路徑適合生產環境，透過標準流程保證了線上業務的穩定性。但同時它又是流程冗長的，在開發階段優勢不明顯，反而會降低開發效率。這種情況下 CNKit 部署流程是很好的互補，你只需要複製 Pod，然後便可以透過瀏覽器或者 IDE 來不斷更新應用包除錯程式碼。

### 除錯

除錯（這裡特指 remote debug）是應用開發過程中相當重要的一環，如果無法除錯，那麼應用開發效率將會大大降低。在雲原生架構下，除錯應用並不是那麼簡單，但總是可以完成的。在這一方面，CNKit 除了簡化除錯流程外，還提供了流量控制能力：

-   **簡化流程**：你只需要在頁面上點選“開啟除錯”，CNKit 便會重啟 Pod 裡的應用來開啟除錯埠。然後本地透過 IDE 來一鍵連線到 CNKit，接著就可以開始斷點除錯了。

-   **流量控制**：透過整合 EDAS 全鏈路流控，CNKit 可使得只有特定請求能進入複製 Pod，觸發斷點除錯邏輯。

透過這兩點，你可以非常方便地完成程式碼除錯。下圖是一個簡單的說明樣例，假如你在開發一個商品中心，上游為交易中心，下游為庫存中心，使用 CNKit 進行除錯的整體鏈路如下所示：

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2458dfb9244f49c2a4e00f5673d26e4e~tplv-k3u1fbpfcp-zoom-1.image "11.png")

標記為開發版本的商品中心即為複製出來的 Pod 節點，雲端環境中透過全鏈路流控來將特定流量轉發到該 Pod 中，開發者本地則透過 CNKit proxy 來連線到該 Pod 的除錯埠。

實際上，在一個多人並行開發的服務中，每個人都可以擁有屬於自己的開發版本節點，只需要設定不同的流量控制規則即可，這樣可並行開發可互不干擾。

### 診斷

我們將問題診斷為 K8s 排程、應用啟動、應用執行和應用下線四個階段。在不同階段，採取的診斷手段並不相同：

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/36074344a56741238876915600495762~tplv-k3u1fbpfcp-zoom-1.image "12.png")

在 K8s 排程過程中，我們主要關注其產生的相關事件，發生排程異常時 K8s 會給出相關原因。下圖為正常排程時的 K8s 事件：

![13.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4fe1b977aa2a4ffa88116d696d364f25~tplv-k3u1fbpfcp-zoom-1.image "13.jpeg")

當出現排程異常（例如資源不足導致排程失敗）的問題時，K8s 會產生相應事件：

![14.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8f95ba02248544b6ad0ea7ad59bc3527~tplv-k3u1fbpfcp-zoom-1.image "14.jpeg")

而在應用啟動階段，除了 K8s 事件，我們還可以觀察 Pod 日誌，這部分日誌是應用產生的，裡面包含更詳盡的資訊。下圖為 Pod 的標準輸出日誌樣例：

![15.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/71c1e6b1b4a94f0b93bf5c335c7df275~tplv-k3u1fbpfcp-zoom-1.image "15.jpeg")

另外，應用啟動階段會產生較多網路訪問，應用啟動失敗很多情況下都是由於網路請求異常引起的，因此 CNKit 支援在啟動前自動執行 Tcpdump 來記錄網路請求。下圖為應用啟動時自動抓取的 Tcpdump 包，CNKit 支援文字和 pcap 兩種格式，下圖為文字格式的 Tcpdump 資料：

![16.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f7f8dd7e22c6463cae6998ea276d13cb~tplv-k3u1fbpfcp-zoom-1.image "16.jpeg")

最後，在應用執行和下線階段，你仍然可以使用 K8s 事件、Pod 日誌和 Tcpdump，另外還可以一鍵使用 CNKit 整合的 Arthas 工具。透過在頁面上一鍵執行 Arthas，CNKit 會自動完成 Arthas 安裝並執行，整體互動如下所示：

![17.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/789fdbfc8b9141bca5165be4dccf423d~tplv-k3u1fbpfcp-zoom-1.image "17.jpeg")

至此，CNKit 的複製、部署、除錯和診斷都一一分享完畢。但除了這些能力，CNKit 還有一些隱藏彩蛋，例如審計 Webshell 等等，這些地方留給讀者來慢慢探索，此處不再贅述。

## EDAS Core

除了端雲互聯和 CNKit，我們還開放了 EDAS Core。如果按照上面 Developing on Kubernetes 劃分的標準來看，端雲互聯屬於 proxied 模式，CNKit 則為 live 模式，而 EDAS Core 則為 pure off-line 模式。

EDAS 本身是收費的商業化產品，它是一個應用託管和微服務管理的雲原生 PaaS 平臺，提供應用開發、部署、監控、運維等全棧式解決方案，同時支援 Spring Cloud 和 Apache Dubbo 等微服務執行環境。而 EDAS Core 則為免費的輕量級 EDAS 核心版本，同樣支援上述能力，但剝離了商業化特性，不提供服務 SLA 和實時的運維支援，適合在開發階段使用。

EDAS Core 最低只需要 4 核 8g 的機器資源，我們完全可以在本地筆記本上來執行一個離線的 EDAS 平臺，並進行微服務開發。EDAS Core 整體架構如下所示：

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5bae466e3c3a480abce63452596eb486~tplv-k3u1fbpfcp-zoom-1.image "18.png")

這裡進行簡單說明：

-   **EDAS Core**：包含了 EDAS 應用託管能力，支援 Nacos 服務註冊發現和 Minio 持久化儲存，可執行於 Kind、K3s、Docker-Desktop 和 K8s 叢集之上，只需 4c8g 的資源佔用。

-   **開發者工具**：支援使用 Jenkins 外掛進行持續部署、Terraform 進行基礎設施維護、ACT 進行本地開發，併相容 EDAS 開放 API 和 SDK。

-   **安裝介質**：支援透過 Helm、OSS 和 ADP 進行 EDAS Core 安裝。

-   **K8s Cluster**：此 K8s 叢集即為 EDAS Core 託管的叢集，上面執行微服務應用（並自動注入服務治 OneAgent）。

-   **服務整合**：在橫向服務整合上，EDAS Core 支援和 EDAS 商業化應用進行一鍵轉換，並整合了 ARMS 和 SkyWalking 等鏈路跟蹤產品，同時支援使用 ACR 進行映象託管。

下面為 EDAS Core 的執行介面（EDAS 老使用者應該對這個介面比較熟悉了）：

![19.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/002609adeffc494a95278bd24bc4c667~tplv-k3u1fbpfcp-zoom-1.image "19.jpeg")

當前 EDAS Core 處於內部邀測狀態，如果希望使用此能力，歡迎在阿里雲上向 EDAS 產品發起工單諮詢：）。

## 結語

雲原生架構和微服務開發這兩個都是非常流行的技術領域，但“雲原生架構下的微服務開發”這個命題卻甚少見國內廠商提及。EDAS 作為微服務託管領域的先行者很早就開始了雲原生架構的支援，並一直在關注新架構下的微服務開發問題。

從最早的端雲互聯模式開始，到最近推出的雲原生工具箱（CNKit）和 EDAS Core，EDAS 一直站在開發者角度來思考雲原生技術演進所面臨的新問題，並不斷提供解決這些問題的工具和產品。最後，對於這幾個工具產品進行簡單的總結來結束本文：

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2a9431c917134eac9ee13032af4dbd04~tplv-k3u1fbpfcp-zoom-1.image "20.png")

除了以上這些，如果你遇到有意思的場景和工具，請釘釘掃碼（群號：21958624）和我們聯絡吧！

![21.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c488473672f54c1dafb91086c0294778~tplv-k3u1fbpfcp-zoom-1.image "21.jpeg")

## *參考資料*

-   *EDAS：*  
    *<https:>*

-   *雲原生工具箱：*  
    *<https:>*

-   *CLM：*  
    *<https:>*

-   *torsocks：*  
    *<https:>*

-   *docker network connect：*  
    *<https:>*

-   *The Secure Shell (SSH) Connection Protocol：*  
    *<https:>*

-   *Java Networking and Proxies：*  
    *<https:>*

-   *Developing on Kubernetes：*  
    *<https:></https:>*

-   *Arthas：*  
    *<https:>*</https:></https:></https:></https:></https:></https:></https:></https:>

關於平臺工程的開發者工具鏈，你還想加點啥？

相關文章