雲原生FaaS初探

一、雲原生的概念

雲計算的概念最先由戴爾公司於1996年提出。2006年，亞馬遜公司率先推出了彈性計算雲（Elastic Compute Cloud，EC2）服務，隨後越來越多的企業開始逐步接受雲計算這一概念，並將應用逐步遷移到雲端，享受這一新型計算方式帶來的技術紅利。2009年，阿里巴巴率先開始研製具有完全自主知識產權的雲產品——飛天操作系統，由此揭開了中國雲計算的序幕。

縱觀軟件架構的演化歷史可以發現，任何新的底層軟硬件技術出現後，上層應用軟件都需要很長一段時間才能夠真正“認識”到新的軟硬件給上層應用軟件帶來的價值，並開發新的軟件架構，以便充分利用新軟硬件的能力。最典型的例子就是x86 CPU和服務器在面世二十多年後，以CORBA、EJB、RPC、瘦客戶端等爲主的多層架構才逐步成爲應用開發的主流架構。類似的還有容器技術，它最早是由FreeBSD於2000年在Jails中提出的，但真正得到大規模應用是在2013年Docker興起之後，而應用層的代表則是幾年之後基於容器的微服務架構。

對於雲計算這一新基礎設施來說，也是如此。在2015年之前，對於大多數應用來說，雲端只是一個用於計算的場所，開發人員所要做的就是將原來在私有數據中心或IDC中的應用，遷移到雲端。在遷移的過程中，應用無須重新編寫，只需要重新部署，因爲雲平臺提供的計算、存儲、網絡等，完全兼容應用遷移之前的計算環境。在遷移模式中，

• 應用通常會將原來的物理機部署模式改成虛擬機（規格更小）部署模式
• 存儲則選用兼容的塊存儲或者文件存儲
• 網絡使用SLB（Server Load Balancer，服務器負載均衡）替換傳統的負載均衡器，構建VPC（Virtual Private Cloud，虛擬私有云）或NAT（Network AddressTranslation，網絡地址轉換）網絡環境
• 使用雲數據庫替換原來的MySQL或SQL Server，或者自行在雲上搭建Oracle數據庫

遷移之後，應用的整體成本（Total Cost ofOwnership，TCO）因爲採用了“按量付費”的模式而大幅下降，同時，企業的IT支出從CapEx（Capital Expenditure，資本性支出）模式轉變爲OpEx（Operating Expense，管理支出）模式，整個IT支出變得更可控。

如果對遷移過程進行技術分析，就會發現大部分應用使用的技術或者產品都在進行“一對一”的替換，只有極少量應用會基於OSS（對象存儲服務）、MaxCompute（大數據計算服務）等雲服務進行部分重構。OSS能夠幫助解決分佈式狀態的存儲問題，而MaxCompute能夠解決數據倉庫的快速搭建和成本問題。但由於沒有或者只進行了少量重構，因此應用的技術棧本身幾乎沒有發生變化，也就是說，軟件的架構沒有發生變化，只是軟件運行的平臺和運維的技術體系發生了變化，即只有平臺層面的變化。而軟件在分佈式場景下需要解決的問題，包括穩定性、組件或服務之間的數據同步、整體的高可用或容災、CI/CD過程的自動化、資源利用率不高、端到端鏈路跟蹤等，仍然需要應用自行解決。這些問題並不會因爲應用遷移到了雲平臺就從根本上得到了解決。

當然，各雲平臺爲了幫助應用解決上述分佈式複雜性問題，不斷推出各類雲服務，但是由於應用架構本身並沒有發生變化，因此這些雲服務並不能幫助應用解決整體問題，只能從局部提升應用的效率。

面對大量的業務需求和場景迭代，很多雲平臺都提供非常專業的垂直領域服務，這些服務比企業基於開源自行搭建的系統具備更高的SLA（Service Level Agreement，服務等級協議）。比如，

• 在數據持久性方面，亞馬遜AWS的數據持久性可以達到99.9…%（11個9），阿里雲OSS的數據持久性甚至達到了99.9…%（12個9）
• 在跨可用區的高可用方面，阿里雲RocketMQ的高可用達到了99.95%，即使整個機房不可用也能繼續對外提供消息服務

