作者 | 陳濤
微服務(wù)架構(gòu)的優(yōu)點(diǎn)和痛點(diǎn)
1、微服務(wù)架構(gòu)的誕生背景
回到互聯(lián)網(wǎng)早期時代，也就是 web1.0 時代，當(dāng)時主要是一些門戶網(wǎng)站，單體應(yīng)用是當(dāng)時的主流應(yīng)用，研發(fā)團(tuán)隊(duì)相對較小，這時候的挑戰(zhàn)在于技術(shù)的復(fù)雜度，以及技術(shù)人員的匱乏。到了新世紀(jì)互聯(lián)網(wǎng)時代，出現(xiàn)了較大規(guī)模的一些應(yīng)用，比如社交、電商等，流量和業(yè)務(wù)的復(fù)雜度也大幅增加，出現(xiàn)了幾百甚至上千人的研發(fā)團(tuán)隊(duì)，研發(fā)團(tuán)隊(duì)擴(kuò)大之后，協(xié)作問題成為困擾。SOA 解決方案是互聯(lián)網(wǎng)的產(chǎn)物，其核心在于分布式、拆分等。但是因?yàn)?ESB 這樣一些單點(diǎn)的組件，所以沒有得到很好的推廣。阿里巴巴在當(dāng)時推出的 HSF、開源的 Dubbo 等技術(shù)，其實(shí)是類似于分布式的一個解決方案，當(dāng)時就已經(jīng)有了微服務(wù)架構(gòu)的理念。微服務(wù)架構(gòu)正式名稱的誕生是在移動互聯(lián)網(wǎng)時代，這時的生活已經(jīng)實(shí)現(xiàn)全面互聯(lián)網(wǎng)化，各種各樣的生活類 APP 涌現(xiàn)，網(wǎng)民以及流量復(fù)雜度相對于新世紀(jì)互聯(lián)網(wǎng)時代顯著增強(qiáng)。另外，較大規(guī)模的研發(fā)團(tuán)隊(duì)也已成為主流。這時候，大家普遍都對效率有了更高的追求，而不只是原來只有幾個巨頭需要有這方面的技術(shù)。微服務(wù)架構(gòu)以及微服務(wù)技術(shù)的推出，如 Spring Cloud、Dubbo 等框架的普及，極大地推廣了微服務(wù)技術(shù)。現(xiàn)在我們已經(jīng)進(jìn)入全面的數(shù)字化時代，社會全面互聯(lián)網(wǎng)化，各種各樣的單位（包括政企、相對傳統(tǒng)的單位）都需要較強(qiáng)的研發(fā)能力。流量的挑戰(zhàn)、業(yè)務(wù)復(fù)雜度的挑戰(zhàn)、研發(fā)團(tuán)隊(duì)的擴(kuò)大等，使得大家對效率有了更高的要求。這時候微服務(wù)架構(gòu)得到了進(jìn)一步的推廣和普及。微服務(wù)架構(gòu)經(jīng)過這么多年的發(fā)展，是經(jīng)久不衰的一項(xiàng)技術(shù)，為什么它能夠有這樣持續(xù)的發(fā)展？2、微服務(wù)架構(gòu)的優(yōu)點(diǎn)
我們來回顧一下微服務(wù)架構(gòu)和單體架構(gòu)的區(qū)別，以及微服務(wù)架構(gòu)的核心優(yōu)勢。單體架構(gòu)核心的問題在于沖突域太大，包括共享代碼庫。在研發(fā)過程中特別容易沖突；邊界和模塊的規(guī)模不清，使得團(tuán)隊(duì)效率也會降低。而在微服務(wù)架構(gòu)下，核心就在于拆分，包括解耦的研發(fā)態(tài)，解耦的部署態(tài)，極大地釋放了團(tuán)隊(duì)的研發(fā)效率。大道至簡，這也是微服務(wù)架構(gòu)為什么能夠持續(xù)發(fā)展的一個原因。
3、微服務(wù)時代痛點(diǎn)
根據(jù)復(fù)雜性守恒定律，我們解決了一個問題，問題會以另一種形式出現(xiàn)，我們又需要去解決。可以看到，微服務(wù)時代下會引入非常多的一些痛點(diǎn)，核心就是穩(wěn)定性。因?yàn)閺脑瓉淼囊恍┍镜卣{(diào)用改成遠(yuǎn)程調(diào)用以后，可能會發(fā)生穩(wěn)定性的點(diǎn)激增，包括調(diào)度放大，即可能因?yàn)榈讓拥囊恍┻h(yuǎn)程調(diào)用問題，造成上層的一些不穩(wěn)定，以及期間需要做的限流降級、調(diào)用鏈等。在微服務(wù)時代定位一個問題的復(fù)雜度，也會成指數(shù)級的一個增長，這里面可能還需要服務(wù)治理。另外如果沒有較好的設(shè)計(jì)和預(yù)先的一些設(shè)想，可能會出現(xiàn)微服務(wù)應(yīng)用的爆炸，包括研發(fā)人員和測試人員之間的協(xié)作也都會成問題。
微服務(wù)技術(shù)經(jīng)過這么多年的發(fā)展，業(yè)界其實(shí)已經(jīng)有了一些解決方案。如上圖顯示，如果要比較好地玩轉(zhuǎn)微服務(wù)技術(shù)，除了開發(fā)自己的業(yè)務(wù)系統(tǒng)以外，可能還要配套地搭建多個系統(tǒng)，包括 CI/CD、發(fā)布系統(tǒng)、研發(fā)流程、微服務(wù)組件相關(guān)的一些工具，以及可觀測性相關(guān)的實(shí)時監(jiān)控、告警系統(tǒng)、服務(wù)治理、調(diào)用鏈等等，還需要運(yùn)維基礎(chǔ)的 IaaS 資源。在這個時代，為了更好地運(yùn)維 IaaS 資源，可能還需要自己維護(hù)一個 K8s 集群。所以說，在這樣的背景下，很多企業(yè)會選擇搭建一個運(yùn)維團(tuán)隊(duì)，或者中間件團(tuán)隊(duì)，或者說由一些后端研發(fā)同學(xué)兼職。但是試想，有多少企業(yè)對自己內(nèi)部搭建的這套系統(tǒng)是滿意的？系統(tǒng)的迭代效率是多少，有沒有踩到過一些開源的坑，這些坑現(xiàn)在有沒有解決？這些應(yīng)該是在企業(yè)的 CTO、架構(gòu)師心中一個持續(xù)的痛點(diǎn)。
1、Serverless時代
Serverless 從2012年第一次提出，到 2014 年 推出了 Lambda 這樣一個引爆性的產(chǎn)品后，短暫地達(dá)到了一個影響力的頂峰。但是這樣一個新生事物，突然到真實(shí)的、復(fù)雜的生產(chǎn)環(huán)境中，其實(shí)有許多不適應(yīng)，包括需要改善的地方，所以后續(xù)幾年它可能要進(jìn)入一個低谷。但是，Serverless 的 “將簡單交給用戶，復(fù)雜留給平臺” 的理念，其實(shí)是非常正確的一個方向。所以在開源界包括業(yè)界，其實(shí)都在持續(xù)性地進(jìn)行 Serverless 方面的一些探索和發(fā)展。阿里云在2017年推出了函數(shù)計(jì)算（Function Compute，F(xiàn)C），在 2018 年推出了 Serverless 應(yīng)用引擎 SAE，在 2019 年以及后續(xù)的這些年，阿里云持續(xù)地在 Serverless 領(lǐng)域進(jìn)行投入，支持了包括鏡像部署、預(yù)留實(shí)力、微服務(wù)場景等。
2、Serverless 市場概況
如圖所示，在 2021 年最新的 Forrester 評測中，阿里云 Serverless 產(chǎn)品能力是中國第一、全球領(lǐng)先，阿里云的 Serverless 用戶占比也是中國第一。這側(cè)面說明了阿里云 Serverless 是已經(jīng)越來越多地進(jìn)入到企業(yè)真實(shí)的生產(chǎn)環(huán)境中，越來越多的企業(yè)認(rèn)可 Serverless 以及阿里云 Serverless 的能力和價值。
3、SAE解決方案
可以看到，在傳統(tǒng)的微服務(wù)架構(gòu)下面，企業(yè)要用好微服務(wù)相關(guān)的技術(shù)需要自己研發(fā)非常多的解決方案，那么在 Serverless 時代下，在 SAE 這個產(chǎn)品里面是怎么解決的？我們可以看到，SAE 將 Serverless 這個理念發(fā)揚(yáng)到了極致，不僅僅托管了 IaaS 資源，包括上層的 K8s，另外還集成了白屏化的 PaaS 以及企業(yè)級微服務(wù)相關(guān)的套件和可觀測相關(guān)的套件。在 SAE 整體解決方案里面，針對這些都進(jìn)行了很好的集成，給用戶提供了一個開箱即用的微服務(wù)解決方案，讓企業(yè)和開發(fā)者能夠很簡單地使用微服務(wù)。
0 門檻 PaaS
圖中可以看到，SAE 在最上層給用戶提供的是一個白屏化的操作系統(tǒng)，它的設(shè)計(jì)理念非常符合企業(yè)一般的 PaaS 系統(tǒng)，包括發(fā)布系統(tǒng)或者一些開源的 PaaS 系統(tǒng)，這樣極大地降低了企業(yè)上手 SAE 的門檻，甚至可以說零門檻，包括它也集成了阿里巴巴最佳的一些發(fā)布，即發(fā)布三板斧——可觀測、可灰度、可回滾。另外它也提供了一些企業(yè)級能力的增強(qiáng)，包括命名空間環(huán)境隔離、細(xì)粒度的權(quán)限控制等等。從圖中可以看到，在一個企業(yè)里面，如果有兩個相互比較獨(dú)立的模塊，完全可以通過命名空間進(jìn)程進(jìn)行隔離。
微服務(wù)治理增強(qiáng)
在微服務(wù)治理增強(qiáng)方面，特別是在 Java 語言，SAE 采用了一個 agent，對用戶來說相當(dāng)于是無侵入、無感知、零升級，而且 agent 的全面兼容開源，使用戶幾乎在無修改的情況下，就可以使用無損下限、API 管理、限流降級、鏈路追蹤等等能力。
這里展開兩個能力，第一個能力是前后端全鏈路灰度。SAE 借助前面提到的 agent 技術(shù)，從 web 請求到網(wǎng)關(guān)到 consumer 到 provide 進(jìn)行了一個全鏈路的打通，使用戶可以通過很簡單的白屏化配置，就可以實(shí)現(xiàn)一個灰度發(fā)布場景。而這樣的技術(shù)如果企業(yè)需要自建，這里面的復(fù)雜度大家應(yīng)該是非常清楚的。
CloudToolkit 端云聯(lián)調(diào)
第二個能力就是 CloudToolkit 的端云聯(lián)調(diào)。大家都知道微服務(wù)的場景下面應(yīng)用數(shù)量是呈現(xiàn)一個爆炸的趨勢，如果本地需要開發(fā)，需要啟動那么多的應(yīng)用，如何能夠安全便捷地聯(lián)調(diào)云上的一個服務(wù)？現(xiàn)在借助 CloudToolkit，用戶可以很簡單地在本地就打通云上的環(huán)境，進(jìn)行一個端云聯(lián)調(diào)，極大地降低開發(fā)測試的門檻。
強(qiáng)大的應(yīng)用監(jiān)控 & 診斷
在微服務(wù)的場景下，因?yàn)槲⒎?wù)的急劇發(fā)散、調(diào)用鏈路的極度增長，在有問題的場景下面定位問題是非常復(fù)雜的。而 SAE 集成了阿里云各種各樣的可觀測產(chǎn)品，包括Prometheus、IaaS、SLS、基礎(chǔ)監(jiān)控等，在 Tracing Logging Metrics 等方面都提供了豐富的解決方案，包括請求鏈路的查詢，常用的診斷場景的指標(biāo)分析，基礎(chǔ)監(jiān)控、實(shí)時日志、事件通知等等，這些都能極大地降低企業(yè)在微服務(wù)臺運(yùn)行場景下的一些日常定位問題。
SAE 的技術(shù)原理和極致彈性建設(shè)
前面已經(jīng)針對三部分，也就是零門檻 PaaS、企業(yè)級微服務(wù)套件、可觀測進(jìn)行了一個講解。那么現(xiàn)在要介紹 Serverless 的一個核心模塊，也就是 IaaS 層面上免運(yùn)維以及彈性能力的建設(shè)。
1、SAE 業(yè)務(wù)架構(gòu)
通過這張 SAE 的業(yè)務(wù)架構(gòu)圖，大家就可以相對比較清晰地看出，在 SAE 里面 IaaS 資源包括存儲、網(wǎng)絡(luò)等是不需要用戶關(guān)心的。另外 SAE 也托管了 K8s 這個 PaaS 層的一個組件，相當(dāng)于用戶也不需要自己去運(yùn)維 K8s 。在 K8s 層之上，SAE 提供了微服務(wù)治理、應(yīng)用生命周期管理等增強(qiáng)的能力。另外在彈性方面，SAE 的彈性能力達(dá)到了 15 秒，相信在很多企業(yè)級的場景下，這已經(jīng)能幫助開發(fā)者較好地應(yīng)對一些突發(fā)流量的情況。另外通過多套環(huán)境以及一些最佳實(shí)踐，可以達(dá)到一個降本增效的效果。
2、SAE 技術(shù)架構(gòu)
那么 SAE 是怎么建設(shè)免運(yùn)維，對用戶來說，相當(dāng)于不需要托管的一個 IaaS 資源以及 K8s 資源呢？上圖中可以看到，SAE 底層其實(shí)是采用了一種安全容器的技術(shù)，相比于 Docker，安全容器相當(dāng)于提供了虛擬機(jī)級別的一個安全解決方案。在 RunC 場景下，由于共享內(nèi)核其實(shí)在公有云產(chǎn)品上，a 用戶有可能穿透到 b 用戶的一個容器內(nèi)，造成一些安全風(fēng)險。采用安全容器的技術(shù)，也就是虛擬機(jī)相關(guān)的安全技術(shù)，達(dá)到了一個生產(chǎn)級別的安全隔離，包括安全容器也進(jìn)入了 K8s 以及容器的生態(tài)。這樣安全容器+容器生態(tài)的結(jié)合，就實(shí)現(xiàn)了較好的安全+效率的一個平衡。另外在存儲和網(wǎng)絡(luò)的隔離方面，SAE 不僅僅需要考慮傳統(tǒng)的 K8s 上的網(wǎng)絡(luò)隔離，也需要考慮在公有云產(chǎn)品下，大部分用戶已經(jīng)在公有云上有非常多的一些存儲資源、網(wǎng)絡(luò)資源，這些也需要進(jìn)行一個打通。SAE 采用了云產(chǎn)品的 ENI網(wǎng)卡技術(shù)，將 ENI 網(wǎng)卡直通到了安全沙箱內(nèi)，這樣相當(dāng)于用戶不僅僅實(shí)現(xiàn)了一個計(jì)算層的隔離，也實(shí)現(xiàn)了網(wǎng)絡(luò)層的打通。
可以看到現(xiàn)在主流的安全容器技術(shù)有 Kata、Firecracker、gVisor 等等，在 SAE 里面是采用了最早也是最成熟的 Kata 技術(shù)來實(shí)現(xiàn)一個計(jì)算成安全的隔離。另外安全容器不僅實(shí)現(xiàn)了一個安全的隔離，也實(shí)現(xiàn)了一個性能隔離和故障隔離。舉一個比較好理解的例子，在 RunC 大家共享內(nèi)核的場景下，一個用戶的 Container 造成了一些內(nèi)核的故障，是直接可能影響到物理機(jī)的。在 SAE 使用安全容器基礎(chǔ)上就沒有這方面的風(fēng)險，最多只會影響到那一個安全容器。
3、極致彈性 極致成本
下圖中可以看到，如果彈性效率達(dá)到了一個極致，用戶的成本也可以達(dá)到一個極致。通過左右兩邊的圖的對比，大家可以理解彈性對用戶成本可以達(dá)到的一個效果。
SAE 極致彈性建設(shè)：部署 & 重啟
SAE 在彈性方面做了哪些事情呢？可以看到傳統(tǒng)的 K8s 的一個 Pod 的創(chuàng)建過程需要經(jīng)過調(diào)度、init container 的創(chuàng)建、拉取用戶鏡像、創(chuàng)建用戶容器、啟動用戶容器、應(yīng)用運(yùn)行等等階段，它雖然符合 K8s 的設(shè)計(jì)理念和規(guī)范，但是在生產(chǎn)環(huán)境下，對一些需要相對比較要求效率的場景，其實(shí)就不太滿足企業(yè)級的要求。而 SAE 借助于阿里巴巴開源里面的 CloneSet 組件的原地升級策略，相當(dāng)于不需要重建整個 Pod，而只需要重建里面的 container 省去了調(diào)度以及 innt containr 創(chuàng)建的一個過程，部署效率達(dá)到了 42% 的提升。
SAE 極致彈性建設(shè)：彈性擴(kuò)容
在鏡像預(yù)熱場景 SAE 也實(shí)現(xiàn)了一個并行的調(diào)度。可以看到，在標(biāo)準(zhǔn)的場景下，調(diào)度到用戶拉取鏡像是一個串行的過程。那么在此做了一個優(yōu)化，就是在識別到 pod 即將調(diào)入到單個物理機(jī)的時候，它就會并行地開始拉取用戶的鏡像，這樣也可以達(dá)到一個彈性效率 30% 的提升。
SAE 極致彈性建設(shè)：Java啟動加速
那么在應(yīng)用啟動這個階段，我們也做了一些彈性效率能力提升的事情。比如說 Java 的應(yīng)用，在 Serverless 場景下其實(shí)一直有啟動慢的痛點(diǎn)，核心在于 Java 需要一個個加載。而在一些企業(yè)級的應(yīng)用里面，針對成千上萬的 class 的加載，這肯定是一個相對較緩慢的過程。SAE 結(jié)合阿里巴巴開源的 Dragonwell 實(shí)現(xiàn)了 App CDS 的技術(shù)，它會在應(yīng)用第一次啟動的時候，將 class 加載打到一個壓縮包中，后續(xù)的應(yīng)用加載，只需要加載壓縮包即可，免去了大量 class 的一個串行化的加載，實(shí)現(xiàn)了部署效率 45% 的一個提升。
SAE極致彈性建設(shè)
最后在應(yīng)用運(yùn)行態(tài)，我們也做了一些彈性方面的增強(qiáng)。微服務(wù)的應(yīng)用通常會需要配置非常多的一些線程，這些線程通常和 Linux 的底層線程是一一對應(yīng)的。在高并發(fā)場景下，這里面就會有較大的線程切換的開銷。SAE 結(jié)合阿里巴巴開源的 Dragonwell，WISP 線程的技術(shù)，將上層的幾百個線程對應(yīng)到了底層的十幾個線程，極大的降低了線程切換的一個開銷。上圖中是我們一個壓測的數(shù)據(jù)。紅線就是使用了 Dragonwell、WISP 的技術(shù)，可以看到運(yùn)行效率有 20% 左右的提升。以上就是 SAE 在 Serverless、IaaS 托管以及 K8s 托管方面，還有在彈性效率方面建設(shè)的一些技術(shù)原理和效果。
原來的微服務(wù)用戶需要自建非常多的組件，包括 PaaS 微服務(wù)一些技術(shù)框架，運(yùn)維 IaaS、K8s，還包括可觀測組件等。SAE 針對這些方面都做了整體的解決方案，使用戶只需要關(guān)注自己的業(yè)務(wù)系統(tǒng)，這極大地降低了用戶使用微服務(wù)技術(shù)的門檻。后續(xù) SAE 針對每個模塊也會持續(xù)地的做能力的建設(shè)。包括：- 在零門檻 PaaS 方面，微服務(wù)會持續(xù)做一些云產(chǎn)品的集成，包括 CICD 工具鏈。另外也會做企業(yè)級的能力增強(qiáng)，比如審批流等。
- 在 Serverless 免運(yùn)維、極致彈性方面，我們也會提供越來越多的彈性能力、彈性指標(biāo)、彈性效率，這些也都會持續(xù)地建設(shè)。另外也會提供類似 AI 預(yù)測這樣的彈性解決方案，降低用戶設(shè)置彈性指標(biāo)的時候的心智負(fù)擔(dān)。
- 在微服務(wù)生態(tài)方面，我們也會和微服務(wù)的企業(yè)套件做更多的集成，進(jìn)一步降低大家使用微服務(wù)技術(shù)的門檻，比如說混沌工程、遠(yuǎn)程調(diào)試能力增強(qiáng)等。
最后在可觀測方面，SAE 相當(dāng)于運(yùn)維了用戶的應(yīng)用。那么可觀測對于 SAE 本身或者說對平臺本身也是一個非常重要的能力，在這方面我們會持續(xù)地做相應(yīng)的一些監(jiān)控告警，包括預(yù)案和灰度建設(shè)等等。對用戶來說，也需要在 SAE 上托管它的應(yīng)用，這就要求產(chǎn)品能夠降低用戶在使用這方面的門檻，后續(xù)會建設(shè)應(yīng)用大盤、事件中心等等。
7 月 24 日阿里云 Serverless Developer Meetup 杭州站現(xiàn)已正式開通報(bào)名渠道！我們特邀來自阿里云、初創(chuàng)互聯(lián)網(wǎng)公司、開源中國 Gitee 的技術(shù)專家和獨(dú)立開發(fā)者分享 Serverles 實(shí)戰(zhàn)經(jīng)驗(yàn)，更有全新單元 Serverless Workshop 首次開張，召集 30 位 “愛動手” 的開發(fā)者，名額有限，速來報(bào)名！詳情見 7.24 杭州站 | 阿里云 Serverless Developer Meetup 開放報(bào)名！瀏覽器打開 http://hdxu.cn/S6Qzf 或掃描下方二維碼即可來現(xiàn)場與技術(shù)大咖一起實(shí)操 Serverless !
????戳 “原文”跳轉(zhuǎn)報(bào)名
