如何通過Serverless提高Java微服務(wù)治理效率

這篇文章將為大家詳細(xì)講解有關(guān)如何通過Serverless提高Java微服務(wù)治理效率，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對相關(guān)知識(shí)有一定的了解。

微服務(wù)治理面臨的挑戰(zhàn)

在業(yè)務(wù)初期，因人手有限，想要快速開發(fā)并上線產(chǎn)品，很多團(tuán)隊(duì)使用單體的架構(gòu)來開發(fā)。但是隨著公司的發(fā)展，會(huì)不斷往系統(tǒng)里面添加新的業(yè)務(wù)功能，系統(tǒng)越來越龐大，需求不斷增加，越來越多的人也會(huì)加入到開發(fā)團(tuán)隊(duì)，代碼庫也會(huì)增速的膨脹，慢慢的單體應(yīng)用變得越來越臃腫，可維護(hù)性和靈活性逐漸降低，維護(hù)成本越來越高。

這個(gè)時(shí)候很多團(tuán)隊(duì)會(huì)把單體應(yīng)用架構(gòu)改為微服務(wù)的架構(gòu)，解決單體應(yīng)用的問題。但隨著微服務(wù)越來越多，運(yùn)維投入會(huì)越來越大，需要保證幾十甚至幾百個(gè)服務(wù)正常運(yùn)行與協(xié)作，這給運(yùn)維帶來了很大的挑戰(zhàn)，下面從軟件生命周期的角度來分析這些挑戰(zhàn)：

• 開發(fā)測試態(tài)如何實(shí)現(xiàn)開發(fā)、測試、線上環(huán)境隔離？如何快速調(diào)試本地變更？如何快速部署本地變更？

• 發(fā)布態(tài)如何設(shè)計(jì)服務(wù)發(fā)布策略？如何無損下線舊版本服務(wù)？如何實(shí)現(xiàn)對新版本服務(wù)灰 度測試？

• 運(yùn)行態(tài)線上問題如何排查？有什么工具可以利用呢？對于服務(wù)質(zhì)量差的節(jié)點(diǎn)如何處理？對于完全不工作的實(shí)例我們?nèi)绾位謴?fù)？

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

Serverless 應(yīng)用引擎

如上圖所示，Serverless 應(yīng)用引擎（SAE）基于神龍 + ECI + VPC + SLB + NAS 等 IaaS 資源，構(gòu)建了一個(gè) Kubernetes 集群，在此之上提供了應(yīng)用管理和微服務(wù)治理的一些能力。它可以針對不同應(yīng)用類型進(jìn)行托管，比如 Spring Cloud 應(yīng)用、Dubbo 應(yīng)用、HSF 應(yīng)用、Web 應(yīng)用和多語言應(yīng)用。并且支持 Cloudtoolkit 插件、云效 RDC / Jenkins 等開發(fā)者工具。在 Serverless 應(yīng)用引擎上，零代碼改造就可以把 Java 微服務(wù)的應(yīng)用遷移到 Serverless。

總的來說，Serverless 應(yīng)用引擎能夠提供成本更優(yōu)、效率更高的一站式應(yīng)用托管方案，零門檻、零改造、零容器基礎(chǔ)，即可享受 Serverless + K8s + 微服務(wù)帶來的技術(shù)紅利。

微服務(wù)治理實(shí)踐

1. 開發(fā)態(tài)實(shí)踐

1）多環(huán)境管理

• 多租戶共有一個(gè)注冊中心，通過不同的租戶對流量進(jìn)行隔離；更進(jìn)一步可以通過網(wǎng)絡(luò) VPC 進(jìn)行環(huán)境隔離；

• 提供環(huán)境級(jí)別的運(yùn)維操作，比如一鍵停止和拉起整個(gè)環(huán)境的功能；

• 提供環(huán)境級(jí)別的配置管理；

• 提供環(huán)境級(jí)別的網(wǎng)關(guān)路由流量管理。

2）云端聯(lián)調(diào)

Serverless 應(yīng)用引擎（SAE）基于 Alibaba CloudToolkit 插件+ 跳板機(jī)可以實(shí)現(xiàn)：

• 本地服務(wù)訂閱并注冊到云端 SAE 內(nèi)置的注冊中心；

• 本地服務(wù)可以和云端 SAE 服務(wù)互相調(diào)用。