如果不是應用的所有存儲訪問代碼都在S3或OSS上重構，那麼“木桶效應”就會凸顯，即整個系統的數據持久性將取決於能力最差的組件；如果應用不是將所有自持的開源組件都遷移到雲平臺上，那麼當一個機房出現故障時，應用仍然會出現高可用性的問題；如果應用不是基於FaaS（Function as a Service，功能即服務）技術開發的，那麼應用仍然需要自行解決單個組件不可用時的Fail Over（失效轉移）以及故障恢復時的Fail Back（失效後自動恢復）等問題。

可見，應用遷移到雲上並不代表從此以後就高枕無憂了，如果應用本身沒有基於“新”的雲服務進行重構，而是繼續採用“老”的架構，那麼即使業務運行沒有問題，應用也不能充分利用“新”的雲運行環境的能力。因爲這些架構是爲了“老”的分佈式運行環境而設計的，不是“雲原生的”，所以需要對這些架構以及圍繞這些架構建立的技術棧、工具鏈、交付體系進行升級，依託於雲技術棧將其重新部署、部分重構甚至全部重寫，才能將應用變成“雲原生的”，從而保證能夠充分利用雲計算的能力。

爲了讓應用能夠更好地使用雲的PaaS平臺能力開發SaaS（Software as a Service，軟件即服務），Heroku於2011年提出了十二因子應用的概念。十二因子應用適用於任何編程語言，通常被認爲是最早的雲原生應用的技術特徵，詳情請參考

之後，Pivotal於2015年明確地提出了雲原生的概念，指出雲原生是一種可以充分利用雲計算優勢構建和運行應用的方式。

在經過CNCF的修改後，最新版雲原生的定義爲：

“雲原生技術有利於各組織在公有云、私有云和混合雲等新型動態環境中構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。這些技術能夠構建容錯性好、易於管理和便於觀察的松耦合系統。結合可靠的自動化手段，雲原生技術使工程師能夠輕鬆地對系統做出頻繁和可預測的重大變更。”

上面三個主流的定義，分別從頂層架構原則、計算模型和代表技術的角度，對雲原生進行了描述。這些定義的共同點是它們都將雲原生看作一種新的計算方式，讓應用能夠充分使用雲的計算優勢。進一步分析這些定義所體現出的技術觀點，我們可以達成這樣一個共識：

只有結合雲原生所提供的雲服務，改造應用的架構，才能夠更好地使用雲原生技術，更好地構建彈性、穩定、松耦合的分佈式應用，並解決分佈式複雜性問題。此外，對架構的改造還意味着相關的開發模式、交付方式、運維方式等都要隨之改變，比如，採用微服務架構重寫應用，用聲明式API和自動化工具升級運維方式，等等。簡單來說，雲原生使得整個軟件的生產流水線都發生了巨大的變化，而具體的變化程度又取決於企業對雲原生的使用情況。

實際上，雲原生的範圍還不止於此。要正確實施雲原生這一新計算模式，還需要企業的IT決策者、架構師、開發人員與運維人員正確理解和應用雲原生的理念，利用合適的雲原生技術及產品。有太多的反例可以證明，僅靠單邊的技術升級是很難讓雲原生升級產生價值的。雲原生相關概念之間的關係如下圖所示。

在上圖中，現代化應用在不少場合與雲原生應用的概念是等同的，因爲它們的很多特徵都是相似的，比如，都採用了容器技術打包和交付，都具備很強的彈性能力等。這兩個概念的細微差別在於：現代化應用可以與雲相關，也可以與雲不相關；而云原生應用通常都與雲相關。

所以雲原生（或者說雲原生計算）應當包括雲原生技術、雲原生產品、雲原生架構以及構建現代化應用的開發理念，如DevOps，具體說明如下。

1. 雲原生產品和雲原生技術需要基於公有云、私有云或混合雲的雲基礎設施（IaaS）。
2. 雲原生架構和雲原生開發理念是基於雲原生技術和產品構建或實現的。注意，對於不是基於雲原生技術或者產品的架構和理念，如基於傳統物理服務器發佈、構建的DevOps，是不會被劃分到雲原生範疇的。
3. 現代化應用和雲原生應用是基於雲原生的架構和開發理念構建或實現的。

 

二、雲原生架構的四個不同成熟階段 

