Serverless 下的微服務(wù)實(shí)踐

作者 | 弈川?

本文整理自《ServerlessLive 直播課》，關(guān)注 Serverless 公眾號(hào)，回復(fù)“927”，即可獲取本堂課程 PPT！

在互聯(lián)網(wǎng)早期即 Web 1.0 的時(shí)代，當(dāng)時(shí)流行的是單體應(yīng)用，研發(fā)團(tuán)隊(duì)比較小，主要是外部網(wǎng)頁(yè)，然后新聞門(mén)戶(hù)等；到了新世紀(jì)的互聯(lián)網(wǎng)時(shí)期 Web 2.0 時(shí)代，網(wǎng)民數(shù)量大幅激增，相繼出現(xiàn)電商、社交這樣巨無(wú)霸級(jí)別的互聯(lián)網(wǎng)產(chǎn)品，出現(xiàn)了幾百人甚至上千的研發(fā)團(tuán)隊(duì)在一個(gè)場(chǎng)景下，流量及業(yè)務(wù)復(fù)雜度相較于上一個(gè)時(shí)代有了質(zhì)的變化，因此單體服務(wù)的弊端：例如研發(fā)效率等問(wèn)題便顯現(xiàn)出來(lái)。

此時(shí)出現(xiàn)了一個(gè)叫 SOA 的架構(gòu)，其架構(gòu)思路與微服務(wù)很像，它有類(lèi)似于 ESB 這種中心化組件，阿里的 HSF，包括后來(lái)開(kāi)源的 Double，都是在此階段誕生的。

移動(dòng)互聯(lián)網(wǎng)時(shí)代出現(xiàn)之后，各種各樣的 APP 誕生，生活也開(kāi)始全面互聯(lián)網(wǎng)化。大流量高并發(fā)以及規(guī)模化的研發(fā)團(tuán)隊(duì)變得越來(lái)越尋常，相應(yīng)對(duì)高技術(shù)、生產(chǎn)力的要求也在逐步提升，此時(shí)微服務(wù)的概念應(yīng)運(yùn)而生。

微服務(wù)其實(shí)一直貫穿在整個(gè)架構(gòu)的發(fā)展過(guò)程中。在 Java 的技術(shù)棧，類(lèi)似于 Spring Cloud 、Double 這些框架都已經(jīng)非常流行。不難發(fā)現(xiàn)整個(gè)社會(huì)已經(jīng)步入數(shù)字化高速發(fā)展階段，此時(shí)更大的問(wèn)題蘊(yùn)含其中，如流量升高、應(yīng)用復(fù)雜度提升，研發(fā)團(tuán)隊(duì)擴(kuò)大、對(duì)于效率的要求增高等等。

大部分的公司或早期業(yè)務(wù)都會(huì)經(jīng)歷過(guò)這樣的過(guò)程（如圖所示）：先是客戶(hù)端，此時(shí)需要通過(guò)一個(gè)入口訪(fǎng)問(wèn)，上圖中 SLB 是阿里云一個(gè)負(fù)載均衡服務(wù)，它相當(dāng)于一個(gè)網(wǎng)絡(luò)入口，可以對(duì)應(yīng)到 ECS（ECS 為阿里云的虛擬機(jī)）打到對(duì)應(yīng)的單體的服務(wù)中，而此時(shí)他們會(huì)共用一個(gè)數(shù)據(jù)庫(kù)，這是第一個(gè)時(shí)期。

到第二個(gè)時(shí)期 SOA 架構(gòu)：此時(shí)出現(xiàn)了分治的思想，它會(huì)將一些業(yè)務(wù)進(jìn)行拆分。但它并未做到服務(wù)與底層的拆分，如存儲(chǔ)數(shù)據(jù)庫(kù)的拆分，其本質(zhì)上還是共用一套數(shù)據(jù)庫(kù)，因此它還是單體的架構(gòu)。

