作者 | 陳濤

微服務架構的優點和痛點

1、微服務架構的誕生背景

回到互聯網早期時代，也就是web1.0時代，當時主要是一些門戶網站，單體應用是當時的主流應用，研發團隊相對較小，這時候的挑戰在於技術的複雜度，以及技術人員的匱乏。

到了新世紀互聯網時代，出現了較大規模的一些應用，比如社交、電商等，流量和業務的複雜度也大幅增加，出現了幾百甚至上千人的研發團隊，研發團隊擴大之後，協作問題成爲困擾。SOA 解決方案是互聯網的產物，其核心在於分佈式、拆分等。但是因爲 ESB 這樣一些單點的組件，所以沒有得到很好的推廣。阿里巴巴在當時推出的 HSF、開源的Dubbo 等技術，其實是類似於分佈式的一個解決方案，當時就已經有了微服務架構的理念。

微服務架構正式名稱的誕生是在移動互聯網時代，這時的生活已經實現全面互聯網化，各種各樣的生活類 APP 湧現，網民以及流量複雜度相對於新世紀互聯網時代顯著增強。另外，較大規模的研發團隊也已成爲主流。這時候，大家普遍都對效率有了更高的追求，而不只是原來只有幾個巨頭需要有這方面的技術。微服務架構以及微服務技術的推出，如 Spring Cloud、Dubbo 等框架的普及，極大地推廣了微服務技術。

現在我們已經進入全面的數字化時代，社會全面互聯網化，各種各樣的單位（包括政企、相對傳統的單位）都需要較強的研發能力。流量的挑戰、業務複雜度的挑戰、研發團隊的擴大等，使得大家對效率有了更高的要求。這時候微服務架構得到了進一步的推廣和普及。

微服務架構經過這麼多年的發展，是經久不衰的一項技術，爲什麼它能夠有這樣持續的發展？

2、微服務架構的優點

我們來回顧一下微服務架構和單體架構的區別，以及微服務架構的核心優勢。

單體架構核心的問題在於衝突域太大，包括共享代碼庫。在研發過程中特別容易衝突；邊界和模塊的規模不清，使得團隊效率也會降低。而在微服務架構下，核心就在於拆分，包括解耦的研發態，解耦的部署態，極大地釋放了團隊的研發效率。大道至簡，這也是微服務架構爲什麼能夠持續發展的一個原因。

3、微服務時代痛點

根據複雜性守恆定律，我們解決了一個問題，問題會以另一種形式出現，我們又需要去解決。可以看到，微服務時代下會引入非常多的一些痛點，核心就是穩定性。因爲從原來的一些本地調用改成遠程調用以後，可能會發生穩定性的點激增，包括調度放大，即可能因爲底層的一些遠程調用問題，造成上層的一些不穩定，以及期間需要做的限流降級、調用鏈等。

在微服務時代定位一個問題的複雜度，也會成指數級的一個增長，這裏面可能還需要服務治理。另外如果沒有較好的設計和預先的一些設想，可能會出現微服務應用的爆炸，包括研發人員和測試人員之間的協作也都會成問題。

微服務技術經過這麼多年的發展，業界其實已經有了一些解決方案。

如上圖顯示，如果要比較好地玩轉微服務技術，除了開發自己的業務系統以外，可能還要配套地搭建多個系統，包括CI/CD、發佈系統、研發流程、微服務組件相關的一些工具，以及可觀測性相關的實時監控、告警系統、服務治理、調用鏈等等，還需要運維基礎的 IaaS 資源。在這個時代，爲了更好地運維 IaaS 資源，可能還需要自己維護一個K8s 集羣。

所以說，在這樣的背景下，很多企業會選擇搭建一個運維團隊，或者中間件團隊，或者說由一些後端研發同學兼職。但是試想，有多少企業對自己內部搭建的這套系統是滿意的？系統的迭代效率是多少，有沒有踩到過一些開源的坑，這些坑現在有沒有解決？這些應該是在企業的CTO、架構師心中一個持續的痛點。

