*作者：* *孤弋（李顏良）*

## 從幾個數字開始說

IDC 預計到 2024 年，由於採用了微服務、容器、動態編排和 DevOps 等技術，新增的生產級雲原生應用在新應用的佔比將從 2020 年的 10% 增加到 60%，其中微服務的 workload 在企業內將超過 80% 。上面的四點是雲原生時代所代表的四個核心技術。其中，我們的開發同學可能對於微服務比較熱衷，從近幾年的趨勢來看，Java 領域的微服務框架日趨成熟，和雲原生的結合也越來越緊密。從 EDAS 中的資料來看，Spring Cloud + Kubernetes 基本上已經成為了微服務架構形態下的主流配搭。但是另外一個資料讓我產生了更多的好奇，就是目前在雲原生場景下有過微服務生產經驗的開發人員不足 8% 。為什麼會是這個樣子？我覺得主要原因有兩個：

首先，是因為本身微服務的學習曲線比較陡峭，好不容易學會精通一個框架，可以進行生產實踐了，可是馬上又面臨了雲原生諸多複雜的概念和複雜環境搭建的技術挑戰，這個兩個因素結合在一起對於每一個人充滿的都是對於未知世界的恐懼，這樣在一些戰略定力不那麼強的團隊中，最後落地效果就不太好。

針對這一條，我覺得大家只需要跟進我們團隊的一些產品和相關課程就行了，雲原生團隊有大量的相關課程在阿里雲大學上供大家學習，很多產品也提供了不錯的工具；同時在各個領域都有很多的數字化轉型的經驗，其中包括微服務在研發團隊中踐行落地的經驗。感興趣的夥伴可以給我們留言，我們可以擇期進行深入的溝通交流。

其次，對於開發人員而言，一直有一個錯誤的認知就是雲原生應用和普通開發的應用是沒有區別的，因為對於開發者而言，還是一樣寫程式碼，還是一樣釋出部署，還是一樣排查診斷。但是這裡還真的不太一樣，哪裡不一樣呢？Heroku 給我們總結出來了 12 條要素，在圈內叫做 12 factor apps，既簡單理解下來，符合這個十二條要素的應用，才能叫做雲原生應用。

### Twelve Factor Apps

這個十二條我列在了這裡，橙色的部分，和我今天的內容相關。下面我每一條做一下簡單的講解：

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

第一條：Codebase，既一份程式碼，多處部署。反過來理解就是多個部署都是一份程式碼，而且 得 是一份程式碼。那什麼時候不是？比如我們直接上生產環境中調整但是忘了同步回來的時候，也就是說，這一條是約束我們的研發流程，保證程式碼在各個環境中的一致性。

第二條：是顯示宣告依賴關係，這一條很好理解，寫 Java 的同學都會使用 ant、maven、gradle 這樣的工具對於一些依賴進行顯示宣告。但是我們往往容易忽略兩點，第一點，是依賴一個 snapshot 版本，最後因為缺少有效的跟蹤而導致線上故障。第二點是一個隱含的依賴，既程式碼執行時環境的依賴系統軟體、執行引擎等應都當是做應用的一部分。

第三條：Config，常規理解是程式碼配置分離。這裡嚴格意義上，是講的是整個執行環境（映象）與配置要做隔離，什麼意思呢？這裡的核心是所依賴配置，是否能在執行啟動的過程中，透過常規的運維手段能進行靈活替換，這些運維手段包括：比如更改環境變數，更改啟動引數，透過分散式配置服務等。

第四條：Backing Services，所有後端服務，其實包括所有發生網路呼叫的情形，我們都需要同一視角去對待。當作附加資源有兩種意思，第一是資源應當準的資源訪問的介面與方式，比如在 Java 中的 URI 介面。還有一種理解就是既然是資源，就需要考慮他的可用性，既然所有後端服務都是資源，那麼我們也要一視同仁的去治理資源的可用性。

第五條：Build,Release,Run 之所以要嚴格分開，這是三個領域我們關注的能力也會不一樣。首先 Build 更注重實效；而 Release 要注重策略；Run 階段更注重流量治理，要儘可能的做到流量無損耗。

第六條：Stateless，單純程式維度的無狀態主要是程式啟動過程中對於資料的依賴。無狀態的目的，是為了更好的做快速伸縮甚至自動的彈性伸縮，Stateless + 啟動無需干預是彈性的關鍵一步。

第七條：Port Binding，是指所有對外暴露的服務都透過埠暴露，這裡是與之相反的是有一些應用透過 unix socket 或者 IPC 之類的訪問方式會極大增加大規模服務運維場景下的複雜度。

第八條：Processes，這裡的理念其實是當服務容量需要彈性時，推薦使用 Scale out，而非程式內的 Scale up，Scale Out 能使應用最大化的利用各種規格下的系統資源，而 Scale Up 的對於 JVM 類似的機制而言，往往會帶來額外的系統開銷和更復雜的 GC 策略。

第九條：Disposability，快速啟動的場景我們應該拉長來看，回到第五條的 Run 階段，Run 階段應該從一個全新的環境準備好開始到程式真正拉起開始服務為止，即包括環境準備、程式包拉取，也包括程式啟動後續的所有流程。而優雅終止則容易忽略類似於訊息、排程任務、執行緒池等後臺任務的處理。