而到微服務(wù)時(shí)期，如若客戶(hù)端通過(guò) SLB 訪(fǎng)問(wèn)網(wǎng)關(guān)（如圖所示），隨后會(huì)轉(zhuǎn)發(fā)對(duì)應(yīng)的服務(wù)，且服務(wù)與服務(wù)之間會(huì)產(chǎn)生一些調(diào)用；每個(gè)服務(wù)會(huì)對(duì)應(yīng)一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)或緩存，且每個(gè)服務(wù)會(huì)通過(guò)類(lèi)似于 Nacos 這種的服務(wù)進(jìn)行注冊(cè)、發(fā)現(xiàn)以及配置管理。

微服務(wù)引入之后，雖然解決了架構(gòu)業(yè)務(wù)的分離，能夠讓研發(fā)團(tuán)隊(duì)在某一個(gè)領(lǐng)域、業(yè)務(wù)能夠做到精專(zhuān)，不過(guò)從整體架構(gòu)來(lái)看便會(huì)發(fā)現(xiàn)，相較于之前它其實(shí)是更為復(fù)雜的，所以也帶來(lái)一些運(yùn)維上的問(wèn)題。

在單體架構(gòu)中于單體應(yīng)用而言，會(huì)發(fā)生邊界不清晰、模塊耦合、共享代碼庫(kù)容易沖突的問(wèn)題，同時(shí)如果團(tuán)隊(duì)規(guī)模較大，此時(shí)的協(xié)作效率也會(huì)相對(duì)較低。但是微服務(wù)架構(gòu)的核心就是解耦，如果做到拆分之后的解耦，就可以釋放開(kāi)發(fā)團(tuán)隊(duì)效率。

云原生是一個(gè)很宏觀的概念，如果我們以微服務(wù)為起點(diǎn)來(lái)看云原生給微服務(wù)帶來(lái)的變化與演進(jìn)，可以更好地幫助我們理解什么是云原生。

微服務(wù)和單體應(yīng)用的本質(zhì)是什么呢？（如圖所示）它其實(shí)是把單體應(yīng)用從一個(gè)巨型的應(yīng)用拆分成數(shù)個(gè)微小的服務(wù)，協(xié)作來(lái)完成原先單體應(yīng)用等效的業(yè)務(wù)服務(wù)。此時(shí)微服務(wù)與微服務(wù)之間會(huì)形成一個(gè)依賴(lài)關(guān)系，它需要部署至一個(gè)或多個(gè)資源上，這時(shí)的資源便是計(jì)算資源。

過(guò)去單體應(yīng)用與資源之間的關(guān)系十分簡(jiǎn)單，單體應(yīng)用的協(xié)同也都是一些內(nèi)部協(xié)同，不存在外部動(dòng)態(tài)的依賴(lài)。但架構(gòu)轉(zhuǎn)換到微服務(wù)之后，由于外部依賴(lài)和節(jié)點(diǎn)數(shù)量的爆炸，整個(gè)體系會(huì)變成網(wǎng)狀，管理起來(lái)十分復(fù)雜。超過(guò) 50% 的企業(yè)會(huì)覺(jué)得采用微服務(wù)架構(gòu)，最大挑戰(zhàn)是復(fù)雜的運(yùn)維，即整個(gè)服務(wù)生命周期的管理。

如今，比較公認(rèn)的一點(diǎn)是云原生的根基在于容器與容器的管理編排（K8S）。而容器與 K8S 的技術(shù)能夠幫助我們解決微服務(wù)體系中所存在繁雜運(yùn)維的問(wèn)題。