如上圖所示，在實(shí)現(xiàn)的時(shí)候用戶需要有一個(gè) ECS 代理服務(wù)器，實(shí)際注冊的是 ECS 代理服務(wù)器到 SAE 的注冊中心，IDEA 在安裝 Cloudtoolkit 插件以后，在啟動(dòng)進(jìn)程時(shí)，會(huì)在本地拉起一個(gè)通道服務(wù)，這個(gè)通道服務(wù)會(huì)連上 ECS 代理服務(wù)器，本地所有的請求都會(huì)轉(zhuǎn)到 ECS 代理服務(wù)器上，云端對服務(wù)的調(diào)用也會(huì)通過 ECS 代理轉(zhuǎn)到本地，這樣就可以以最新的代碼在本地?cái)帱c(diǎn)調(diào)試，這就是云端聯(lián)調(diào)的實(shí)現(xiàn)。

3）構(gòu)建快速開發(fā)體系

代碼在本地完成聯(lián)調(diào)以后，要能快速地通過 Maven 插件和 IDEA-plugin，可以很快地一鍵部署到云端的開發(fā)環(huán)境。

2. 發(fā)布態(tài)實(shí)踐

1）應(yīng)用發(fā)布三板斧

• 可灰度：應(yīng)用在發(fā)布的過程中，運(yùn)維平臺(tái)一定要有發(fā)布策略，包括單批、分批、金絲雀等發(fā)布策略；同時(shí)還要支持流量的灰度；批次間也要允許自動(dòng)/手動(dòng)任選。

• 可觀測：發(fā)布過程可監(jiān)控，白屏化實(shí)時(shí)查看發(fā)布的日志和結(jié)果，及時(shí)定位問題。

• 可回滾：允許人工介入控制發(fā)布流程：異常中止、一鍵回滾。

通過這三點(diǎn)可以讓應(yīng)用發(fā)布做到可灰度、可觀測、可回滾。

2）微服務(wù)無損下線

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

上圖是微服務(wù)注冊和發(fā)行的整個(gè)流程，圖中有服務(wù)消費(fèi)者和服務(wù)提供者，服務(wù)提供者分別有 B1、B2 兩臺(tái)實(shí)例，服務(wù)消費(fèi)者分別有 A1、A2 兩臺(tái)實(shí)例。

B1、B2 把自己注冊到注冊中心，消費(fèi)者從注冊中心刷新服務(wù)列表，發(fā)現(xiàn)服務(wù)提供者 B1、B2，正常情況下，消費(fèi)者開始調(diào)用 B1 或者 B2，服務(wù)提供者 B 需要發(fā)布新版本，先對其中一個(gè)節(jié)點(diǎn)進(jìn)行操作，如 B1，首先停止 Java 進(jìn)程，服務(wù)停止過程又分為主動(dòng)銷毀和被動(dòng)銷毀，主動(dòng)銷毀是準(zhǔn)實(shí)時(shí)的，被動(dòng)銷毀的時(shí)間由不同的注冊中心決定，最差的情況可能需要一分鐘。

如果應(yīng)用是正常停止，Spring Cloud 和 Dubbo 框架的 ShutdownHook 能正常被執(zhí)行，這一步的耗時(shí)基本上是可以忽略不計(jì)的。如果應(yīng)用是非正常停止，比如說直接 Kill-9 的一個(gè)停止，或者是 Docker 鏡像構(gòu)建的時(shí)候，Java 進(jìn)程不是一號(hào)進(jìn)程，且沒有把 Kill 信號(hào)傳遞給應(yīng)用的話，那么服務(wù)提供者不會(huì)主動(dòng)去注銷節(jié)點(diǎn)，它會(huì)等待注冊中心去發(fā)現(xiàn)、被動(dòng)地去感知服務(wù)下線的過程。

當(dāng)微服務(wù)注冊中心感知到服務(wù)下線以后，會(huì)通知服務(wù)消費(fèi)者其中一個(gè)服務(wù)節(jié)點(diǎn)已下線，這里有兩種方式：注冊中心的推送和消費(fèi)者的輪巡。注冊中心刷新服務(wù)列表，感知到提供者已經(jīng)下線一個(gè)節(jié)點(diǎn)，這一步對于 Dubbo 框架來說不存在，但對于 Spring Cloud 來說，它最差的刷新時(shí)間是 30 秒。等消費(fèi)者的服務(wù)列表更新以后，就不再調(diào)用下線節(jié)點(diǎn) B。從第 2 步到第 6 步的過程中，注冊中心如果是 Eureka，最差的情況需要消耗兩分鐘；如果是 Nacos，最差的情況需要消耗 50 秒。

在這個(gè)時(shí)間內(nèi)請求都有可能出現(xiàn)問題，所以發(fā)布的時(shí)候會(huì)出現(xiàn)各種報(bào)錯(cuò)。

