![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/e92b78a083cd41a985c94a2dba170239.png)

作者 | 王科懷（行松）
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/C_MbxxvchQNfa6FxIn3QHw)

# 微服務治理面臨的挑戰

在業務初期，因人手有限，想要快速開發並上線產品，很多團隊使用單體的架構來開發。但是隨著公司的發展，會不斷往系統裡面新增新的業務功能，系統越來越龐大，需求不斷增加，越來越多的人也會加入到開發團隊，程式碼庫也會增速的膨脹，慢慢的單體應用變得越來越臃腫，可維護性和靈活性逐漸降低，維護成本越來越高。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/0947a38407594314a1d70a0d3a76303d.png)

這個時候很多團隊會把單體應用架構改為微服務的架構，解決單體應用的問題。但隨著微服務越來越多，運維投入會越來越大，需要保證幾十甚至幾百個服務正常執行與協作，這給運維帶來了很大的挑戰，下面從軟體生命週期的角度來分析這些挑戰：

- 開發測試態

- 如何實現開發、測試、線上環境隔離？
   - 如何快速除錯本地變更？
   - 如何快速部署本地變更？

- 釋出態

- 如何設計服務釋出策略？
   - 如何無損下線舊版本服務？
   - 如何實現對新版本服務灰 度測試？

- 執行態

- 線上問題如何排查？有什麼工具可以利用呢？
   - 對於服務質量差的節點如何處理？
   - 對於完全不工作的例項我們如何恢復？

面對以上問題，Serverless 應用引擎在這方面都做了哪些工作？

# Serverless 應用引擎

