本文将介紹 Serverless 應用引擎是如何将 Serverless 技術與微服務體系組合成最佳實踐的。
作者：弈川
稽核&校對：筱姜、潇航
編輯&排版：雯燕
在網際網路早期即 Web 1.0 的時代，當時流行的是單體應用，研發團隊比較小，主要是外部網頁，然後新聞門戶等；到了新世紀的網際網路時期 Web 2.0 時代，網民數量大幅激增，相繼出現電商、社交這樣巨無霸級别的網際網路産品，出現了幾百人甚至上千的研發團隊在一個場景下，流量及業務複雜度相較于上一個時代有了質的變化，是以單體服務的弊端：例如研發效率等問題便顯現出來。
此時出現了一個叫 SOA 的架構，其架構思路與微服務很像，它有類似于 ESB 這種中心化元件，阿裡的 HSF，包括後來開源的 Double，都是在此階段誕生的。
移動網際網路時代出現之後，各種各樣的 APP 誕生，生活也開始全面網際網路化。大流量高并發以及規模化的研發團隊變得越來越尋常，相應對高技術、生産力的要求也在逐漸提升，此時微服務的概念應運而生。
微服務其實一直貫穿在整個架構的發展過程中。在 Java 的技術棧，類似于 Spring Cloud 、Double 這些架構都已經非常流行。不難發現整個社會已經步入數字化高速發展階段，此時更大的問題蘊含其中，如流量升高、應用複雜度提升，研發團隊擴大、對于效率的要求提高等等。
大部分的公司或早期業務都會經曆過這樣的過程（如圖所示）：先是用戶端，此時需要通過一個入口通路，上圖中 SLB 是阿裡雲一個負載均衡服務，它相當于一個網絡入口，可以對應到 ECS（ECS 為阿裡雲的虛拟機）打到對應的單體的服務中，而此時他們會共用一個資料庫，這是第一個時期。
到第二個時期 SOA 架構：此時出現了分治的思想，它會将一些業務進行拆分。但它并未做到服務與底層的拆分，如存儲資料庫的拆分，其本質上還是共用一套資料庫，是以它還是單體的架構。
而到微服務時期，如若用戶端通過 SLB 通路網關（如圖所示），随後會轉發對應的服務，且服務與服務之間會産生一些調用；每個服務會對應一個單獨的資料庫或緩存，且每個服務會通過類似于 Nacos 這種的服務進行注冊、發現以及配置管理。
微服務引入之後，雖然解決了架構業務的分離，能夠讓研發團隊在某一個領域、業務能夠做到精專，不過從整體架構來看便會發現，相較于之前，它其實是更為複雜的，是以也帶來一些運維上的問題。
在單體架構中，于單體應用而言，會發生邊界不清晰、子產品耦合、共享代碼庫容易沖突的問題，同時如果團隊規模較大，此時的協作效率也會相對較低。但是微服務架構的核心就是解耦，如果做到拆分之後的解耦，就可以釋放開發團隊效率。
雲原生是一個很宏觀的概念，如果我們以微服務為起點來看雲原生給微服務帶來的變化與演進，可以更好地幫助我們了解什麼是雲原生。
微服務和單體應用的本質是什麼呢？（如圖所示）它其實是把單體應用從一個巨型的應用拆分成數個微小的服務，協作來完成原先單體應用等效的業務服務。此時微服務與微服務之間會形成一個依賴關系，它需要部署至一個或多個資源上，這時的資源便是計算資源。
過去單體應用與資源之間的關系十分簡單，單體應用的協同也都是一些内部協同，不存在外部動态的依賴。但架構轉換到微服務之後，由于外部依賴和節點數量的爆炸，整個體系會變成網狀，管理起來十分複雜。超過 50% 的企業會覺得采用微服務架構，最大挑戰是複雜的運維，即整個服務生命周期的管理。
如今，比較公認的一點是雲原生的根基在于容器與容器的管理編排（K8s）。而容器與 K8s 的技術能夠幫助我們解決微服務體系中所存在繁雜運維的問題。
首先不同的微服務之間會存在異構，即一個團隊，在微服務體系下為了發揮最大效能，可能會允許不同小團隊采用不同的程式設計語言、運作環境去運作微服務。是以最初我們在運維和管理微服務時，是沒有統一的标準去處理這些異構環境的。這便促發了雲原生容器技術的流行，因為這項技術的作用就是通過一層标準化的運作時和封裝來限制微服務部署。這樣從生命周期與管理角度來看，每一個微服務之間的差異變少，十分有利于資源的排程。
随後。基于容器排程衍生出了容器平台。容器平台就是管理容器的，就 K8s 來說，它可以标準便捷地将微服務運作到底層的資源上，随後存儲計算網絡可以通過 K8s 這層來進行統一封裝，一層抽象與封裝，它類似于雲原生時代的作業系統。
它具體會提供哪些幫助呢？在 K8s 中有個概念叫 POD ，POD 是一組容器的結合，與微服務實體生命周期的耦合，在一個 POD 裡面，它可以運作一個或者是多個容器。
采用微服務架構時，一般會把微服務運作的主體放在主容器中，也就是把微服務執行的主邏輯放在主容器裡面。此時主容器的生命周期與 POD 的生命周期是完全耦合的，POD 什麼時候消亡，微服的運作主體便何時消亡。除此之外我們還會運作一些邊車容器— Sidecar，它主要是為主容器提供輔助功能，如日志采集、網絡代理、身份鑒權等 。此時的微服務便除了提供自身核心業務以外，它還可以動态的提供額外輔助能力，這讓微服務的管理變得更加穩定與便捷。
POD 這個模型還提供了許多非常有用的功能，比如狀态資訊。（狀态資訊是指：POD 會提供一個标準的接口來顯示運作時的狀态）通過這個資訊狀态可以出判斷微服務或是容器的運作狀态，如它是否處于運作中、業務是否已經準備好可以迎接流量接入，POD 為整體的穩定性提供了保障。另一個是位址服務功能，每個 POD 會有一個标準化的 DNS 位址服務，它對于需要統一暴露出來的 API ，日志監控追蹤能力都十分有幫助。通過 DNS 的日志位址來通路以及暴露的可觀測性資訊，可以快速發現運作時的問題。由此便可總結：容器及容器平台能夠在微觀上幫微服務具備更多的能力。
圖中為 4 種釋出模型：
滾動更新
固定更新
藍綠部署
金絲雀釋出（灰階釋出）
微服務将過去單體時期靜态的通信關系，通過拆分編成動态運作時。通常服務間的通信與協同是需要單獨管理的，微服務架構幫助我們進行了每個服務通用功能的抽象與實作。
抽象層面包含兩方面：業務邏輯與通信、流量、服務治理能力。我們可以将底層通用能力抽象成一個具體的架構，但是不同微服務之間的架構是沒辦法實作互相調用的。而到了雲原生時代，它能夠使用不同的開發語言以及模型進行程式設計，實作微服務的研發。
Service Mesh 服務網格就是為了解決流量治理在多語言，多環境下的問題而出現的。
在資料層面，Sidecar 負責流量劫持轉發以及管理，該功能典型 Sidecar 實作就是 Envoy。
如圖它會先将上面部分從架構層面抽象出來後與業務直接進行解耦，将通用能力放在 Sidecar 中，通過 Sidecar 之間的通信、轉發去管理；這樣會使問題變得簡單很多。開發者隻需要在流量管理和 Sidecar 之間通信，不同技術棧的微服務執行個體便可實作互相通信。
除了資料層面，我們還需要管控層面的支援。需要一個元件來實作原微服務體系中的政策規則的管理，經典實作就是 Istio。比如在原來在微服務體系中的服務注冊、服務發現、流量觀測等能力是需要管控層面的主線去完成的。有這些能力之後它就組成了 Service Mesh。我們可以通過管理 POD 中的流量以及資料層面的單點，讓他們形成網狀結構，變成叢集實作流量的配置設定、安全、觀測。
圖中的程式設計模型與函數計算相關
請求驅動是基于請求的動态彈性伸縮，并簡化請求處理的邏輯。微服務的調用，從流量進來後，會經過 4 層或者 7 層的負載均衡分發到不同的微服務執行個體；但是在同一個微服務執行個體程序的内部，一般會有兩個邏輯：第一個是請求管理，它可能是一個 HTTP 伺服器，或者是一些 Handler，也可能是一些隊列管理，請求分發能力的組成；這些組成最終會将請求送出到第二部分，即請求進行中，而請求處理也是開發者真正需要實作的一些邏輯。
比如說 Java Go 、Python，它們都有自己的一套請求管理邏輯，請求管理和請求處理之間會形成強烈的耦合，這個執行個體既包含請求的管理，又包含請求處理的邏輯。在這個架構下不存在一個全局獨立，且可以感覺到請求去進行流量管理的控制層，隻有到整個執行個體自身的處理層才如此解釋請求。即便此時微服務執行個體已然過載，也很難再次将這個請求轉發到其它微服務執行個體上進行負載均衡。是以請求驅動系統就是查資料、并解決這兩個要素，開發者實際在做的就是請求驅動的解耦。
如圖所示，首先外部系統傳輸過來的請求會先進行标準化，有一個擴充卡；标準化之後就會将其放在請求負載均衡器中，這個負載均衡器可以了解該請求本身的語義；然後它可以驅動并進行處理。當處理單元不夠時，它可以通過管理器來進行擴容；邏輯單元比較多時，它還可以進行縮容，這樣便形成了一個動态管理，可以為開發者節約非常多的成本。
請求驅動模型：
請求标準化
請求路由
處理管理
将請求标準化、請求路由、處理管理等組合起來，便與 Serverless 的概念吻合。開發者根本不需要去關心 Server ，隻需要去專注業務邏輯即可。這其實也是微服務體系與平台化的 Serverless 架構融合的過程。阿裡雲的 FC （函數計算）和 SAE（應用引擎） 都是以解決這些問題為核心的。
Serverless 其實經過了很多年的發展，其理念最早可以追溯到 2012 年；而2014 年 AWS 正式推出 Lambda，才掀起了 Serverless 浪潮；但随後而來的是一段沉靜的發展期。這種情況出現的原因是為什麼呢？分析來看是因為函數計算的開發模式與原本模式有非常大的出入，它更适合前端而不是 long running 形式的一些應用，它更偏向基于請求的一些處理。是以那些需要長時間運作的服務或應用架構便不太能夠享受到 Serverless 所帶來的彈性和降本提效等紅利。
微服務的痛點在于穩定性。微服務帶來了許多其他元件。例如服務發現、或是其他的一些工具類的産品，這些在單體情況下會變得更加複雜，因為整個架構變成網狀結構。容器與容器平台在某些程度上是幫助我們承載微服務這部分的運維的，但是其本身如容器 K8s 都是存在一定複雜性的。
K8s 的架構圖
K8s 不僅複雜也存在一些痛點：
容器鏡像部署方式差異
K8s 元件運維的複雜
學習成本
對于開發者來說是最有吸引力的是不需要改變原本的開發方式的基礎上可以将精力專注于業務邏輯。而微服務比較理想的狀态也是開發者隻需關注架構中的業務系統，其它部分如：網關 CICD 釋出系統、驗貨流程，注冊中心、告警監控、分析日志，這些通通都不再需開發者再去關心。其優勢可以總結為：
讓開發者專注業務邏輯
不改變原有開發方式
無需關心與運維底層資源
具備彈性能力可以降低閑時成本
優秀的工具鍊
微服務體系在整個雲計算發展的時代有不同的事件。如最開始部署就是傳統的 IT 設施，像 IDC 這種機房，微服務提供的是靜态的實體計算資源。
然後到了第二步就是雲托管時代，就是我們大家所熟知的 VM，阿裡的話就是 ECS ，它可以提供彈性的計算資源，但它并沒有實質的改變，隻是資源上變成彈性，它對于服務、微服務的部署，包括管理運維等本質上都沒有太大變化。
到了第三階段雲原生時代，雲平台、雲服務都可以承擔這些複雜的運維操作、配置、管理。微服務提供的就是一個運作環境與平台，此時使用者隻需要去關心業務系統、以及如何實作業務系統即可。将複雜的技術變得越來越簡單，讓使用者不再感覺那些煩雜的操作，由平台代替使用者去做重複的、難以維護的工作，這也十分符合計算機技術整體的發展方向。
作者介紹：
弈川｜阿裡雲雲原生團隊
目前從事阿裡雲 Serverless 應用引擎的研發工作，專注于aPaas、微服務、分布式系統、Serverless 工具鍊等方向，緻力于打造下一代 Serverless 平台，讓傳統應用的開發者能零改造、低成本的享受 Serverless、K8S 等技術紅利。
相關連結：
1）社群官網
http://www.serverless-devs.com/
2）項目倉庫
https://：.com/Serverless-Devs/Serverless-Devs
3）Serverless Desktop 桌面用戶端
https://serverlessdevs.resume.net.cn/zh-cn/desktop/index.html
4）Serverless 應用開發者套件
http://serverless-dk.oss.devsapp.net/docs/tutorial-dk/intro/react
5）Serverless Devs CLI
https://serverlessdevs.resume.net.cn/zh-cn/cli/index.html
6）Serverless Hub 應用中心
https://serverlesshub.resume.net.cn/#/hubs/special-view
點選此處，看相關視訊版解析~