首先不同的微服務(wù)之間會(huì)存在異構(gòu)，即一個(gè)團(tuán)隊(duì)，在微服務(wù)體系下為了發(fā)揮最大效能，可能會(huì)允許不同小團(tuán)隊(duì)采用不同的編程語(yǔ)言、運(yùn)行環(huán)境去運(yùn)行微服務(wù)。因此最初我們?cè)谶\(yùn)維和管理微服務(wù)時(shí)，是沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)去處理這些異構(gòu)環(huán)境的。這便促發(fā)了云原生容器技術(shù)的流行，因?yàn)檫@項(xiàng)技術(shù)的作用就是通過(guò)一層標(biāo)準(zhǔn)化的運(yùn)行時(shí)和封裝來(lái)限制微服務(wù)部署。這樣從生命周期與管理角度來(lái)看，每一個(gè)微服務(wù)之間的差異變少，十分有利于資源的調(diào)度。

隨后。基于容器調(diào)度衍生出了容器平臺(tái)。容器平臺(tái)就是管理容器的，就 K8S 來(lái)說(shuō)，它可以標(biāo)準(zhǔn)便捷地將微服務(wù)運(yùn)行到底層的資源上，隨后存儲(chǔ)計(jì)算網(wǎng)絡(luò)可以通過(guò) K8S 這層來(lái)進(jìn)行統(tǒng)一封裝，一層抽象與封裝，它類(lèi)似于云原生時(shí)代的操作系統(tǒng)。

它具體會(huì)提供哪些幫助呢？在 K8S 中有個(gè)概念叫 POD ，POD 是一組容器的結(jié)合，與微服務(wù)實(shí)體生命周期的耦合，在一個(gè) POD 里面，它可以運(yùn)行一個(gè)或者是多個(gè)容器。

采用微服務(wù)架構(gòu)時(shí)，一般會(huì)把微服務(wù)運(yùn)行的主體放在主容器中，也就是把微服務(wù)執(zhí)行的主邏輯放在主容器里面。此時(shí)主容器的生命周期與 POD 的生命周期是完全耦合的，POD 什么時(shí)候消亡，微服的運(yùn)行主體便何時(shí)消亡。除此之外我們還會(huì)運(yùn)行一些邊車(chē)容器— Sidecar，它主要是為主容器提供輔助功能，如日志采集、網(wǎng)絡(luò)代理、身份鑒權(quán)等?。此時(shí)的微服務(wù)便除了提供自身核心業(yè)務(wù)以外，它還可以動(dòng)態(tài)的提供額外輔助能力，這讓微服務(wù)的管理變得更加穩(wěn)定與便捷。

POD 這個(gè)模型還提供了許多非常有用的功能，比如狀態(tài)信息。（狀態(tài)信息是指：POD 會(huì)提供一個(gè)標(biāo)準(zhǔn)的接口來(lái)顯示運(yùn)行時(shí)的狀態(tài)）通過(guò)這個(gè)信息狀態(tài)可以出判斷微服務(wù)或是容器的運(yùn)行狀態(tài)，如它是否處于運(yùn)行中、業(yè)務(wù)是否已經(jīng)準(zhǔn)備好可以迎接流量接入，POD 為整體的穩(wěn)定性提供了保障。另一個(gè)是地址服務(wù)功能，每個(gè) POD 會(huì)有一個(gè)標(biāo)準(zhǔn)化的 DNS 地址服務(wù)，它對(duì)于需要統(tǒng)一暴露出來(lái)的 API ，日志監(jiān)控追蹤能力都十分有幫助。通過(guò) DNS 的日志地址來(lái)訪(fǎng)問(wèn)以及暴露的可觀測(cè)性信息，可以快速發(fā)現(xiàn)運(yùn)行時(shí)的問(wèn)題。由此便可總結(jié)：容器及容器平臺(tái)能夠在微觀上幫微服務(wù)具備更多的能力。

圖中為 4 種發(fā)布模型：

1. 滾動(dòng)更新

2. 固定更新

3. 藍(lán)綠部署

4. 金絲雀發(fā)布（灰度發(fā)布）