![2.png](https://ucc.alicdn.com/pic/developer-ecology/807af2579ff8404bbc430d669798162e.png)

如上圖所示，Serverless 應用引擎（SAE）基於神龍 + ECI + VPC + SLB + NAS 等 IaaS 資源，構建了一個 Kubernetes 叢集，在此之上提供了應用管理和微服務治理的一些能力。它可以針對不同應用型別進行託管，比如 Spring Cloud 應用、Dubbo 應用、HSF 應用、Web 應用和多語言應用。並且支援 Cloudtoolkit 外掛、雲效 RDC / Jenkins 等開發者工具。在 Serverless 應用引擎上，零程式碼改造就可以把 Java 微服務的應用遷移到 Serverless。

總的來說，Serverless 應用引擎能夠提供成本更優、效率更高的一站式應用託管方案，零門檻、零改造、零容器基礎，即可享受 Serverless + K8s + 微服務帶來的技術紅利。

# 微服務治理實踐

## 1. 開發態實踐

### 1）多環境管理

![3.png](https://ucc.alicdn.com/pic/developer-ecology/fda5c079bb1a4d29a9ab888e5d06089f.png)

- 多租戶共有一個註冊中心，透過不同的租戶對流量進行隔離；更進一步可以透過網路 VPC 進行環境隔離；
- 提供環境級別的運維操作，比如一鍵停止和拉起整個環境的功能；
- 提供環境級別的配置管理；
- 提供環境級別的閘道器路由流量管理。

### 2）雲端聯調

Serverless 應用引擎（SAE）基於 Alibaba CloudToolkit 外掛+ 跳板機可以實現：

- 本地服務訂閱並註冊到雲端 SAE 內建的註冊中心；
- 本地服務可以和雲端 SAE 服務互相呼叫。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/7a2fb15ba9c841e3911c6835397520d5.png)

如上圖所示，在實現的時候使用者需要有一個 ECS 代理伺服器，實際註冊的是 ECS 代理伺服器到 SAE 的註冊中心，IDEA 在安裝 Cloudtoolkit 外掛以後，在啟動程式時，會在本地拉起一個通道服務，這個通道服務會連上 ECS 代理伺服器，本地所有的請求都會轉到 ECS 代理伺服器上，雲端對服務的呼叫也會透過 ECS 代理轉到本地，這樣就可以以最新的程式碼在本地斷點除錯，這就是雲端聯調的實現。

### 3）構建快速開發體系

![5.png](https://ucc.alicdn.com/pic/developer-ecology/d23c6c672fae4de49cb959ea69dbd14f.png)

程式碼在本地完成聯調以後，要能快速地透過 Maven 外掛和 IDEA-plugin，可以很快地一鍵部署到雲端的開發環境。

## 2. 釋出態實踐

### 1）應用釋出三板斧

![6.png](https://ucc.alicdn.com/pic/developer-ecology/2d81c851975843978bb77737b948666f.png)

![7.png](https://ucc.alicdn.com/pic/developer-ecology/d354aec65086433a83d94c8a70c9c7fc.png)

- 可灰度：應用在釋出的過程中，運維平臺一定要有釋出策略，包括單批、分批、金絲雀等釋出策略；同時還要支援流量的灰度；批次間也要允許自動/手動任選。
- 可觀測：釋出過程可監控，白屏化實時檢視釋出的日誌和結果，及時定位問題。
- 可回滾：允許人工介入控制釋出流程：異常中止、一鍵回滾。

透過這三點可以讓應用釋出做到可灰度、可觀測、可回滾。

### 2）微服務無損下線

在版本更換的過程中，SAE 是如何保證舊版本的微服務流量可以無損地下線掉？

![8.png](https://ucc.alicdn.com/pic/developer-ecology/b4144732323f402f9aaa4640d086c74a.png)

上圖是微服務註冊和發行的整個流程，圖中有服務消費者和服務提供者，服務提供者分別有 B1、B2 兩臺例項，服務消費者分別有 A1、A2 兩臺例項。

B1、B2 把自己註冊到註冊中心，消費者從註冊中心重新整理服務列表，發現服務提供者 B1、B2，正常情況下，消費者開始呼叫 B1 或者 B2，服務提供者 B 需要釋出新版本，先對其中一個節點進行操作，如 B1，首先停止 Java 程式，服務停止過程又分為主動銷燬和被動銷燬，主動銷燬是準實時的，被動銷燬的時間由不同的註冊中心決定，最差的情況可能需要一分鐘。

如果應用是正常停止，Spring Cloud 和 Dubbo 框架的 ShutdownHook 能正常被執行，這一步的耗時基本上是可以忽略不計的。如果應用是非正常停止，比如說直接 Kill-9 的一個停止，或者是 Docker 映象構建的時候，Java 程式不是一號程式，且沒有把 Kill 訊號傳遞給應用的話，那麼服務提供者不會主動去登出節點，它會等待註冊中心去發現、被動地去感知服務下線的過程。

當微服務註冊中心感知到服務下線以後，會通知服務消費者其中一個服務節點已下線，這裡有兩種方式：註冊中心的推送和消費者的輪巡。註冊中心重新整理服務列表，感知到提供者已經下線一個節點，這一步對於 Dubbo 框架來說不存在，但對於 Spring Cloud 來說，它最差的重新整理時間是 30 秒。等消費者的服務列表更新以後，就不再呼叫下線節點 B。從第 2 步到第 6 步的過程中，註冊中心如果是 Eureka，最差的情況需要消耗兩分鐘；如果是 Nacos，最差的情況需要消耗 50 秒。

在這個時間內請求都有可能出現問題，所以釋出的時候會出現各種報錯。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/8fe097c5f2924e49a4b9f934d6a6bf74.png)

經過上面的分析，在傳統的釋出流程中，客戶端有一個服務端呼叫報錯期，這是由於客戶端沒有及時感知到服務端下線的例項造成的，這種情況主要是因為服務提供者藉助微服務，通知消費者來更新服務提供的列表造成的。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/7345ba25e3a141b0a8174c2ed1041602.png)

那能否繞過註冊中心，服務提供者直接通知服務消費者？答案是肯定的。SAE 做了兩件事情，第一，服務提供者在應用釋出前，會主動向服務註冊中心登出應用，並將應用標記為已下線狀態，將原來停止程式階段的登出變成了 preStop 階段登出程式。

在接收到服務消費者的請求時，首先會正常處理本次請求，並且通知服務消費者此節點已經下線，在此之後消費者收到通知後，會立即重新整理自己的服務列表，在此之後服務消費者就不會再把請求發到服務提供者 B1 的例項上。

透過上面這個方案，就使得下線感知時間大大縮短，從原來的分鐘級別做到準實時的，確保你的應用在下線時能夠做到業務無損。

### 3）基於標籤的灰度釋出

![11.png](https://ucc.alicdn.com/pic/developer-ecology/3b68fa8dc1da4d5995da14a97de78439.png)

釋出策略分為分批發布和灰度釋出，如何實現流量的灰度？從上面的架構圖中可以看到，在應用釋出之前，要配置一個灰度規則，比如按 uid 的取模餘值 =20 來作為灰度流量的規則，當應用釋出的時候，會對已釋出的節點標識為一個灰度的版本，在這樣的情況下，當有流量進來時，微服務閘道器和消費者都會透過配置中心拿到在治理中心配置的灰度規則。

消費者的 Agent 也會從註冊中心拉取它所依賴的服務的一些資訊，當一個流量進到消費者時，會按照灰度規則來做匹配，如果是灰度的流量，它會轉化到灰度的機器上；如果是正常流量，它會轉到正常的機器上，這是基於標籤實現的灰度釋出的具體邏輯。

## 3. 執行態實踐

### 1）強大的應用監控 & 診斷能力

![12.png](https://ucc.alicdn.com/pic/developer-ecology/20470bde747b417489c2afc9adfef5a2.png)

執行態的例項，服務的執行過程中會出現這樣或者那樣的問題，怎麼去排查和解決它？

排查和解決的前提是必須具有強大的應用監控能力和診斷能力，SAE 整合了雲產品 ARMS，能夠讓跑在上面的 Java 微服務看到應用的呼叫關係拓撲圖，可以定位到你的 MySQL 慢服務方法的呼叫堆疊，進而定位到程式碼級別的問題。

比如一個請求響應慢，業務出現問題，它可以定位到是哪個請求、哪個服務、服務的哪行程式碼出現了問題，這樣就能為解決問題帶來很多便利。總的來說，就是我們要先有監控報警的能力，才能幫助我們更好地診斷服務運營過程中的問題。

### 2）故障隔離和服務恢復

上面說到我們透過監控、報警來排查、解決遇到的問題，那我們的系統能否主動去做一些事情呢？SAE 作為一個 Serverless 平臺，具備很多自運維的能力，下圖中有兩個場景：

![13.png](https://ucc.alicdn.com/pic/developer-ecology/503b6bc1e3fa41dc845b9129bc8c9f8c.png)

- 場景 1：某應用運營過程中，某幾臺機器由於磁碟滿或者宿主機資源爭搶，導致 load 很高或網路狀態差，客戶端出現呼叫超時或者報錯。

面對這種情況，SAE 提供了服務治理能力，即離群摘除，它可以配置，當網路超時嚴重或者後端服務 5xx 報錯達到一定比例時，可以選擇把該節點從消費端服務列表中摘除，從而使得有問題的機器不再響應業務的請求，很好地保證業務的 SLA。

- 場景 2：某應用執行過程中，因突發流量導致記憶體耗盡，觸發 OOM。

這種情況下，透過 SAE 這種 Serverless 應用引擎，節點在配置健康檢查以後，節點裡的容器是可以重新拉起的，可以做到快速對程式進行恢復。

### 3）精準容量+限流降級+極致彈性

![14.png](https://ucc.alicdn.com/pic/developer-ecology/e9a628bf26ab42ed92cd6a0474c944ca.png)

基於 Serverless Paas 平臺 SAE 和其他產品的互動，來達到整個運維態的閉環。

使用者在使用的時候，可以運用 PTS 壓測工具構造場景，然後得出來一些閾值。比如可以對流量高峰所需要消耗的資源進行預估，這時就可以根據這些閾值設計彈性策略。當業務系統達到請求比例時，就可以按照所設定的彈性策略來擴縮容自己的機器。

擴縮容在時間上，有可能還跟不上處理大批次的請求，這時可以透過和 AHAS 的互動，配置限流降級的能力。當有突發大流量時，首先可以用 AHAS 的能力把一些流量擋在門外，然後同時觸發 SAE 上應用的擴容策略去擴容例項，當這些例項擴容完成之後，整個機器的平均負載會下降，流量又重新放進來。從突發大流量到限流降級再到擴容，最後到流量達到正常狀態，這就是“精準容量+限流降級+極致彈性”的最佳實踐模型。

# 總結

本文首先按照提出問題、解決問題的思路，闡述微服務在開發、釋出和執行態是如何解決問題的；再介紹如何透過 Serverless 產品和其他產品的互動，從而實現精準流量、限流降級和極致彈性。

- 開發測試態

- 透過註冊中心多租戶和網路環境的隔離，並提供環境級別的能力；
   - 透過雲端聯調技術來快速調式本地變更；
   - 如果 IDE 外掛快速部署本地變更。

- 釋出態

- 運維平臺針對應用釋出需要具備可灰度、可觀測、 可回滾；
   - 透過 MSE agent 能力實現服務無損下線；
   - 透過標籤路由提供了線上流量灰度測試的能力。

- 執行態

- 建立強大應用監控和診斷能力；
   - 對服務質量差的節點具備離群摘除能力；
   - 對已經不工作的例項透過配置健康檢查能夠做到例項重啟恢復業務；
   - 提供了精準容量+限流降級+極致彈性模型。

### **作者簡介**

**王科懷**，花名：行松，阿里雲 SAE 技術研發，負責 SAE 產品 Runtime 層技術架構設計，專注於微服務、Serverless、應用託管領域，基於雲原生技術持續打造新一代應用託管平臺。

> 本文整理自【Serverless Live 系列直播】2 月 1 日場
> 直播回看連結：[https://developer.aliyun.com/topic/serverless/practices](https://developer.aliyun.com/topic/serverless/practices)

### Serverless 電子書下載

**本書亮點**：

- 從架構演進開始，介紹 Serverless 架構及技術選型構建 Serverless 思維；
- 瞭解業界流行的 Serverless 架構執行原理；
- 掌握 10 大 Serverless 真實落地案例，活學活用。

**下載連結**：[https://developer.aliyun.com/topic/download?id=1128](https://developer.aliyun.com/topic/download?id=1128)

如何透過 Serverless 提高 Java 微服務治理效率？

相關文章