經(jīng)過上面的分析，在傳統(tǒng)的發(fā)布流程中，客戶端有一個(gè)服務(wù)端調(diào)用報(bào)錯(cuò)期，這是由于客戶端沒有及時(shí)感知到服務(wù)端下線的實(shí)例造成的，這種情況主要是因?yàn)榉?wù)提供者借助微服務(wù)，通知消費(fèi)者來更新服務(wù)提供的列表造成的。

那能否繞過注冊中心，服務(wù)提供者直接通知服務(wù)消費(fèi)者？答案是肯定的。SAE 做了兩件事情，第一，服務(wù)提供者在應(yīng)用發(fā)布前，會(huì)主動(dòng)向服務(wù)注冊中心注銷應(yīng)用，并將應(yīng)用標(biāo)記為已下線狀態(tài)，將原來停止進(jìn)程階段的注銷變成了 preStop 階段注銷進(jìn)程。

在接收到服務(wù)消費(fèi)者的請求時(shí)，首先會(huì)正常處理本次請求，并且通知服務(wù)消費(fèi)者此節(jié)點(diǎn)已經(jīng)下線，在此之后消費(fèi)者收到通知后，會(huì)立即刷新自己的服務(wù)列表，在此之后服務(wù)消費(fèi)者就不會(huì)再把請求發(fā)到服務(wù)提供者 B1 的實(shí)例上。

通過上面這個(gè)方案，就使得下線感知時(shí)間大大縮短，從原來的分鐘級(jí)別做到準(zhǔn)實(shí)時(shí)的，確保你的應(yīng)用在下線時(shí)能夠做到業(yè)務(wù)無損。

3）基于標(biāo)簽的灰度發(fā)布

發(fā)布策略分為分批發(fā)布和灰度發(fā)布，如何實(shí)現(xiàn)流量的灰度？從上面的架構(gòu)圖中可以看到，在應(yīng)用發(fā)布之前，要配置一個(gè)灰度規(guī)則，比如按 uid 的取模余值 =20 來作為灰度流量的規(guī)則，當(dāng)應(yīng)用發(fā)布的時(shí)候，會(huì)對已發(fā)布的節(jié)點(diǎn)標(biāo)識(shí)為一個(gè)灰度的版本，在這樣的情況下，當(dāng)有流量進(jìn)來時(shí)，微服務(wù)網(wǎng)關(guān)和消費(fèi)者都會(huì)通過配置中心拿到在治理中心配置的灰度規(guī)則。

消費(fèi)者的 Agent 也會(huì)從注冊中心拉取它所依賴的服務(wù)的一些信息，當(dāng)一個(gè)流量進(jìn)到消費(fèi)者時(shí)，會(huì)按照灰度規(guī)則來做匹配，如果是灰度的流量，它會(huì)轉(zhuǎn)化到灰度的機(jī)器上；如果是正常流量，它會(huì)轉(zhuǎn)到正常的機(jī)器上，這是基于標(biāo)簽實(shí)現(xiàn)的灰度發(fā)布的具體邏輯。

3. 運(yùn)行態(tài)實(shí)踐

1）強(qiáng)大的應(yīng)用監(jiān)控 & 診斷能力

運(yùn)行態(tài)的實(shí)例，服務(wù)的運(yùn)行過程中會(huì)出現(xiàn)這樣或者那樣的問題，怎么去排查和解決它？

排查和解決的前提是必須具有強(qiáng)大的應(yīng)用監(jiān)控能力和診斷能力，SAE 集成了云產(chǎn)品 ARMS，能夠讓跑在上面的 Java 微服務(wù)看到應(yīng)用的調(diào)用關(guān)系拓?fù)鋱D，可以定位到你的 MySQL 慢服務(wù)方法的調(diào)用堆棧，進(jìn)而定位到代碼級(jí)別的問題。

比如一個(gè)請求響應(yīng)慢，業(yè)務(wù)出現(xiàn)問題，它可以定位到是哪個(gè)請求、哪個(gè)服務(wù)、服務(wù)的哪行代碼出現(xiàn)了問題，這樣就能為解決問題帶來很多便利?？偟膩碚f，就是我們要先有監(jiān)控報(bào)警的能力，才能幫助我們更好地診斷服務(wù)運(yùn)營過程中的問題。

2）故障隔離和服務(wù)恢復(fù)

上面說到我們通過監(jiān)控、報(bào)警來排查、解決遇到的問題，那我們的系統(tǒng)能否主動(dòng)去做一些事情呢？SAE 作為一個(gè) Serverless 平臺(tái)，具備很多自運(yùn)維的能力，下圖中有兩個(gè)場景：