微服務(wù)將過(guò)去單體時(shí)期靜態(tài)的通信關(guān)系，通過(guò)拆分編成動(dòng)態(tài)運(yùn)行時(shí)。通常服務(wù)間的通信與協(xié)同是需要單獨(dú)管理的，微服務(wù)框架幫助我們進(jìn)行了每個(gè)服務(wù)通用功能的抽象與實(shí)現(xiàn)。

抽象層面包含兩方面：業(yè)務(wù)邏輯與通信、流量、服務(wù)治理能力。我們可以將底層通用能力抽象成一個(gè)具體的框架，但是不同微服務(wù)之間的框架是沒(méi)辦法實(shí)現(xiàn)相互調(diào)用的。而到了云原生時(shí)代，它能夠使用不同的開(kāi)發(fā)語(yǔ)言以及模型進(jìn)行編程，實(shí)現(xiàn)微服務(wù)的研發(fā)。

Service Mesh 服務(wù)網(wǎng)格就是為了解決流量治理在多語(yǔ)言，多環(huán)境下的問(wèn)題而出現(xiàn)的。

在數(shù)據(jù)層面，Sidecar 負(fù)責(zé)流量劫持轉(zhuǎn)發(fā)以及管理，該功能典型 Sidecar 實(shí)現(xiàn)就是 Envoy。

如圖它會(huì)先將上面部分從框架層面抽象出來(lái)后與業(yè)務(wù)直接進(jìn)行解耦，將通用能力放在 Sidecar 中，通過(guò) Sidecar 之間的通信、轉(zhuǎn)發(fā)去管理；這樣會(huì)使問(wèn)題變得簡(jiǎn)單很多。開(kāi)發(fā)者只需要在流量管理和 Sidecar 之間通信，不同技術(shù)棧的微服務(wù)實(shí)例便可實(shí)現(xiàn)互相通信。

除了數(shù)據(jù)層面，我們還需要管控層面的支持。需要一個(gè)組件來(lái)實(shí)現(xiàn)原微服務(wù)體系中的策略規(guī)則的管理，經(jīng)典實(shí)現(xiàn)就是 Istio。比如在原來(lái)在微服務(wù)體系中的服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、流量觀測(cè)等能力是需要管控層面的主線(xiàn)去完成的。有這些能力之后它就組成了 Service Mesh。我們可以通過(guò)管理 POD 中的流量以及數(shù)據(jù)層面的單點(diǎn)，讓他們形成網(wǎng)狀結(jié)構(gòu)，變成集群實(shí)現(xiàn)流量的分配、安全、觀測(cè)。

圖中的編程模型與函數(shù)計(jì)算相關(guān)

請(qǐng)求驅(qū)動(dòng)是基于請(qǐng)求的動(dòng)態(tài)彈性伸縮，并簡(jiǎn)化請(qǐng)求處理的邏輯。微服務(wù)的調(diào)用，從流量進(jìn)來(lái)后，會(huì)經(jīng)過(guò) 4 層或者 7 層的負(fù)載均衡分發(fā)到不同的微服務(wù)實(shí)例；但是在同一個(gè)微服務(wù)實(shí)例進(jìn)程的內(nèi)部，一般會(huì)有兩個(gè)邏輯：第一個(gè)是請(qǐng)求管理，它可能是一個(gè) HTTP 服務(wù)器，或者是一些 Handler，也可能是一些隊(duì)列管理，請(qǐng)求分發(fā)能力的組成；這些組成最終會(huì)將請(qǐng)求提交到第二部分，即請(qǐng)求處理中，而請(qǐng)求處理也是開(kāi)發(fā)者真正需要實(shí)現(xiàn)的一些邏輯。

