Serverless：微服務(wù)架構(gòu)的終極模式
??點(diǎn)擊“博文視點(diǎn)Broadview”，獲取更多書(shū)訊
微服務(wù)的生態(tài)和實(shí)踐已經(jīng)比較成熟，其設(shè)計(jì)方法、開(kāi)發(fā)框架、CI/CD工具、基礎(chǔ)設(shè)施管理工具等，都可以幫助企業(yè)順利實(shí)施微服務(wù)。然而，微服務(wù)遠(yuǎn)沒(méi)有達(dá)到完美，它在架構(gòu)、開(kāi)發(fā)、基礎(chǔ)設(shè)施方面仍然面臨新的挑戰(zhàn)。
微服務(wù)面臨的挑戰(zhàn)
微服務(wù)的粒度影響服務(wù)的交付速度及擴(kuò)展性，微服務(wù)的開(kāi)發(fā)引入治理組件，增加了開(kāi)發(fā)的難度，以容器為基礎(chǔ)的微服務(wù)基礎(chǔ)設(shè)施在彈性等方面仍有不足，而微服務(wù)增加帶來(lái)的基礎(chǔ)設(shè)施成本也是微服務(wù)實(shí)施的新挑戰(zhàn)。
1．微服務(wù)的粒度仍然比較大
當(dāng)前微服務(wù)劃分主要遵循單一職責(zé)的原則，比如將用戶管理的功能作為一個(gè)單獨(dú)的微服務(wù)。如圖所示，用戶管理微服務(wù)提供了API注冊(cè)、登錄、登出功能。通常，從提升用戶體驗(yàn)的角度來(lái)看，瀏覽器會(huì)保留用戶的會(huì)話，除非用戶主動(dòng)登出，否則不會(huì)請(qǐng)求登出API。所以，登出和注冊(cè)的QPS差距較大，對(duì)擴(kuò)展的訴求完全不同。而且，注冊(cè)API和登出API的變更頻率也可能不同。進(jìn)一步拆分可以帶來(lái)擴(kuò)展性等便利，但整個(gè)微服務(wù)的數(shù)量也會(huì)提升一個(gè)量級(jí)，給基礎(chǔ)設(shè)施的管理帶來(lái)負(fù)擔(dān)，那么如何做好架構(gòu)權(quán)衡，既能夠擁有架構(gòu)上的高可擴(kuò)展性，又不用增加基礎(chǔ)設(shè)施管理成本呢？
2．微服務(wù)開(kāi)發(fā)仍有較高門(mén)檻
如圖所示，Java微服務(wù)開(kāi)發(fā)的軟件棧要求開(kāi)發(fā)者掌握以下技能。
Java微服務(wù)開(kāi)發(fā)技術(shù)棧
相比于單體應(yīng)用開(kāi)發(fā)，微服務(wù)開(kāi)發(fā)效率得到提升的部分來(lái)自服務(wù)粒度減少及開(kāi)發(fā)框架的改進(jìn)，例如，從復(fù)雜的SpringMVC演進(jìn)到SpringBoot，框架更加輕量化。但在其他方面（并發(fā)處理等）并沒(méi)有什么改變，同時(shí)在微服務(wù)治理、分布式事務(wù)等方面的開(kāi)發(fā)難度反而增加了。服務(wù)網(wǎng)格的出現(xiàn)，讓開(kāi)發(fā)人員可以不用關(guān)心服務(wù)治理的內(nèi)容，但這樣會(huì)帶來(lái)服務(wù)性能的下降和維護(hù)的復(fù)雜性，其使用的范圍也存在局限。是否存在一種新的編程模型及開(kāi)發(fā)框架，讓開(kāi)發(fā)者在了解基本的語(yǔ)言特性和編程模型后，便可上手開(kāi)發(fā)業(yè)務(wù)邏輯，而不用關(guān)心網(wǎng)絡(luò)、并發(fā)、服務(wù)治理等問(wèn)題？
3．微服務(wù)基礎(chǔ)設(shè)施管理、高可用和彈性仍然很難保證
容器和Kubernetes工具的使用，提升了應(yīng)用部署及基礎(chǔ)設(shè)施運(yùn)維自動(dòng)化的能力，但保證基礎(chǔ)設(shè)施高可用、可擴(kuò)展對(duì)運(yùn)維人員的能力要求很高。如圖所示，服務(wù)上云后，基礎(chǔ)設(shè)施團(tuán)隊(duì)可以不用再關(guān)心服務(wù)器、交換機(jī)等硬件的運(yùn)維，但仍然需要關(guān)心虛擬機(jī)的維護(hù)，如安全補(bǔ)丁、基礎(chǔ)鏡像的更新升級(jí)、擴(kuò)容等。
基礎(chǔ)設(shè)施團(tuán)隊(duì)依然需要管理虛擬機(jī)
從On-Premise到公有云，實(shí)際上虛擬機(jī)的可用性在降低，比如云服務(wù)商提供的單虛擬機(jī)的可用性可能只有95%。運(yùn)維人員需要借助云側(cè)的工具來(lái)保證基礎(chǔ)設(shè)施的高可用，難度仍然存在，而且很依賴運(yùn)維人員的能力。
集群及其他云原生工具的維護(hù)也帶來(lái)額外的挑戰(zhàn)。以Kubernetes集群為例，維護(hù)和管理Kubernetes集群需要專業(yè)的技能。同理，維護(hù)云原生的監(jiān)控、日志服務(wù)的高可用性也有不小的難度。所以，基礎(chǔ)設(shè)施管理的難度仍然存在，只是從虛擬機(jī)轉(zhuǎn)移到容器集群，從Rsyslog轉(zhuǎn)移到ElasticSearch。
對(duì)于服務(wù)層面的擴(kuò)展性，當(dāng)前的策略也比較簡(jiǎn)單，例如，設(shè)定最少和最多使用的虛擬機(jī)數(shù)量，或者想辦法改善根據(jù)CPU/內(nèi)存使用率來(lái)伸縮或擴(kuò)容的延遲。但是，由于總體資源量不會(huì)超過(guò)策略設(shè)定的虛擬機(jī)極限數(shù)量，因此一旦請(qǐng)求超過(guò)最大資源能承載的范圍，可能會(huì)影響用戶的使用體驗(yàn)甚至?xí)?wù)中斷。以容器為單位的擴(kuò)容，從虛擬機(jī)性能的分鐘級(jí)減少到30s左右，但當(dāng)面對(duì)突發(fā)流量時(shí)依然會(huì)出現(xiàn)響應(yīng)不及時(shí)、用戶體驗(yàn)差的情況。是否存在全托管的基礎(chǔ)設(shè)施及監(jiān)控運(yùn)維服務(wù)，能提供更好的彈性，從而讓開(kāi)發(fā)者無(wú)須關(guān)心所有底層和集群的維護(hù)工作，不再依賴高級(jí)運(yùn)維人員來(lái)保證基礎(chǔ)設(shè)施的可用性？
4．基礎(chǔ)設(shè)施的成本依然較高
微服務(wù)會(huì)增加基礎(chǔ)設(shè)施的成本。每個(gè)微服務(wù)都要考慮冗余，保證高可用。隨著微服務(wù)數(shù)量的增加，基礎(chǔ)設(shè)施的數(shù)量會(huì)呈現(xiàn)指數(shù)級(jí)增長(zhǎng)，但云服務(wù)的基礎(chǔ)設(shè)施收費(fèi)方式?jīng)]有改變，依然采用按照資源大小及以小時(shí)為單位（或包年）計(jì)費(fèi)的方式。閑時(shí)和忙時(shí)的收費(fèi)相同，對(duì)企業(yè)來(lái)說(shuō)存在成本的浪費(fèi)。是否存在一種新的基礎(chǔ)設(shè)施服務(wù)，能按照“用多少付多少”的方式收費(fèi)，從而降低基礎(chǔ)設(shè)施成本？
微服務(wù)面臨的這些新問(wèn)題，是否可以通過(guò)新的基礎(chǔ)設(shè)施服務(wù)及開(kāi)發(fā)模式來(lái)解決呢？
什么是Serverless
2012年，時(shí)任Iron.io的副總裁Ken提出了Serverless的概念，他認(rèn)為未來(lái)的軟件和應(yīng)用都應(yīng)該是Serverless的：“即使云計(jì)算興起，世界仍然圍繞著服務(wù)器運(yùn)轉(zhuǎn)。不過(guò)，這不會(huì)持續(xù)下去。云應(yīng)用程序正在進(jìn)入無(wú)服務(wù)器世界，這將對(duì)軟件和應(yīng)用程序的創(chuàng)建和分發(fā)產(chǎn)生重大影響。”
2014年，AWS推出Lambda函數(shù)計(jì)算服務(wù)，提供簡(jiǎn)化的編程模型及函數(shù)的運(yùn)行環(huán)境全托管，并且計(jì)費(fèi)方式更加接近實(shí)際的使用情況（請(qǐng)求次數(shù)和每100ms使用的內(nèi)存資源）。2015年，AWS推出API Gateway（全托管的網(wǎng)關(guān)服務(wù)），正式將Serverless這個(gè)概念推廣開(kāi)來(lái)。近年來(lái)，大部分的云提供商也提供了各種形態(tài)的Serverless服務(wù)，用于支持更多應(yīng)用的開(kāi)發(fā)和運(yùn)行。下圖為AWS Serverless全景圖。
AWS Serverless全景圖
Google在Serverless上的投入和發(fā)展節(jié)奏也很快。為了擴(kuò)大在移動(dòng)應(yīng)用開(kāi)發(fā)領(lǐng)域的優(yōu)勢(shì)，同時(shí)為Google云引流，Google在2011年就收購(gòu)了Firebase，2016年將其作為mBaaS（移動(dòng)后端即服務(wù)）的Serverless解決方案推出，以及安卓應(yīng)用開(kāi)發(fā)的主流云服務(wù)。除此之外，Google也推出了其他Serverless服務(wù)，以提供跨平臺(tái)（Android、Web、iOS等）能力，支持移動(dòng)、Web等應(yīng)用開(kāi)發(fā)，下圖為Google Serverless全景圖。
Google?Serverless全景圖
華為終端云服務(wù)以多年為超過(guò)百萬(wàn)移動(dòng)應(yīng)用開(kāi)發(fā)者提供服務(wù)為基礎(chǔ)，結(jié)合多年在Serverless領(lǐng)域的技術(shù)積累，推出了Serverless行業(yè)解決方案，包含構(gòu)建類（云函數(shù)、認(rèn)證、云存儲(chǔ)、云數(shù)據(jù)庫(kù)等）、增長(zhǎng)類（推送服務(wù)、遠(yuǎn)程配置等）、質(zhì)量和分析類（性能服務(wù)、崩潰服務(wù)等），提供面向移動(dòng)應(yīng)用開(kāi)發(fā)的Serverless服務(wù)。2021年，云函數(shù)、云數(shù)據(jù)庫(kù)等核心構(gòu)建類服務(wù)已面向全球HMS生態(tài)的開(kāi)發(fā)者開(kāi)放，下圖為HUAWEI AppGallery Connect Serverless全景圖。
HUAWEI AppGallery Connect Serverless全景圖
Serverless的定義
那么Serverless到底是什么呢？維基百科將Serverless定義為一種云計(jì)算執(zhí)行模型。
云服務(wù)商按需分配計(jì)算機(jī)資源，開(kāi)發(fā)者無(wú)須運(yùn)維這些資源，不用關(guān)心容器、虛擬機(jī)或物理服務(wù)器的容量規(guī)劃、配置、管理、維護(hù)、操作和擴(kuò)展。
Serverless計(jì)算無(wú)狀態(tài)，可在短時(shí)間內(nèi)完成計(jì)算，其結(jié)果保存在外部存儲(chǔ)中。
當(dāng)不使用某個(gè)應(yīng)用時(shí)，不向其分配計(jì)算資源。
計(jì)費(fèi)基于應(yīng)用消耗的實(shí)際資源來(lái)度量。
CNCF（Cloud Native Computing Foundation，云原生計(jì)算基金會(huì)）認(rèn)為Serverless旨在構(gòu)建和運(yùn)行不需要服務(wù)器管理的應(yīng)用程序，二者的不同之處在于它描述了一個(gè)更細(xì)粒度的部署模型，能夠以一個(gè)或多個(gè)函數(shù)的形式將應(yīng)用打包并上傳到平臺(tái)執(zhí)行，并且按需執(zhí)行、自動(dòng)擴(kuò)展和計(jì)費(fèi)。
Serverless并不意味著不需要服務(wù)器來(lái)托管和運(yùn)行代碼，也不意味著不再需要運(yùn)維工程師。Serverless是指開(kāi)發(fā)者不再需要將時(shí)間和資源花費(fèi)在服務(wù)器調(diào)配、維護(hù)、更新、擴(kuò)展和容量規(guī)劃上，這些任務(wù)都由Serverless平臺(tái)處理，開(kāi)發(fā)者只需要專注于編寫(xiě)應(yīng)用程序的業(yè)務(wù)邏輯，運(yùn)維工程師能夠?qū)⒕Ψ旁跇I(yè)務(wù)運(yùn)維上。綜合維基百科和CNCF的定義，可以認(rèn)為Serverless是一種云計(jì)算執(zhí)行、部署和計(jì)費(fèi)模型，Serverless服務(wù)按請(qǐng)求為應(yīng)用分配資源，按照使用計(jì)費(fèi)，基礎(chǔ)設(shè)施全托管（無(wú)須關(guān)心維護(hù)、擴(kuò)容等）。
目前，Serverless服務(wù)主要分為FaaS和BaaS。
函數(shù)即服務(wù)（Function as a Service，F(xiàn)aaS）：開(kāi)發(fā)者實(shí)現(xiàn)的服務(wù)器端應(yīng)用邏輯（微服務(wù)甚至粒度更小的服務(wù)）以事件驅(qū)動(dòng)的方式運(yùn)行在無(wú)狀態(tài)的臨時(shí)容器中，這些容器和計(jì)算資源完全由云提供商管理。如圖1-7所示，從開(kāi)發(fā)者角度來(lái)看，F(xiàn)aaS和IaaS/PaaS相比，其擴(kuò)容的維度從應(yīng)用級(jí)別降低到函數(shù)級(jí)別，開(kāi)發(fā)者只需關(guān)心和維護(hù)業(yè)務(wù)層面的正常運(yùn)行，其他部分如運(yùn)行時(shí)、容器、操作系統(tǒng)、硬件等，都由云提供商來(lái)解決。
FaaS與IaaS、PaaS的區(qū)別
后端即服務(wù)（Backend as a Service，BaaS）：基于API的三方服務(wù)，用來(lái)取代應(yīng)用程序中功能的核心子集。由于這些API是作為自動(dòng)擴(kuò)展和透明運(yùn)行的服務(wù)提供的，因此從開(kāi)發(fā)者和運(yùn)維工程師的角度來(lái)看似乎是無(wú)服務(wù)器的。非計(jì)算類的全托管服務(wù)，如消息隊(duì)列等中間件、NoSQL數(shù)據(jù)庫(kù)服務(wù)、身份驗(yàn)證服務(wù)等，都可以認(rèn)為是BaaS服務(wù)。
FaaS通常是承載業(yè)務(wù)邏輯代碼的服務(wù)，開(kāi)發(fā)者會(huì)更為關(guān)心，它也是本書(shū)重點(diǎn)介紹的內(nèi)容。
Serverless關(guān)鍵技術(shù)
下圖是典型的Serverless系統(tǒng)架構(gòu)，從中可以看到一些Serverless的常用概念。
典型的Serverless架構(gòu)
事件源（Event Sources）：事件的生產(chǎn)者，可能是HTTP請(qǐng)求、消息隊(duì)列的事件等，通過(guò)同步或異步的方式去觸發(fā)函數(shù)。
觸發(fā)器（Trigger）：函數(shù)的REST呈現(xiàn)，通常是RESTful URL。當(dāng)事件源將事件推/拉到觸發(fā)器時(shí)，F(xiàn)aaS平臺(tái)會(huì)查找觸發(fā)器和函數(shù)的映射關(guān)系，從而啟動(dòng)該函數(shù)實(shí)例，以響應(yīng)被推/拉到觸發(fā)器的事件。
FaaS控制器（FaaS Controller）：FaaS平臺(tái)的核心組件，管理函數(shù)的生命周期、擴(kuò)容和縮容等?？梢詫⒑瘮?shù)實(shí)例縮容為0，同時(shí)在收到對(duì)函數(shù)的請(qǐng)求時(shí)迅速啟動(dòng)新的函數(shù)實(shí)例。
函數(shù)實(shí)例（Function Instance）：執(zhí)行函數(shù)的環(huán)境，包含函數(shù)代碼、函數(shù)運(yùn)行環(huán)境（如JRE、Node.js）、上下文信息（如函數(shù)運(yùn)行的配置，通常以環(huán)境變量注入）。一個(gè)函數(shù)實(shí)例可以同時(shí)處理1個(gè)或N個(gè)事件（取決于平臺(tái)的具體實(shí)現(xiàn)）。函數(shù)實(shí)例通常內(nèi)置可觀測(cè)性，將日志和監(jiān)控信息上報(bào)到對(duì)應(yīng)的日志和監(jiān)控服務(wù)中。
函數(shù)編程模型（Programming Model）：通常表現(xiàn)為函數(shù)的編碼規(guī)范，如簽名、入口的方法名等。函數(shù)的編程模型一般會(huì)提供同步/異步/異常處理機(jī)制，開(kāi)發(fā)者只需要處理輸入（事件、上下文），并返回結(jié)果即可。
BaaS平臺(tái)：函數(shù)通常是無(wú)狀態(tài)的，其狀態(tài)一般存儲(chǔ)在BaaS服務(wù)中，如NoSQL數(shù)據(jù)庫(kù)等。函數(shù)可以基于REST API或BaaS服務(wù)提供的SDK來(lái)訪問(wèn)BaaS服務(wù)，而不用關(guān)心這些服務(wù)的擴(kuò)容和縮容問(wèn)題。
結(jié)合上圖中典型Serverless架構(gòu)的架構(gòu)元素，從Serverless系統(tǒng)的實(shí)現(xiàn)來(lái)看，其關(guān)鍵技術(shù)需求包括以下幾點(diǎn)。
函數(shù)編程模型：提供友好的編程模型，使開(kāi)發(fā)者可以聚焦于業(yè)務(wù)邏輯，為開(kāi)發(fā)者屏蔽編碼中最困難的部分，如并發(fā)編程等。同時(shí)，需要原生支持函數(shù)的編排，盡量減少開(kāi)發(fā)者的學(xué)習(xí)成本。
快速擴(kuò)容：傳統(tǒng)的基礎(chǔ)設(shè)施通常都是從1到n擴(kuò)容的，而Serverless平臺(tái)需要支持從0到n擴(kuò)容，以更快的擴(kuò)容速度應(yīng)對(duì)流量的變化。同時(shí)，傳統(tǒng)基礎(chǔ)設(shè)施基于資源的擴(kuò)容決策周期（監(jiān)控周期）過(guò)長(zhǎng)，而Serverless平臺(tái)可達(dá)到秒級(jí)甚至毫秒級(jí)的擴(kuò)容速度。
快速啟動(dòng)：函數(shù)被請(qǐng)求時(shí)才會(huì)創(chuàng)建實(shí)例，該準(zhǔn)備過(guò)程會(huì)消耗較長(zhǎng)的時(shí)間，影響函數(shù)的啟動(dòng)性能。同理，對(duì)于新到達(dá)的并發(fā)請(qǐng)求，會(huì)產(chǎn)生并發(fā)的冷啟動(dòng)問(wèn)題。Serverless平臺(tái)需要降低冷啟動(dòng)時(shí)延，以滿足應(yīng)用對(duì)性能的訴求。
高效連接：函數(shù)需要將狀態(tài)或數(shù)據(jù)存放在后端BaaS服務(wù)中，而對(duì)接這些服務(wù)往往需要繁雜的API，造成開(kāi)發(fā)人員的學(xué)習(xí)負(fù)擔(dān)。如果能提供統(tǒng)一的后端訪問(wèn)接口，則可以降低開(kāi)發(fā)和遷移成本。另外，Serverless平臺(tái)的函數(shù)實(shí)例生命周期通常較短，對(duì)于如RDS數(shù)據(jù)庫(kù)等后端服務(wù)無(wú)法保持長(zhǎng)連接。然而，在并發(fā)冷啟動(dòng)場(chǎng)景下，大量函數(shù)實(shí)例會(huì)同時(shí)創(chuàng)建與數(shù)據(jù)庫(kù)的連接，可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)負(fù)載增加而訪問(wèn)失敗。為此，Serverless平臺(tái)需要為函數(shù)提供完備、高效、可靠的BaaS服務(wù)連接/訪問(wèn)接口。
安全隔離：Serverless是邏輯多租的服務(wù)，租戶的函數(shù)代碼可能運(yùn)行在同一臺(tái)服務(wù)器上。基于容器的方式，一旦單個(gè)租戶的函數(shù)遭受攻擊，造成容器逃逸，會(huì)影響服務(wù)器上所有租戶的函數(shù)安全。所以，通常Serverless平臺(tái)會(huì)采用安全容器的方式，引入輕量級(jí)虛擬化技術(shù)來(lái)保證隔離性，但這同時(shí)會(huì)引入額外的性能（啟動(dòng)）和資源開(kāi)銷等問(wèn)題。因此，Serverless平臺(tái)需要兼顧極致性能和安全隔離。
雖然業(yè)界涌現(xiàn)的各種Serverless系統(tǒng)在實(shí)現(xiàn)上可能有所不同（如本節(jié)介紹的多個(gè)函數(shù)計(jì)算平臺(tái)），但基本的概念、原理和關(guān)鍵技術(shù)是相通的，各個(gè)系統(tǒng)在實(shí)現(xiàn)時(shí)都需要應(yīng)對(duì)以上所述的技術(shù)挑戰(zhàn)。
Serverless帶來(lái)的核心變化
從開(kāi)發(fā)者或商業(yè)的角度看來(lái)，Serverless的價(jià)值在于全托管及創(chuàng)新的計(jì)費(fèi)模式。但從技術(shù)的角度看，Serverless從架構(gòu)、開(kāi)發(fā)模式、基礎(chǔ)設(shè)施等層面都有不同程度的創(chuàng)新。
Serverless的技術(shù)創(chuàng)新
Serverless基于事件驅(qū)動(dòng)的架構(gòu)，它的編程模型和運(yùn)行模式簡(jiǎn)化了開(kāi)發(fā)模式，融入了不可變基礎(chǔ)設(shè)施的最佳實(shí)踐。
1．Serverless是事件驅(qū)動(dòng)架構(gòu)的延伸
Serverless更容易實(shí)現(xiàn)事件驅(qū)動(dòng)的應(yīng)用。在分布式系統(tǒng)中，請(qǐng)求/響應(yīng)的方式和事件驅(qū)動(dòng)的方式都存在。請(qǐng)求/響應(yīng)是指客戶端會(huì)發(fā)出一個(gè)請(qǐng)求并等待一個(gè)響應(yīng)，該過(guò)程允許同步或異步方式。雖然請(qǐng)求者可以允許該響應(yīng)異步到達(dá)，但對(duì)響應(yīng)到達(dá)的預(yù)期本身就在一個(gè)響應(yīng)和另一個(gè)響應(yīng)之間建立了直接的依賴關(guān)系。事件驅(qū)動(dòng)的架構(gòu)是指在松耦合系統(tǒng)中通過(guò)生產(chǎn)和消費(fèi)事件來(lái)互相交換信息。相比請(qǐng)求/響應(yīng)的方式，事件的方式更解耦，并且更加自治。例如，在圖片上傳后進(jìn)行轉(zhuǎn)換處理的場(chǎng)景，以往需要一個(gè)長(zhǎng)時(shí)運(yùn)行的服務(wù)去輪詢是否有新圖片產(chǎn)生，而在Serverless下，用戶不需要進(jìn)行編碼輪詢，只需要通過(guò)配置將對(duì)象存儲(chǔ)服務(wù)中的上傳事件對(duì)接到函數(shù)即可，文件上傳后會(huì)自動(dòng)觸發(fā)函數(shù)進(jìn)行圖片轉(zhuǎn)換。
Serverless架構(gòu)的基本單元從微服務(wù)變?yōu)楹瘮?shù)。微服務(wù)的每個(gè)API的非功能屬性有差異，比如對(duì)性能、擴(kuò)展性、部署頻率的要求并不相同，進(jìn)一步拆分的確有助于系統(tǒng)的持續(xù)演進(jìn)，但相應(yīng)會(huì)帶來(lái)指數(shù)級(jí)的服務(wù)數(shù)量增長(zhǎng)，導(dǎo)致微服務(wù)的基礎(chǔ)設(shè)施和運(yùn)維體系難以支撐。Serverless架構(gòu)可以將微服務(wù)的粒度進(jìn)一步降低到函數(shù)級(jí)，同時(shí)不會(huì)對(duì)基礎(chǔ)設(shè)施和運(yùn)維產(chǎn)生新的負(fù)擔(dān)，只是增加了少量的函數(shù)管理成本，相比其帶來(lái)的收益這是完全可以接受的。
基于Serverless更容易構(gòu)建3-Tier架構(gòu)應(yīng)用。3-Tier是指將應(yīng)用分為3層，即展示層、業(yè)務(wù)層及數(shù)據(jù)層，并且會(huì)部署在不同的物理位置。如Web應(yīng)用，其展示層和業(yè)務(wù)層在物理層面往往會(huì)在一起部署。以下圖中的寵物商店應(yīng)用為例，在基于微服務(wù)的部署視圖中，其業(yè)務(wù)層和展示層在一起部署；而在基于Serverless的部署視圖中，展示層可以托管在對(duì)象存儲(chǔ)服務(wù)中，業(yè)務(wù)層由FaaS托管，數(shù)據(jù)層由云數(shù)據(jù)庫(kù)托管，實(shí)現(xiàn)了3-Tier在物理上的獨(dú)立部署。同時(shí)，各層獨(dú)立擴(kuò)展，技術(shù)獨(dú)自演進(jìn)。
通過(guò)Serverless構(gòu)建三層架構(gòu)的寵物商店應(yīng)用
2．Serverless簡(jiǎn)化了開(kāi)發(fā)模式
微服務(wù)提供了豐富的框架，方便開(kāi)發(fā)者進(jìn)行開(kāi)發(fā)，但同時(shí)也增加了開(kāi)發(fā)者的認(rèn)知負(fù)擔(dān)，同樣是使用Java，基于Serverless開(kāi)發(fā)服務(wù)，開(kāi)發(fā)者只需掌握J(rèn)ava的基礎(chǔ)特性、函數(shù)編程框架及BaaS的SDK即可，如下圖所示。
基于Java的微服務(wù)開(kāi)發(fā)和函數(shù)開(kāi)發(fā)差異
函數(shù)的編程框架相比Spring/SpringBoot要簡(jiǎn)單很多，開(kāi)發(fā)者只需了解輸入輸出處理（通常為JSON）及如何處理業(yè)務(wù)邏輯。如下圖所示，Serverless系統(tǒng)可以是1∶1的觸發(fā)模型，每個(gè)請(qǐng)求被一個(gè)單獨(dú)的函數(shù)實(shí)例處理，每個(gè)實(shí)例可以被視為一個(gè)單獨(dú)的線程，系統(tǒng)自動(dòng)根據(jù)請(qǐng)求數(shù)量擴(kuò)展函數(shù)實(shí)例，開(kāi)發(fā)者不用理解Java的并發(fā)編程也可以輕松實(shí)現(xiàn)對(duì)高并發(fā)應(yīng)用的支持。
Serverless支持應(yīng)用的高并發(fā)
基于函數(shù)的編程模型，可以繼續(xù)對(duì)數(shù)據(jù)進(jìn)行抽象操作。例如，Azure Function提供的Data Binding功能，允許開(kāi)發(fā)者用一套配置和一種編程模型操作不同存儲(chǔ)服務(wù)的數(shù)據(jù)，讓開(kāi)發(fā)服務(wù)變得更加簡(jiǎn)單，降低開(kāi)發(fā)人員的認(rèn)知負(fù)擔(dān)，進(jìn)而提升開(kāi)發(fā)效率。
3．Serverless是不可變基礎(chǔ)設(shè)施的最佳實(shí)踐
Serverless直接以代碼方式部署，開(kāi)發(fā)者不用再考慮容器鏡像打包、鏡像維護(hù)等問(wèn)題。系統(tǒng)通常在部署時(shí)重新創(chuàng)建函數(shù)實(shí)例，在不使用時(shí)回收實(shí)例，每次處理用戶請(qǐng)求的可能都是全新的實(shí)例，降低了因?yàn)榄h(huán)境變化出錯(cuò)的風(fēng)險(xiǎn)。而這些部署及變更的過(guò)程，對(duì)用戶來(lái)說(shuō)只是更新代碼，其復(fù)雜度相比使用容器及Kubernetes大大降低。Serverless在擴(kuò)展性方面也具有優(yōu)勢(shì)。FaaS和BaaS對(duì)開(kāi)發(fā)人員來(lái)說(shuō)沒(méi)有“預(yù)先計(jì)劃容量”的概念，也不需要配置“自動(dòng)擴(kuò)展”觸發(fā)器或規(guī)則。縮放由Serverless平臺(tái)自動(dòng)發(fā)生，無(wú)須開(kāi)發(fā)人員干預(yù)。請(qǐng)求處理完成后，Serverless平臺(tái)會(huì)自動(dòng)壓縮計(jì)算資源，當(dāng)面對(duì)突發(fā)流量時(shí)，Serverless可以做到毫秒級(jí)擴(kuò)容，保證及時(shí)響應(yīng)。
基于Serverless的服務(wù)治理也更簡(jiǎn)單。例如，通過(guò)API網(wǎng)關(guān)服務(wù)可以對(duì)函數(shù)進(jìn)行SLA（服務(wù)水平協(xié)議）設(shè)置限流，函數(shù)請(qǐng)求出錯(cuò)后會(huì)自動(dòng)重試，直至進(jìn)入死信隊(duì)列，開(kāi)發(fā)者可以針對(duì)死信隊(duì)列進(jìn)行重放，最終保證請(qǐng)求得到處理。
Serverless平臺(tái)默認(rèn)對(duì)接了監(jiān)控、日志、調(diào)用鏈系統(tǒng)，開(kāi)發(fā)者無(wú)須再費(fèi)力單獨(dú)維護(hù)運(yùn)維的基礎(chǔ)設(shè)施。雖然當(dāng)前Serverless的監(jiān)控指標(biāo)并不如傳統(tǒng)的監(jiān)控指標(biāo)豐富，但是其更關(guān)注的是應(yīng)用的黃金指標(biāo)，如延遲、流量、錯(cuò)誤和飽和度。這樣可以減少?gòu)?fù)雜的干擾信息，使開(kāi)發(fā)者專注在用戶體驗(yàn)相關(guān)的指標(biāo)上。
Serverless的其他優(yōu)點(diǎn)
除了以上的技術(shù)創(chuàng)新，Serverless還有一些額外的優(yōu)點(diǎn)。
加快交付的速度：函數(shù)的代碼規(guī)模、測(cè)試規(guī)模相比微服務(wù)又降低了一個(gè)量級(jí)，可以更快地開(kāi)發(fā)、驗(yàn)證及通過(guò)持續(xù)交付流水線發(fā)布。
全功能團(tuán)隊(duì)構(gòu)建更加容易：微服務(wù)實(shí)施的關(guān)鍵之一在于全功能團(tuán)隊(duì)。全功能團(tuán)隊(duì)通常由不同角色（前后端開(kāi)發(fā)人員、DevOps等）組成。如果一段時(shí)間內(nèi)前端開(kāi)發(fā)任務(wù)較多，可能會(huì)出現(xiàn)前端開(kāi)發(fā)人員不足導(dǎo)致交付延期的情況，反之亦然。采用全棧工程師是一個(gè)有效的解決方案，但這樣的工程師比較稀缺，培養(yǎng)周期較長(zhǎng)。Serverless讓前后端技術(shù)棧統(tǒng)一變得更簡(jiǎn)單，比如使用Node.js、Swift、Flutter等統(tǒng)一前后端技術(shù)，開(kāi)發(fā)者從而可以使用一門(mén)技術(shù)實(shí)現(xiàn)前后端業(yè)務(wù)的開(kāi)發(fā)，最終使團(tuán)隊(duì)效率倍增。
Serverless和微服務(wù)的差異
為了說(shuō)明Severless開(kāi)發(fā)與微服務(wù)開(kāi)發(fā)的區(qū)別，表1-1對(duì)比了整個(gè)軟件開(kāi)發(fā)流程中微服務(wù)和Serverless在每個(gè)階段的活動(dòng)，從設(shè)計(jì)、開(kāi)發(fā)、上線到持續(xù)服務(wù)，Serverless相比微服務(wù)在開(kāi)發(fā)難度及工作量上大幅降低，最終體現(xiàn)為更少的業(yè)務(wù)上線時(shí)間和更穩(wěn)定的運(yùn)行質(zhì)量。
微服務(wù)和Serverless開(kāi)發(fā)的差異
* 本文節(jié)選自《華為Serverless核心技術(shù)與實(shí)踐》一書(shū)，歡迎閱讀此書(shū)了解更多內(nèi)容！
▊《華為Serverless核心技術(shù)與實(shí)踐》
劉方明，李林鋒，王磊?著
華為2012實(shí)驗(yàn)室自研的分布式內(nèi)核——華為元戎，作為底座支撐了華為終端云通過(guò)Serverless快速開(kāi)發(fā)和上線商業(yè)服務(wù)的應(yīng)用場(chǎng)景。本書(shū)以此為例，系統(tǒng)地剖析了構(gòu)建Serverless平臺(tái)的設(shè)計(jì)思路和實(shí)現(xiàn)方案，幫助讀者掌握理論知識(shí)和實(shí)踐方法。本書(shū)共分10章，內(nèi)容涵蓋了從微服務(wù)到Serverless演進(jìn)的機(jī)遇與挑戰(zhàn)、基礎(chǔ)知識(shí)與組件工具、當(dāng)前生態(tài)與發(fā)展方向，以及華為元戎創(chuàng)新構(gòu)建的有狀態(tài)函數(shù)編程模型、高性能函數(shù)運(yùn)行時(shí)、高效對(duì)接BaaS服務(wù)等一系列Serverless核心技術(shù)，并配套介紹了云數(shù)據(jù)庫(kù)、云存儲(chǔ)、云托管等一系列開(kāi)箱即用的Serverless后端服務(wù)。最后，以華為終端云AppGallery Connect平臺(tái)的翻譯服務(wù)作為應(yīng)用案例，完整展示了從技術(shù)選型、架構(gòu)設(shè)計(jì)、代碼示例到實(shí)現(xiàn)效果的端到端實(shí)踐經(jīng)驗(yàn)，啟發(fā)讀者活學(xué)活用Serverless技術(shù)。
本書(shū)可作為廣大開(kāi)發(fā)者、科研人員和信息專業(yè)的本科生與研究生等學(xué)習(xí)Serverless技術(shù)的入門(mén)讀物，也可作為云計(jì)算與分布式系統(tǒng)等領(lǐng)域從業(yè)人員深入了解Serverless架構(gòu)的參考書(shū)。
京東限時(shí)49元包郵，快快掃碼搶購(gòu)吧！
?
如果喜歡本文 歡迎?在看丨留言丨分享至朋友圈?三連 ?熱文推薦??
▼點(diǎn)擊閱讀原文，查看本書(shū)詳情~