• 場景 1：某應(yīng)用運(yùn)營過程中，某幾臺(tái)機(jī)器由于磁盤滿或者宿主機(jī)資源爭搶，導(dǎo)致 load 很高或網(wǎng)絡(luò)狀態(tài)差，客戶端出現(xiàn)調(diào)用超時(shí)或者報(bào)錯(cuò)。

面對這種情況，SAE 提供了服務(wù)治理能力，即離群摘除，它可以配置，當(dāng)網(wǎng)絡(luò)超時(shí)嚴(yán)重或者后端服務(wù) 5xx 報(bào)錯(cuò)達(dá)到一定比例時(shí)，可以選擇把該節(jié)點(diǎn)從消費(fèi)端服務(wù)列表中摘除，從而使得有問題的機(jī)器不再響應(yīng)業(yè)務(wù)的請求，很好地保證業(yè)務(wù)的 SLA。

• 場景 2：某應(yīng)用運(yùn)行過程中，因突發(fā)流量導(dǎo)致內(nèi)存耗盡，觸發(fā) OOM。

這種情況下，通過 SAE 這種 Serverless 應(yīng)用引擎，節(jié)點(diǎn)在配置健康檢查以后，節(jié)點(diǎn)里的容器是可以重新拉起的，可以做到快速對進(jìn)程進(jìn)行恢復(fù)。

3）精準(zhǔn)容量+限流降級(jí)+極致彈性

基于 Serverless Paas 平臺(tái) SAE 和其他產(chǎn)品的互動(dòng)，來達(dá)到整個(gè)運(yùn)維態(tài)的閉環(huán)。

用戶在使用的時(shí)候，可以運(yùn)用 PTS 壓測工具構(gòu)造場景，然后得出來一些閾值。比如可以對流量高峰所需要消耗的資源進(jìn)行預(yù)估，這時(shí)就可以根據(jù)這些閾值設(shè)計(jì)彈性策略。當(dāng)業(yè)務(wù)系統(tǒng)達(dá)到請求比例時(shí)，就可以按照所設(shè)置的彈性策略來擴(kuò)縮容自己的機(jī)器。

擴(kuò)縮容在時(shí)間上，有可能還跟不上處理大批量的請求，這時(shí)可以通過和 AHAS 的互動(dòng)，配置限流降級(jí)的能力。當(dāng)有突發(fā)大流量時(shí)，首先可以用 AHAS 的能力把一些流量擋在門外，然后同時(shí)觸發(fā) SAE 上應(yīng)用的擴(kuò)容策略去擴(kuò)容實(shí)例，當(dāng)這些實(shí)例擴(kuò)容完成之后，整個(gè)機(jī)器的平均負(fù)載會(huì)下降，流量又重新放進(jìn)來。從突發(fā)大流量到限流降級(jí)再到擴(kuò)容，最后到流量達(dá)到正常狀態(tài)，這就是“精準(zhǔn)容量+限流降級(jí)+極致彈性”的最佳實(shí)踐模型

本文首先按照提出問題、解決問題的思路，闡述微服務(wù)在開發(fā)、發(fā)布和運(yùn)行態(tài)是如何解決問題的；再介紹如何通過 Serverless 產(chǎn)品和其他產(chǎn)品的互動(dòng)，從而實(shí)現(xiàn)精準(zhǔn)流量、限流降級(jí)和極致彈性。

• 開發(fā)測試態(tài)通過注冊中心多租戶和網(wǎng)絡(luò)環(huán)境的隔離，并提供環(huán)境級(jí)別的能力；通過云端聯(lián)調(diào)技術(shù)來快速調(diào)式本地變更；如果 IDE 插件快速部署本地變更。

• 發(fā)布態(tài)運(yùn)維平臺(tái)針對應(yīng)用發(fā)布需要具備可灰度、可觀測、 可回滾；通過 MSE agent 能力實(shí)現(xiàn)服務(wù)無損下線；通過標(biāo)簽路由提供了線上流量灰度測試的能力。

• 運(yùn)行態(tài)建立強(qiáng)大應(yīng)用監(jiān)控和診斷能力；對服務(wù)質(zhì)量差的節(jié)點(diǎn)具備離群摘除能力；對已經(jīng)不工作的實(shí)例通過配置健康檢查能夠做到實(shí)例重啟恢復(fù)業(yè)務(wù)；提供了精準(zhǔn)容量+限流降級(jí)+極致彈性模型。

關(guān)于如何通過Serverless提高Java微服務(wù)治理效率就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。