Serverless時代下的解決方案

1、Serverless時代

Serverless 從2012年第一次提出，到 2014年推出了 Lambda 這樣一個引爆性的產品後，短暫地達到了一個影響力的頂峯。但是這樣一個新生事物，突然到真實的、複雜的生產環境中，其實有許多不適應，包括需要改善的地方，所以後續幾年它可能要進入一個低谷。

但是，Serverless 的“將簡單交給用戶，複雜留給平臺”的理念，其實是非常正確的一個方向。所以在開源界包括業界，其實都在持續性地進行 Serverless 方面的一些探索和發展。

阿里雲在2017年推出了函數計算（Function Compute，FC），在2018年推出了Serverless應用引擎 SAE，在 2019年以及後續的這些年，阿里雲持續地在 Serverless 領域進行投入，支持了包括鏡像部署、預留實力、微服務場景等。

2、Serverless 市場概況

在2021年最新的 Forrester 評測中，阿里雲 Serverless 產品能力是中國第一、全球領先，阿里雲的 Serverless 用戶佔比也是中國第一。這側面說明了阿里雲 Serverless 是已經越來越多地進入到企業真實的生產環境中，越來越多的企業認可 Serverless 以及阿里雲 Serverless 的能力和價值。

3、SAE解決方案

可以看到，在傳統的微服務架構下面，企業要用好微服務相關的技術需要自己研發非常多的解決方案，那麼在 Serverless 時代下，在 SAE 這個產品裏面是怎麼解決的？

我們可以看到，SAE 將 Serverless 這個理念發揚到了極致，不僅僅託管了 IaaS 資源，包括上層的 K8s，另外還集成了白屏化的 PaaS 以及企業級微服務相關的套件和可觀測相關的套件。在 SAE 整體解決方案裏面，針對這些都進行了很好的集成，給用戶提供了一個開箱即用的微服務解決方案，讓企業和開發者能夠很簡單地使用微服務。

1、0 門檻 PaaS

圖中可以看到，SAE 在最上層給用戶提供的是一個白屏化的操作系統，它的設計理念非常符合企業一般的 PaaS 系統，包括髮布系統或者一些開源的 PaaS 系統，這樣極大地降低了企業上手 SAE 的門檻，甚至可以說零門檻，包括它也集成了阿里巴巴最佳的一些發佈，即發佈三板斧——可觀測、可灰度、可回滾。另外它也提供了一些企業級能力的增強，包括命名空間環境隔離、細粒度的權限控制等等。從圖中可以看到，在一個企業裏面，如果有兩個相互比較獨立的模塊，完全可以通過命名空間進程進行隔離。

2、微服務治理增強

在微服務治理增強方面，特別是在 Java 語言，SAE 採用了一個 agent，對用戶來說相當於是無侵入、無感知、零升級，而且 agent 的全面兼容開源，使用戶幾乎在無修改的情況下，就可以使用無損下限、API 管理、限流降級、鏈路追蹤等等能力。

3、前後端全鏈路灰度

這裏展開兩個能力，第一個能力是前後端全鏈路灰度。SAE 藉助前面提到的 agent 技術，從 web請求到網關到 consumer 到 provide 進行了一個全鏈路的打通，使用戶可以通過很簡單的白屏化配置，就可以實現一個灰度發佈場景。而這樣的技術如果企業需要自建，這裏面的複雜度大家應該是非常清楚的。

4、CloudToolkit 端雲聯調

第二個能力就是 CloudToolkit 的端雲聯調。大家都知道微服務的場景下面應用數量是呈現一個爆炸的趨勢，如果本地需要開發，需要啓動那麼多的應用，如何能夠安全便捷地聯調雲上的一個服務？現在藉助 CloudToolkit，用戶可以很簡單地在本地就打通雲上的環境，進行一個端雲聯調，極大地降低開發測試的門檻。

