如何經過 Serverless 提升 Java 微服務治理效率？

做者 | 王科懷（行鬆） 來源 | 阿里巴巴雲原生公衆號

微服務治理面臨的挑戰

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

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

• 開發測試態

  • 如何實現開發、測試、線上環境隔離？
  • 如何快速調試本地變動？
  • 如何快速部署本地變動？

• 發佈態

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

• 運行態

  • 線上問題如何排查？有什麼工具能夠利用呢？
  • 對於服務質量差的節點如何處理？
  • 對於徹底不工做的實例咱們如何恢復？

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

Serverless 應用引擎

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

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

微服務治理實踐

1. 開發態實踐

1）多環境管理

• 多租戶共有一個註冊中心，經過不一樣的租戶對流量進行隔離；更進一步能夠經過網絡 VPC 進行環境隔離；
• 提供環境級別的運維操做，好比一鍵中止和拉起整個環境的功能；
• 提供環境級別的配置管理；
• 提供環境級別的網關路由流量管理。

2）雲端聯調

Serverless 應用引擎（SAE）基於 Alibaba CloudToolkit 插件+ 跳板機能夠實現：

• 本地服務訂閱並註冊到雲端 SAE 內置的註冊中心；
• 本地服務能夠和雲端 SAE 服務互相調用。

如上圖所示，在實現的時候用戶須要有一個 ECS 代理服務器，實際註冊的是 ECS 代理服務器到 SAE 的註冊中心，IDEA 在安裝 Cloudtoolkit 插件之後，在啓動進程時，會在本地拉起一個通道服務，這個通道服務會連上 ECS 代理服務器，本地全部的請求都會轉到 ECS 代理服務器上，雲端對服務的調用也會經過 ECS 代理轉到本地，這樣就能夠以最新的代碼在本地斷點調試，這就是雲端聯調的實現。

3）構建快速開發體系

代碼在本地完成聯調之後，要能快速地經過 Maven 插件和 IDEA-plugin，能夠很快地一鍵部署到雲端的開發環境。

2. 發佈態實踐

1）應用發佈三板斧

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

經過這三點可讓應用發佈作到可灰度、可觀測、可回滾。

2）微服務無損下線

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

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

B一、B2 把本身註冊到註冊中心，消費者從註冊中心刷新服務列表，發現服務提供者 B一、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 秒。

在這個時間內請求都有可能出現問題，因此發佈的時候會出現各類報錯。

通過上面的分析，在傳統的發佈流程中，客戶端有一個服務端調用報錯期，這是因爲客戶端沒有及時感知到服務端下線的實例形成的，這種狀況主要是由於服務提供者藉助微服務，通知消費者來更新服務提供的列表形成的。

那可否繞過註冊中心，服務提供者直接通知服務消費者？答案是確定的。SAE 作了兩件事情，第一，服務提供者在應用發佈前，會主動向服務註冊中心註銷應用，並將應用標記爲已下線狀態，將原來中止進程階段的註銷變成了 preStop 階段註銷進程。

在接收到服務消費者的請求時，首先會正常處理本次請求，而且通知服務消費者此節點已經下線，在此以後消費者收到通知後，會當即刷新本身的服務列表，在此以後服務消費者就不會再把請求發到服務提供者 B1 的實例上。

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

3）基於標籤的灰度發佈

發佈策略分爲分批發布和灰度發佈，如何實現流量的灰度？從上面的架構圖中能夠看到，在應用發佈以前，要配置一個灰度規則，好比按 uid 的取模餘值 =20 來做爲灰度流量的規則，當應用發佈的時候，會對已發佈的節點標識爲一個灰度的版本，在這樣的狀況下，當有流量進來時，微服務網關和消費者都會經過配置中心拿到在治理中心配置的灰度規則。

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

3. 運行態實踐

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

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

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

好比一個請求響應慢，業務出現問題，它能夠定位到是哪一個請求、哪一個服務、服務的哪行代碼出現了問題，這樣就能爲解決問題帶來不少便利。總的來講，就是咱們要先有監控報警的能力，才能幫助咱們更好地診斷服務運營過程當中的問題。

2）故障隔離和服務恢復

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

• 場景 1：某應用運營過程當中，某幾臺機器因爲磁盤滿或者宿主機資源爭搶，致使 load 很高或網絡狀態差，客戶端出現調用超時或者報錯。

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

• 場景 2：某應用運行過程當中，因突發流量致使內存耗盡，觸發 OOM。

這種狀況下，經過 SAE 這種 Serverless 應用引擎，節點在配置健康檢查之後，節點裏的容器是能夠從新拉起的，能夠作到快速對進程進行恢復。

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

基於 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

Serverless 電子書下載

本書亮點：

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

下載連接：https://developer.aliyun.com/topic/download?id=1128