軟件能力成熟度模型（Capability Maturity Model for Software，CMM），作爲一種評估軟件實施能力和幫助企業改善軟件質量的方法，對於軟件企業在軟件的定義、實施、度量、控制和改善等各個階段的管理工作都進行了詳細描述。

1987年，美國的卡內基梅隆大學受美國國防部的委託，對軟件行業提出的軟件過程成熟度模型，隨後成爲國際上各軟件企業都接受並推崇的軟件評估標準。CMM包含初始級、可重複級、定義級、管理級和優化級5個級別，共計18個過程域、52個目標，以及300多個關鍵實踐。

相對CMM而言，雲原生架構的目標更簡單，主要是幫助企業改善軟件的架構，使其能夠快速、有效地享用雲計算提供的各種服務，提升軟件的交付效率，降低軟件的整體成本，提高軟件的交付質量。在這個框架下，很多基礎的軟硬件環境等都由雲廠商提供，且它們提供的雲服務往往都包含業界最佳實踐的產品及解決方案。雲廠商所具備的大量行業屬性的文檔也可以作爲模板供企業參考，以便企業能夠更好地梳理相關流程，實施這些雲服務。因此，可以用更簡單和更便於操作的方式對雲原生架構進行成熟度的定級，如下表所示。

 

 

三、ACNA（Alibaba Cloud Native Architecting）的概念

阿里巴巴爲大量各行各業的企業客戶提供了基於阿里雲服務的解決方案和最佳實踐，以幫助企業完成數字化轉型，並積累了大量經驗和教訓。阿里巴巴將企業的核心關注點、企業組織與IT文化、工程實施能力等多個方面與架構技術相結合，形成了阿里巴巴獨有的雲原生架構設計方法——ACNA（Alibaba Cloud Native Architecting）。

（1）ACNA的作用與目的

1. 提升研發團隊的能力，實現成本、進度計劃、功能和質量等目標。
2. 指導研發團隊控制研發和運維過程，優化IT組織結構並打造更加高效的軟件工程流程機制。
3. 引導研發團隊，在確定雲原生架構的成熟度以及定位雲原生化方面關鍵問題的過程中選擇改進策略。

（2）ACNA的實現步驟

1. 確定企業當前所處的雲原生架構成熟度級別。
2. 瞭解會對改進生產質量和優化過程起關鍵作用的因素。
3. 將工作重點集中在有限的幾個關鍵目標上，從而有效達到優化現有研發流程的效果，進而持續改進產品。

ACNA是一個“4+1”的架構設計流程，其中，“4”代表架構設計的關鍵視角，包括企業戰略視角（ACNA-S1）、業務發展視角（ACNA-S2）、組織能力視角（ACNA-S3）和雲原生技術架構視角（ACNA-S4）；“1”表示雲原生架構的架構持續演進閉環（ACNA-S5）。4個關鍵視角和1個閉環的關係（命名爲ACNA-G1）如下圖所示。

ACNA除了是一種架構設計方法，還包含對雲原生架構的評估體系、成熟度衡量體系、行業應用最佳實踐、技術和產品體系、架構原則、實施指導等。

0x1：ACNA-S1：企業戰略視角

任何架構都必須服務於企業戰略，雲原生架構也不例外！與以往架構的升級有所不同，雲原生架構的升級不僅是技術的升級，更是對企業核心業務生產流程（即通過軟件開發和運營構建數字化業務）的一次重構，雲原生架構升級的意義，如同工業時代用更自動化的流水線替換手工作坊一樣深刻。

企業必須清楚業務戰略與雲IT戰略之間的關係，即雲IT戰略只是對業務戰略進行必要的技術支撐，還是雲IT戰略本身也是業務戰略的一部分。通常，高科技公司會對雲計算提出更高的需求，比如，

• 通過大量使用雲廠商提供的AI技術爲用戶提供智能化的用戶體驗
• 使用IoT（物聯網）和音視頻技術爲用戶建立更廣泛、生動的連接
• 基於雲原生、AI等技術建立遠超競品的業內領先安全產品能力
• 等.....