5、強大的應用監控 & 診斷

在微服務的場景下，因爲微服務的急劇發散、調用鏈路的極度增長，在有問題的場景下面定位問題是非常複雜的。而 SAE 集成了阿里雲各種各樣的可觀測產品，包括Prometheus、IaaS、SLS、基礎監控等，在 Tracing Logging Metrics 等方面都提供了豐富的解決方案，包括請求鏈路的查詢，常用的診斷場景的指標分析，基礎監控、實時日誌、事件通知等等，這些都能極大地降低企業在微服務檯運行場景下的一些日常定位問題。

SAE的技術原理和極致彈性建設

前面已經針對三部分，也就是零門檻PaaS、企業級微服務套件、可觀測進行了一個講解。那麼現在要介紹 Serverless 的一個核心模塊，也就是 IaaS 層面上免運維以及彈性能力的建設。

1、SAE 業務架構

通過這張 SAE 的業務架構圖，大家就可以相對比較清晰地看出，在SAE裏面 IaaS 資源包括存儲、網絡等是不需要用戶關心的。另外 SAE 也託管了 K8s 這個 PaaS 層的一個組件，相當於用戶也不需要自己去運維 K8s 。在 K8s 層之上，SAE 提供了微服務治理、應用生命週期管理等增強的能力。另外在彈性方面，SAE 的彈性能力達到了15秒，相信在很多企業級的場景下，這已經能幫助開發者較好地應對一些突發流量的情況。另外通過多套環境以及一些最佳實踐，可以達到一個降本增效的效果。

2、SAE 技術架構

那麼 SAE 是怎麼建設免運維，對用戶來說，相當於不需要託管的一個 IaaS 資源以及 K8s 資源呢？

上圖中可以看到，SAE 底層其實是採用了一種安全容器的技術，相比於Docker，安全容器相當於提供了虛擬機級別的一個安全解決方案。在 RunC 場景下，由於共享內核其實在公有云產品上，a用戶有可能穿透到 b 用戶的一個容器內，造成一些安全風險。採用安全容器的技術，也就是虛擬機相關的安全技術，達到了一個生產級別的安全隔離，包括安全容器也進入了 K8s 以及容器的生態。這樣安全容器+容器生態的結合，就實現了較好的安全+效率的一個平衡。

另外在存儲和網絡的隔離方面，SAE 不僅僅需要考慮傳統的 K8s 上的網絡隔離，也需要考慮在公有云產品下，大部分用戶已經在公有云上有非常多的一些存儲資源、網絡資源，這些也需要進行一個打通。

SAE 採用了雲產品的 ENI網卡技術，將 ENI網卡直通到了安全沙箱內，這樣相當於用戶不僅僅實現了一個計算層的隔離，也實現了網絡層的打通。可以看到現在主流的安全容器技術有 Kata、Firecracker、gVisor 等等，在 SAE 裏面是採用了最早也是最成熟的 Kata 技術來實現一個計算成安全的隔離。另外安全容器不僅實現了一個安全的隔離，也實現了一個性能隔離和故障隔離。

舉一個比較好理解的例子，在 RunC 大家共享內核的場景下，一個用戶的 Container 造成了一些內核的故障，是直接可能影響到物理機的。在 SAE 使用安全容器基礎上就沒有這方面的風險，最多隻會影響到那一個安全容器。

3、極致彈性極致成本

下圖中可以看到，如果彈性效率達到了一個極致，用戶的成本也可以達到一個極致。通過左右兩邊的圖的對比，大家可以理解彈性對用戶成本可以達到的一個效果。

1、SAE 極致彈性建設：部署 & 重啓