第十條：Dev/Prod parity ，理解容易，落地比較困難。要達成這一點的前提，理論上是要避免一切在環境中人為的操作。雲原生中有一條叫做“不可變基礎設施”，其實和這一條在對應，但是不可變基礎設施指的在執行時需嚴格 follow 在程式碼中宣告的配置，如果要變則需要重新宣告。

第十一條：Logging Event，是推薦日誌當成事件流處理，確切的說就是建議將所有日誌都列印到標準輸出中，而不是使用配置檔案。同時使用專門的集中儲存的日誌服務把日誌內容收集然後統一進行聚合、清理、查詢。這樣不僅運維標準簡單。而且可以解耦本地磁碟依賴，雲原生場景下的應用，要做好磁碟資料隨時可能消失的準備。

第十二條：後臺管理任務指的是一些維護性質的任務，比如清理日誌、快取、訂正某些資料等等。我們應該把這些都當成本身業務的一部分，不能遊離在整個產品體系之外。既同樣需要遵循前面 11 條，如：一份程式碼，顯示宣告，程式碼和配置解耦，無狀態等等。

## 常規開源軟體方式搭建

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

首先，是需要準備一個微服務環境，最為基礎的在微服務場景下需要一個服務註冊發現的元件（如：Nacos），當然隨著我們的業務越來越複雜，需要的元件肯定會越來越多比如：APM 元件、日誌服務元件等等。

然後，我們本地會使用一個 IDE，搭建程式碼工程，開始進行開發。在 Java 中，使用 mvn 進行依賴包的管理。

第三，我們將程式碼提交到 git 倉庫中，所有針對環境變更的操作，都應該遵循 Build/Release/Run 的流程嚴格區分開。現在 Jenkins 可以很好的達到這個效果，在在 Jenkins 中建立一條流水線包含多個任務，分別是：程式構建變異、構建映象。映象上傳；最後針對 K8s 的發起一次對應的 workload 的變更。

## EDAS Core 將開源四步變成一步

EDAS 團隊提供了一種更簡便的方式，它是產自於阿里云云產品 EDAS 的一個簡單的實現，包括 EDAS 中的部分應用週期管理和微服務治理能力，且自帶 webshell，他最簡化的安裝只需要 4C8G。它輕量、簡便，筆記本上可拉起，也可安裝在任意一套標準的 K8s 叢集上，可免費用於開發測試。可以將上述步驟四步變成一步：

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

### 安裝步驟

第一步，我們先將 EDAS Core 的安裝包下載，並解壓。

第二步，將確認好叢集相關的 kubeconfig 檔案並放至對應的位置。

第三步，進入到安裝目錄並執行安裝指令碼，整個過程大概歷時 7-8 分鐘。

使用 EDAS Core 無需準備複雜的 Dockerfile 和映象，只需要依次選擇相對應的環境，並上傳常規的程式包上傳並設定相應的規則引數就好了。而且微服務相關的 Nacos 元件搭建、地址引數配置等都會預設管理好。

同時使用 EDAS 也做了一個官方 Jenkins 外掛專門用來和 Jenkins 對接，只需要在外掛中提供 EDAS 應用 ID，和部署包的地址。就可以完成流水線的對接。

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

## 微服務開發下的痛點

環境搭建只是第一步，微服務的開發中，其中一個痛點是一個系統是自己開發的應用，如何加入到一個原來大的生態叢集中。以及兩個應用需要同步上線一個新的能力，如何在不影響別人的情況下，這個兩個人可以根據一定流量規則進行精準聯調。如下圖：

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

### 端雲互聯

為了解決上面的兩個問題，我們推薦給您的是 Alibaba Cloud Toolkit 中的《端雲互聯》功能，在這個方案中只需要提供一臺 ssh 埠能聯通的跳板機就能很完美的解決上面兩個問題：

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

同時在精準聯調的場景下，可以在 EDAS 中建立一個泳道組並指定好入口應用，在雲上設定好流量規則。同時讓兩個開發人員同時加入到這一個泳道組中。隨後所有滿足規則的流量則會精準的路由到彼此的節點上。

不僅如此，Cloud Toolkit 中還提供了另外一個能力是可以直接從 IDE 中一鍵部署到環境中，也提供了一鍵進入 POD 的 Webshell 能力，方便我們進行排查診斷，此能力近期也會上線在 EDAS 商業版本中。

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

當我們把所有的應用都開發好了之後，我們要面對很多新的環境的準備，比如我們要準備新的測試環境、壓測環境、預發、生產 等等，運維同學每一次準備環境的過程都會隨著應用的增多而備受煎熬。EDAS Core 針對這種場景，特開發了一鍵將所有應用上雲的功能。

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

## 最後的彩蛋：成都環境推出免費版本

為了打消上雲之後有的同學會擔心所花費的商業版本的費用的顧慮，EDAS 在 8 月底的時候，在成都環境公測了一種新的應用形態，這種形態下 EDAS 將管控、微服務治理、APM 監控三個能力進行了分拆，大家可以根據自己的需要靈活定製，歡迎大家試用反饋。

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

如何開發一個標準的雲原生應用？

相關文章