實際上，在數字化轉型的今天，越來越多的企業認爲雲IT戰略應該在企業業務戰略中扮演技術賦能業務創新的重要角色，雲IT已經變成了“Cloud First”，甚至“Cloud Only”，只是在全部採用公有云還是採用混合雲的策略上存在一些差別。基於雲IT戰略，雲原生架構可以幫助企業實現泛在接入技術，構建數字化生態系統，還可以從技術的角度確保數字化業務的快速迭代，構建面向用戶體驗管理的數字基礎設施，持續優化IT成本，降低業務風險。

0x2：ACNA-S2：業務發展視角

阿里巴巴在爲企業提供雲服務和諮詢的過程中發現，數字化業務對技術架構的主要訴求是保證業務連續性、業務快速上線、業務成本控制，以及科技賦能業務創新。

• 業務連續性訴求主要是指數字化業務必須能夠爲用戶持續提供服務，不能因爲軟硬件故障或Bug導致業務不可用，還要能夠防止黑客攻擊、數據中心不可用、自然災害等意外事故發生。此外，當業務規模快速增長時，軟硬件資源的購買和部署一定要及時，以便企業能夠更好地拓展新用戶。
• 市場瞬息萬變，相較於傳統業務，數字化業務具有更靈活的特性，這就要求企業具備更快的“業務到市場”的能力，包括新業務快速構建、現有業務快速更新等。雲原生架構能夠深刻理解企業對這些能力的訴求，並在產品、工具、流程等多個層面進行不同程度的處理。需要注意的是，這些訴求同時對組織結構帶來新的要求，可能會要求應用進行徹底重構（比如微服務化）。
• 雲計算必須爲企業釋放成本紅利，幫助企業從原來的CaPex模式轉變爲OpEx模式，即不用事先購買大批軟硬件資源，而是用多少支付多少；同時，大量採用雲原生架構也會降低企業的開發和運維成本。有數據顯示，通過容器平臺技術可使運維支出成本降低30%。
• 傳統模式下，如果要使用高科技賦能業務，則會經歷一個冗長的選型、POC、試點和推廣的過程，而如果選擇使用雲廠商和第三方提供的雲服務，則可以更快速地應用新技術進行創新。因爲這些雲服務具備更快的連接速度和更低的試錯成本，且在不同技術的集成上具備統一平臺和統一技術依賴的優勢。

0x3：ACNA-S3：組織能力視角

雲原生架構升級是對企業的整個IT架構的徹底升級，每個組織在進行雲原生架構升級時，必須根據企業自身的情況量體裁衣，其中，組織能力和技術棧處於同等重要的地位。雲原生架構涉及的架構升級對企業中的開發、測試和運維等相關人員都帶來了巨大的影響，技術架構的升級和實現需要企業中相關組織的積極參與和配合。特別是在架構持續演進的過程中，需要類似“架構治理委員會”這樣的組織負責雲原生的規劃和落地，並不斷檢查和評估架構設計與執行之間是否存在偏差。

此外，雲原生架構的設計還需要考慮組織結構的改變。前面提到一個非常重要的雲原生架構原則就是服務化（包括微服務、小服務等），這個領域的一個典型原則就是康威定律，要求企業的技術架構與溝通架構必須保持一致，否則會導致畸形的服務化架構，甚至導致組織溝通成本上升和“扯皮”現象增多的問題。

企業需要考慮的另外一個很重要的問題就是，企業接受改變的程度如何，或者說，企業能夠快速進行組織結構調整，並保持業務穩定性的能力如何。雲原生架構升級要求大量的企業IT人員也進行技術體系的升級和崗位職能的重新設計，這勢必導致原本處於穩定和舒適區的技術領導者和底層員工必須破而再立，所以組織改變的風險不得不慎重考慮。

0x4：ACNA-S4：雲原生技術架構視角

從技術架構的維度看，ACNA認爲架構維度包含七個重要的領域，具體說明如下。