SAE 在彈性方面做了哪些事情呢？可以看到傳統的 K8s 的一個 Pod 的創建過程需要經過調度、init container的創建、拉取用戶鏡像、創建用戶容器、啓動用戶容器、應用運行等等階段，它雖然符合 K8s 的設計理念和規範，但是在生產環境下，對一些需要相對比較要求效率的場景，其實就不太滿足企業級的要求。而 SAE 藉助於阿里巴巴開源裏面的 CloneSet 組件的原地升級策略，相當於不需要重建整個 Pod，而只需要重建裏面的 container 省去了調度以及 innt containr 創建的一個過程，部署效率達到了 42% 的提升。

2、SAE 極致彈性建設：彈性擴容

在鏡像預熱場景 SAE 也實現了一個並行的調度。可以看到，在標準的場景下，調度到用戶拉取鏡像是一個串行的過程。那麼在此做了一個優化，就是在識別到 pod 即將調入到單個物理機的時候，它就會並行地開始拉取用戶的鏡像，這樣也可以達到一個彈性效率 30% 的提升。

3、SAE 極致彈性建設：Java啓動加速

那麼在應用啓動這個階段，我們也做了一些彈性效率能力提升的事情。比如說 Java 的應用，在 Serverless 場景下其實一直有啓動慢的痛點，核心在於 Java 需要一個個加載。而在一些企業級的應用裏面，針對成千上萬的 class 的加載，這肯定是一個相對較緩慢的過程。 SAE 結合阿里巴巴開源的 Dragonwell 實現了 App CDS 的技術，它會在應用第一次啓動的時候，將 class 加載打到一個壓縮包中，後續的應用加載，只需要加載壓縮包即可，免去了大量 class 的一個串行化的加載，實現了部署效率 45% 的一個提升。

4、SAE極致彈性建設

最後在應用運行態，我們也做了一些彈性方面的增強。微服務的應用通常會需要配置非常多的一些線程，這些線程通常和 Linux 的底層線程是一一對應的。在高併發場景下，這裏面就會有較大的線程切換的開銷。SAE 結合阿里巴巴開源的 Dragonwell，WISP 線程的技術，將上層的幾百個線程對應到了底層的十幾個線程，極大的降低了線程切換的一個開銷。

上圖中是我們一個壓測的數據。紅線就是使用了 Dragonwell、WISP 的技術，可以看到運行效率有 20% 左右的提升。以上就是 SAE 在 Serverless、IaaS 託管以及 K8s 託管方面，還有在彈性效率方面建設的一些技術原理和效果。

總結和展望

原來的微服務用戶需要自建非常多的組件，包括 PaaS 微服務一些技術框架，運維 IaaS、K8s，還包括可觀測組件等。SAE 針對這些方面都做了整體的解決方案，使用戶只需要關注自己的業務系統，這極大地降低了用戶使用微服務技術的門檻。

後續 SAE 針對每個模塊也會持續地的做能力的建設。包括： • 在零門檻 PaaS 方面，微服務會持續做一些雲產品的集成，包括 CICD 工具鏈。另外也會做企業級的能力增強，比如審批流等。 • 在 Serverless 免運維、極致彈性方面，我們也會提供越來越多的彈性能力、彈性指標、彈性效率，這些也都會持續地建設。另外也會提供類似 AI 預測這樣的彈性解決方案，降低用戶設置彈性指標的時候的心智負擔。 • 在微服務生態方面，我們也會和微服務的企業套件做更多的集成，進一步降低大家使用微服務技術的門檻，比如說混沌工程、遠程調試能力增強等。

最後在可觀測方面，SAE 相當於運維了用戶的應用。那麼可觀測對於 SAE 本身或者說對平臺本身也是一個非常重要的能力，在這方面我們會持續地做相應的一些監控告警，包括預案和灰度建設等等。對用戶來說，也需要在SAE上託管它的應用，這就要求產品能夠降低用戶在使用這方面的門檻，後續會建設應用大盤、事件中心等等。

作者：阿里巴巴中間件
鏈接：https://my.oschina.net/u/3996014/blog/5131825