比如說(shuō) Java Go 、Python，它們都有自己的一套請(qǐng)求管理邏輯，請(qǐng)求管理和請(qǐng)求處理之間會(huì)形成強(qiáng)烈的耦合，這個(gè)實(shí)例既包含請(qǐng)求的管理，又包含請(qǐng)求處理的邏輯。在這個(gè)架構(gòu)下不存在一個(gè)全局獨(dú)立，且可以感知到請(qǐng)求去進(jìn)行流量管理的控制層，只有到整個(gè)實(shí)例自身的處理層才如此解釋請(qǐng)求。即便此時(shí)微服務(wù)實(shí)例已然過(guò)載，也很難再次將這個(gè)請(qǐng)求轉(zhuǎn)發(fā)到其它微服務(wù)實(shí)例上進(jìn)行負(fù)載均衡。因此請(qǐng)求驅(qū)動(dòng)系統(tǒng)就是查數(shù)據(jù)、并解決這兩個(gè)要素，開(kāi)發(fā)者實(shí)際在做的就是請(qǐng)求驅(qū)動(dòng)的解耦。

如圖所示，首先外部系統(tǒng)傳輸過(guò)來(lái)的請(qǐng)求會(huì)先進(jìn)行標(biāo)準(zhǔn)化，有一個(gè)適配器；標(biāo)準(zhǔn)化之后就會(huì)將其放在請(qǐng)求負(fù)載均衡器中，這個(gè)負(fù)載均衡器可以理解該請(qǐng)求本身的語(yǔ)義；然后它可以驅(qū)動(dòng)并進(jìn)行處理。當(dāng)處理單元不夠時(shí)，它可以通過(guò)管理器來(lái)進(jìn)行擴(kuò)容；邏輯單元比較多時(shí)，它還可以進(jìn)行縮容，這樣便形成了一個(gè)動(dòng)態(tài)管理，可以為開(kāi)發(fā)者節(jié)約非常多的成本。

請(qǐng)求驅(qū)動(dòng)模型：

1. 請(qǐng)求標(biāo)準(zhǔn)化

2. 請(qǐng)求路由

3. 處理管理

將請(qǐng)求標(biāo)準(zhǔn)化、請(qǐng)求路由、處理管理等組合起來(lái)，便與 Serverless 的概念吻合。開(kāi)發(fā)者根本不需要去關(guān)心 Server ，只需要去專(zhuān)注業(yè)務(wù)邏輯即可。這其實(shí)也是微服務(wù)體系與平臺(tái)化的 Serverless 架構(gòu)融合的過(guò)程。阿里云的 FC （函數(shù)計(jì)算）和 SAE（應(yīng)用引擎） 都是以解決這些問(wèn)題為核心的。

Serverless 其實(shí)經(jīng)過(guò)了很多年的發(fā)展，其理念最早可以追溯到 2012 年；2014 年 AWS 正式推出 Lambda，才掀起了 Serverless 浪潮；但隨后而來(lái)的是一段沉靜的發(fā)展期。這種情況出現(xiàn)的原因是為什么呢？分析來(lái)看是因?yàn)楹瘮?shù)計(jì)算的開(kāi)發(fā)模式與原本模式有非常大的出入，它更適合前端而不是 long running 形式的一些應(yīng)用，它更偏向基于請(qǐng)求的一些處理。因此那些需要長(zhǎng)時(shí)間運(yùn)行的服務(wù)或應(yīng)用架構(gòu)便不太能夠享受到 Serverless 所帶來(lái)的彈性和降本提效等紅利。

微服務(wù)的痛點(diǎn)在于穩(wěn)定性。微服務(wù)帶來(lái)了許多其他組件。例如服務(wù)發(fā)現(xiàn)、或是其他的一些工具類(lèi)的產(chǎn)品，這些在單體情況下會(huì)變得更加復(fù)雜，因?yàn)檎麄€(gè)架構(gòu)變成網(wǎng)狀結(jié)構(gòu)。容器與容器平臺(tái)在某些程度上是幫助我們承載微服務(wù)這部分的運(yùn)維的，但是其本身如容器 K8S 都是存在一定復(fù)雜性的。

K8S 的架構(gòu)圖