1. 服務化能力。用微服務或小服務構建業務，分離大塊業務中具備不同業務迭代週期的模塊，業務以標準化API等方式對模塊進行集成和編排；服務間採用事件驅動的方式集成，減少相互依賴；通過可度量建設不斷提升服務的SLA（Service Level Agreement，服務等級協議）能力。
2. 彈性能力。利用雲資源的特性，根據業務峯值和資源負載情況來自動擴充或收縮系統的規模，業務不再需要進行容量評估、按量付費。
3. 無服務器化程度。在業務中，應儘量使用雲服務，而不是自己持有第三方服務，特別是自己維護開源軟件的模式；應用的設計應儘量變換成無狀態模式，把有狀態的部分保存到雲服務中。進一步採用Serverless技術體系重構應用運行時，讓軟件的底層運維逐漸“消失”。
4. 可觀測性。IT設施需要得到持續治理，任何IT設施中的軟硬件發生錯誤後都要具備快速修復的能力，以避免影響業務，這就需要系統具備全面的可觀測性，內容涉及對傳統的日誌方式、監控、APM、鏈路跟蹤、服務質量（Quality of Service，QoS）度量等多個方面。
5. 韌性能力。韌性能力除了包括服務化中常用的熔斷、限流、降級、自動重試、背壓等特性之外，還包括高可用、容災、異步化等特性。
6. 自動化水平。關注開發、測試和運維三個過程的敏捷性，推薦使用容器技術自動化軟件構建過程、使用OAM標準化軟件交付過程、使用IaC（Infrastructure as Code，基礎設施即代碼）和GitOps等自動化CI/CD流水線和運維過程。
7. 安全能力。關注業務的數字化安全，在利用雲服務加固業務運行環境的同時，採用安全軟件生命週期開發，使應用符合ISO 27001、PCI/DSS、等級保護等安全要求。安全能力是基礎維度，要求在架構評測中關注，但它不會參與評分。

0x5：ACNA-S5：架構持續演進閉環

雲原生架構演進是一個不斷迭代的過程，每一次迭代都要經歷從企業戰略、業務訴求到架構設計與實施這樣一個完整的閉環，整體關係（命名爲ACNA-G2）如下圖所示。

下面就來詳細介紹架構持續演進閉環的關鍵輸入和實現過程。

1、關鍵輸入

1. 企業戰略視角（ACNA-S1）：包括數字化戰略訴求、技術戰略（特別是雲戰略）訴求、企業架構訴求等，建議量化描述創新效率提升百分比、IT成本降低值、風險成本降低值等。
2. 業務發展視角（ACNA-S2）：包括新業務（特別是數字化業務）的技術訴求、BI/AI（商業智能/人工智能）訴求、IoT（物聯網）訴求、用戶體驗訴求等，建議量化描述業務迭代速度提升值、用戶體驗改善百分比、業務開發效率提升百分比等。

2、關鍵過程

1. 識別業務痛點和架構債務（ACNA-S5-P1）：明確並量化業務痛點（比如，雲上雲下一套部署、端到端的可觀測性等）；技術債務依據各企業的具體情況而有所不同，通常包含容器化改造、CI/CD完善、微服務改造、老應用下線、遺留系統集成方案、非x86架構的轉移等。
2. 確定架構迭代目標（ACNA-S5-P2）：建議每次迭代不超過1年，並通過OKR（Objective and Key Result，目標與關鍵成果法）的方式，在目標中描述本次迭代的業務目標，在關鍵成果中量化業務價值和技術價值。注意，在確定迭代目標的時候，要充分識別架構升級的利益相關者（Stakeholder）及其價值訴求，避免出現項目很成功但是得不到業務方認同的情況。
3. 評估架構風險（ACNA-S5-P3）：風險和價值往往是一對矛盾體，不要因爲風險大而不做雲原生架構升級，也不要因爲迫切升級而忽視風險，建議在風險和價值間獲得平衡。P3階段的重點是識別風險類別和風險點，它們會根據企業所在行業和企業自身特性的不同而不同。風險類別通常包括組織風險、市場風險、技術風險、設計實現風險、實施落地風險、運維風險、IT文化風險、財務風險、數據風險、合規風險等。
4. 選取雲原生技術（ACNA-S5-P4）：P4階段需要從雲原生技術棧（ACNA-T5）中選取在本次迭代中需要採用的雲原生技術，也需要把採用該技術可能造成的風險和帶來的價值放在首位考慮。
5. 制訂迭代計劃（ACNA-S5-P5）：P5階段需要充分考慮是否每個里程碑都能夠得到各參與方的認同，一定要避免先閉門開發然後期望產出一個高價值產品的情況，因爲像雲原生架構升級這樣的項目，需要與各參與方深度合作，且在執行過程中很可能出現改變計劃和目標的情況。
6. 架構評審和設計評審（ACNA-S5-P6）：P6階段作爲改變企業整個生產流水線的重要架構升級，需要在技術上進行架構評審和重要設計評審，讓重要設計在各參與方之間得到認同，這也是減少整體風險的重要手段。
7. 架構風險控制（ACNA-S5-P7）：在P3階段確定了風險點之後，就需要馬上設定這些風險的監控方法和預警閾值，並在架構升級的過程中不斷監控這些閾值的變化情況，做到實時風險評估和預警。整體而言，在整個實施過程中，企業需要建立“識別—監控—評估—預警—改進”的風控閉環。
8. 迭代驗收和覆盤（ACNA-S5-P8）：爲了讓雲原生架構升級的下一個迭代取得成功，即使本次迭代已經成功驗收，也需要團隊客觀、深入地對本次迭代的得失進行復盤，特別是在組織能力、項目和產品的管理能力等軟技能。

 

