作者 | 陳濤
微服務架構的優點和痛點
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上托管它的應用，這就要求産品能夠降低使用者在使用這方面的門檻，後續會建設應用大盤、事件中心等等。
﹀
解決方案咨詢技術交流群：搜尋釘釘群号 31704055 加入，可擷取雲原生詳細解決方案資料與專家答疑。*進群後請備注：公司-職位-姓名