K8S 不僅復(fù)雜也存在一些痛點(diǎn)：

1. 容器鏡像部署方式差異

2. K8S 組件運(yùn)維的復(fù)雜

3. 學(xué)習(xí)成本

對(duì)于開(kāi)發(fā)者來(lái)說(shuō)是最有吸引力的是不需要改變?cè)镜拈_(kāi)發(fā)方式的基礎(chǔ)上可以將精力專(zhuān)注于業(yè)務(wù)邏輯。而微服務(wù)比較理想的狀態(tài)也是開(kāi)發(fā)者只需關(guān)注架構(gòu)中的業(yè)務(wù)系統(tǒng)，其它部分如：網(wǎng)關(guān) CICD 發(fā)布系統(tǒng)、驗(yàn)貨流程，注冊(cè)中心、告警監(jiān)控、分析日志，這些通通都不再需開(kāi)發(fā)者再去關(guān)心。其優(yōu)勢(shì)可以總結(jié)為：

1. 讓開(kāi)發(fā)者專(zhuān)注業(yè)務(wù)邏輯

2. 不改變?cè)虚_(kāi)發(fā)方式

3. 無(wú)需關(guān)心與運(yùn)維底層資源

4. 具備彈性能力可以降低閑時(shí)成本

5. 優(yōu)秀的工具鏈

微服務(wù)體系在整個(gè)云計(jì)算發(fā)展的時(shí)代有不同的事件。如最開(kāi)始部署就是傳統(tǒng)的 IT 設(shè)施，像 IDC 這種機(jī)房，微服務(wù)提供的是靜態(tài)的物理計(jì)算資源。

然后到了第二步就是云托管時(shí)代，就是我們大家所熟知的 VM，阿里的話(huà)就是 ECS ，它可以提供彈性的計(jì)算資源，但它并沒(méi)有實(shí)質(zhì)的改變，只是資源上變成彈性，它對(duì)于服務(wù)、微服務(wù)的部署，包括管理運(yùn)維等本質(zhì)上都沒(méi)有太大變化。

到了第三階段云原生時(shí)代，云平臺(tái)、云服務(wù)都可以承擔(dān)這些復(fù)雜的運(yùn)維操作、配置、管理。微服務(wù)提供的就是一個(gè)運(yùn)行環(huán)境與平臺(tái)，此時(shí)用戶(hù)只需要去關(guān)心業(yè)務(wù)系統(tǒng)、以及如何實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)即可。將復(fù)雜的技術(shù)變得越來(lái)越簡(jiǎn)單，讓用戶(hù)不再感知那些煩雜的操作，由平臺(tái)代替用戶(hù)去做重復(fù)的、難以維護(hù)的工作，這也十分符合計(jì)算機(jī)技術(shù)整體的發(fā)展方向。

弈川

阿里云云原生團(tuán)隊(duì)

目前從事阿里云 Serverless 應(yīng)用引擎的研發(fā)工作，專(zhuān)注于aPaas、微服務(wù)、分布式系統(tǒng)、Serverless 工具鏈等方向，致力于打造下一代 Serverless 平臺(tái)，讓傳統(tǒng)應(yīng)用的開(kāi)發(fā)者能零改造、低成本的享受 Serverless、K8S 等技術(shù)紅利。

社區(qū)網(wǎng)址

Serverless Devs

推薦閱讀:

Serverless?Devs 2.0 全新發(fā)布，讓?xiě)?yīng)用開(kāi)發(fā)更簡(jiǎn)單

???????

???????先行一步，7 大技術(shù)創(chuàng)新和突破，阿里云把 Serverless 領(lǐng)域的這些難題都給解了

Serverless?架構(gòu)模式及演進(jìn)

一圖看懂阿里云 Serverless @云棲大會(huì)

Serverless Devs 2.0 開(kāi)箱測(cè)評(píng)

?戳原文體驗(yàn)?看課程回放！? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??