四、雲原生架構成熟度模型

雲原生架構成熟度模型是一種能夠幫助企業找到當前軟件架構與成熟的雲原生架構之間的差距，從而在後續的架構優化迭代中進行鍼對性改善的評估模型。ACNA參考CMM（Capability Maturity Model，能力成熟度模型）的定義，從主要的架構維度定義了雲原生架構的成熟度模型。

我們需要注意到，ACNA的雲原生架構成熟度評估模型不會幫助企業從通用技術架構、應用架構或信息架構的維度進行評估，因此它並沒有幫助實施者梳理架構的核心利益相關者和架構交付合同。同時，評估模型本身也沒有對團隊核心人員技能以及組織的流程、文化和流水線建設進行評估，而是從基於雲的現代化應用這一特定的軟件技術架構進行評估。雖然這樣的評估範圍相對較小，但是更專業，可操作性更強。

此外，ACNA雲原生架構成熟度模型的評估對象不是企業或架構實施人員，而是某個具體軟件所採用的架構。因此，對於一個企業而言，可能部分軟件的評估結果是零級（初始級），部分軟件的評估結果是中級（發展級），這完全取決於每個軟件自身的架構情況。

ACNA雲原生架構設計共包含6個關鍵架構維度（Service+Elasticity+Serverless+Observability+Resilience+Automation，簡寫爲SESORA），在此我們先定義關鍵維度的成熟度級別，如下圖所示（命名爲ACNA-T1）。

結合雲原生架構的四個不同成熟階段，我們定義了整個架構的成熟度模型，如下圖所示。

 

五、阿里雲FaaS介紹 

0x1：產品架構

函數計算主要包含服務、函數、實例、運行環境、觸發器、層、應用中心等功能組件，具體產品組件架構圖如下圖所示。

0x2：核心功能

功能項		說明	相關文檔
多觸發器		函數計算支持HTTP觸發器以及OSS觸發器、SLS觸發器等多種事件驅動觸發器。此外，函數計算無縫集成事件總線EventBridge，進一步動態擴展函數的事件觸發源。	觸發器簡介
多語言執行環境		函數計算支持Java、Python、Node.js、PHP、Go及.NET Core語言，並且支持通過Custom Runtime的方式來構建其他語言的Runtime，例如Go Custom Runtime、Ruby Custom Runtime和PowerShell Custom Runtime等。爲了豐富使用場景，還提供自定義鏡像作爲運行環境的能力。	代碼開發概述
灰度發佈		通過線上新舊版本共存的灰度發佈方式，小範圍驗證新版本的能力，逐步切換流量到新版本。同時，可以快速地切換主版本和灰度版本，只需變更別名指向的版本號，即可完成新舊版本的平滑切換。	使用版本和別名實現灰度發佈
單實例多併發		爲了進一步減少實例資源使用量，優化資源成本，降低冷啓動，函數計算支持單實例多併發能力。默認情況下，函數的實例併發度爲1，即一個實例同時只會處理一個請求。當您設置單實例併發度大於1後，函數計算在彈性伸縮時，充分利用完一個實例的併發度後纔會創建新的實例。	設置實例併發度
可觀測	日誌服務	函數計算支持將函數調用執行的日誌存儲至阿里雲日誌服務SLS，再根據日誌服務中存儲的函數日誌來執行代碼調試、故障分析、數據分析等操作。	配置日誌
	指標監控	函數計算提供多層次、多維度的監控指標。通過實時監控和性能數據採集，並進行可視化展示，爲您提供端到端的監控排查路徑。	監控指標
	鏈路追蹤	阿里雲鏈路追蹤Tracing Analysis基於OpenTracing標準，兼容開源社區，爲分佈式應用的開發者提供了完整的分佈式調用鏈查詢和診斷，分佈式拓撲動態發現，應用性能實時彙總等功能。 函數計算與鏈路追蹤集成，支持使用Jaeger上傳鏈路信息，使您能夠跟蹤函數的執行，幫助您快速分析和診斷Serverless架構下的性能瓶頸，提高Serverless場景的開發診斷效率。	什麼是鏈路追蹤Tracing Analysis
應用中心		函數計算提供一站式Serverless應用管理。從一鍵管理應用到快速體驗，從GitOps流程到應用管理，幫助開發者快速完成應用從無到有再到多的過程。	使用函數計算快速搭建管理NAS的可視化應用

1、觸發器

觸發器是觸發函數執行的方式。在事件驅動的計算模型中，事件源是事件的生產者，函數是事件的處理者，而觸發器提供了一種集中、統一的方式來管理不同的事件源。在事件源中，當事件發生時，如果滿足觸發器定義的規則，事件源會自動調用觸發器關聯的函數。

1）場景示例

• 示例一 ：對象存儲OSS中的圖片狀態變更觸發函數執行。某應用使用對象存儲OSS存放上傳的圖片，您可以通過直接調用函數的方式去下載圖片進行處理，並將結果存入對象存儲OSS或者其他服務。如果對象存儲OSS能夠幫助我們關注新上傳的圖片，並且自動去調用關聯的函數，您無需再調用函數，從而簡化了開發和使用流程。OSS觸發器的作用就是關注這些事件並調用函數計算的函數。配置了OSS觸發器後，當有新圖片上傳，OSS觸發器會自動觸發函數下載並處理圖片。
• 示例二：日誌服務SLS中日誌更新觸發函數執行。某應用使用日誌服務SLS定時採集更新的日誌，您可以通過直接調用函數對增量的日誌進行查詢和分析。如果日誌服務SLS能夠幫助我們關注更新的日誌，並自動調用關聯的函數，您無需再調用函數。SLS觸發器的作用就是關注這些事件並調用函數計算的函數。配置了SLS觸發器後，當有日誌更新，SLS觸發器會自動觸發函數消費增量的日誌。
• 示例三：在指定時間觸發函數執行。某應用需要每隔1小時收集一次數據。您可以每隔1小時通過直接調用函數收集數據並處理。如果函數計算中的函數能每隔1小時自動執行，您無需再關注時間。定時觸發器的作用就是關注時間事件並調用函數計算的函數。配置了定時觸發器後，在指定的時間，定時觸發器會自動觸發函數收集和處理數據。

2）觸發器類型

按照觸發器集成方式，函數計算支持的觸發器分爲雙向集成觸發器、單向集成觸發器和EventBridge觸發器，三類觸發器的區別如下：

• 雙向集成觸發器：您既可以在函數計算又可以在事件源端配置觸發器。
• 單向集成觸發器：目前只支持在事件源端配置觸發器。
• EventBridge觸發器：支持在函數計算配置觸發器，同時支持在事件總線EventBridge創建函數觸發規則，無需在事件源端配置。

從函數調用方式的角度，觸發器又可以分爲同步調用觸發器和異步調用觸發器，兩種調用方式的區別如下所示。

• 同步調用：事件被函數處理後直接返回結果。例如，使用控制檯調用函數屬於同步調用。
• 異步調用：事件在寫入到函數計算內部隊列後返回結果，函數計算系統會保證該消息被可靠地處理。

雙向集成觸發器

觸發器名稱	調用方式	文檔鏈接
定時觸發器	異步調用	定時觸發器概述
OSS觸發器	異步調用	OSS觸發器概述
SLS觸發器	同步調用	SLS觸發器
CDN事件觸發器	同步調用	CDN事件觸發器概述
Tablestore觸發器	同步調用	Tablestore觸發器概述
MNS主題觸發器	異步調用	MNS主題觸發器
HTTP觸發器	同步調用	HTTP觸發器概述

單向集成觸發器

觸發器名稱	調用方式	示例鏈接
API網關觸發器	同步調用	API網關觸發器概述
DataHub單向觸發器	同步調用	DataHub單向觸發器

EventBridge觸發器

觸發器名稱	調用方式	示例鏈接
消息隊列RocketMQ版觸發器	同步調用	RocketMQ觸發器
消息隊列RabbitMQ版觸發器	同步調用	RabbitMQ觸發器
消息服務MNS隊列觸發器	同步調用	MNS隊列觸發器
消息隊列Kafka版	同步調用	Kafka觸發器
阿里雲官方事件源觸發器	同步調用	阿里雲產品事件觸發器

2、函數

爲滿足不同場景下的用戶需求，函數計算提供事件函數和HTTP函數兩種函數類型，支持內置運行時、自定義運行時和容器鏡像三種部署函數的方式。

1）函數類型

函數計算目前支持兩種類型的函數：

• 事件函數：事件函數適用於事件驅動模型中通過事件發生來調用關聯函數。
• HTTP函數：HTTP函數主要適用於快速構建Web應用等場景。

函數計算的編程模型中，入口函數的模型由函數名、函數入參和返回值三部分組成。其中，函數入參也可以調用代碼中定義的其他函數。

事件函數和HTTP函數在觸發方式和函數入參兩方面的區別如下。

函數類型	觸發方式	函數入參
事件函數	您可以通過觸發函數執行來實現某個特定功能。事件函數支持通過定時器、調用API/SDK或其他阿里雲服務的觸發器來觸發函數執行。支持創建任何除HTTP觸發器以外類型的觸發器，例如OSS觸發器、SLS觸發器、CDN事件觸發器、Tablestore觸發器和EventBridge觸發器等。關於支持的觸發器類型和更多信息，請參見觸發器簡介。所有支持類型的觸發器均可觸發事件函數。	以Node.js語言爲例，一個簡單的入口函數模型如下所示。   exports.handler = function(event, context, callback) { callback(null, 'hello world'); } 有關Node.js事件函數的更多信息，請參見事件請求處理程序（Event Handler）。有關其他編程語言的函數入參介紹，請參見開發語言列表。
HTTP函數	HTTP函數僅支持通過發送HTTP/HTTPS請求來觸發函數執行。您可以自行配置觸發方式，例如GET、POST、PUT、DELETE、HEAD和PATCH方式。 爲函數創建HTTP觸發器後，HTTP觸發器通過發送HTTP/HTTPS請求觸發函數執行。一個版本或別名下僅支持創建一個HTTP觸發器。具體信息，請參見HTTP觸發器概述。	以Node.js語言爲例，一個簡單的入口函數模型如下所示。   exports.handler = function(request, response, context) { response.send(null, 'hello world'); } 有關Node.js HTTP函數的更多信息，請參見HTTP請求處理程序（HTTP Handler）。有關其他編程語言的函數入參介紹，請參見開發語言列表。

2）部署方式 

從開發流程角度，函數的部署方式包括通過控制檯部署、通過Serverless Devs工具部署和調用API/SDK部署。具體信息，請參見使用控制檯創建函數、使用Serverless Devs管理函數資源和CreateFunction。

從Runtime類型角度，函數計算支持三種部署方式：使用內置運行時創建、使用自定義運行時創建、使用容器鏡像創建。您可以根據業務情況選擇不同的部署方式。

對比項	使用內置運行時創建	使用自定義運行時創建	使用容器鏡像創建
代碼包限制	最大支持10 GB原始代碼	最大支持10 GB原始代碼	最大支持10 GB未解壓鏡像
代碼包格式	ZIP、JAR（Java）、文件夾	ZIP、JAR（Java）、文件夾	參見什麼是容器鏡像服務ACR
是否支持GPU實例	不支持	不支持	支持
運行時環境	Node.js、Python、PHP、Java、.NET Core 、Go	無限制	無限制

0x3：工作流程

函數計算工作流程如下圖所示。

 

六、re-build改造對原始應用的必要依賴條件

• 計算/存儲分離
• 無狀態數據流處理應用 

 

七、重構過程

略

未完成重構的部分：

僅對多引擎部分進行了重構，多引擎和其他組件之間的分佈式和消息同步，依然採取的事原始分佈式架構的中間件，從宏觀上看依然存在scale-up瓶頸