為什么它有典型FaaS能力，卻是非典型FaaS架構？
FaaS—Function as a service，函數即服務。它是2014年由于亞馬遜的AWS Lambda的興起，而被大家廣泛認知。FaaS能力是NBF中的一項非常重要的能力，NBF是一個非典型的FaaS架構，但是具備了典型的FaaS能力。文章將詳細介紹NBF的FaaS容器架構、服務發布、服務路由和強大的Serverless能力以及NBF-FaaS在阿里大促期間的實踐心得。
1.NBF
NBF (New-Retail Business Framework) 是供應鏈中臺基礎技術團隊研發的新零售服務開放框架，提供了標準化業務定義、快捷服務開發和生態開放的能力，旨在為生態伙伴提供一整套完整的新零售PaaS和SaaS的解決方案。
2.FaaS
2.1定義
FaaS是Serverless的一種典型形式，由 Serverless平臺提供負載均衡、高可用、自動擴縮容、服務治理等最佳實踐，將這些最佳實踐對 Developer 透明化，進一步縮短 Developer 從想法到產品的時間，降低開發成本，同時保障 Developer 開發的服務的可靠性。通過事件驅動的方式，開發者的Function通過Event有效觸發，比如 HTTP 請求、消息事件等。
2.2典型架構
?? 
- Event Sources Function 事件驅動的集合;
- Function Instances 提供服務的Function或微服務;
- FaaS Controller 管理Function的控制服務，比如典型的API Gateway或者BFF(Backend For Front)等;
- Platform Services Function依賴的平臺服務，如權限管理 API、對象存儲服務等。
3.NBF-FaaS架構
?? 
3.1 NBF-Platform Services
NBF的平臺能力主要分為三層 ：
(1)Serverless平臺—CSE(Cloud Service Engine)：Serverless是FaaS平臺依賴的基礎能力，這一塊NBF與中間件CSE團隊深度合作，CSE提供快速的擴縮容的能力，可以在毫秒級別支持并行水平擴容和動態縮容，滿足業務的錯峰場景。基礎技術團隊與CSE共建容器冷熱啟動的性能優化以及Serverless運維工具(日志，監控報警，鏈路跟蹤等)開發。
(2)NBF容器：NBF容器采用OSGI架構，提供了Bundle完整的生命周期管理，包括Bundle的加載，啟動，卸載和注銷等等，以及容器和Bundle的隔離和通信能力。
(3)平臺能力：
服務發布：把Function/Bundle快速發布成服務的能力。
服務路由：服務多態，降級和Mock的路由能力。
服務管理：基于SPI和Bundle的版本管理和服務啟停能力。
服務運維：服務的Serverless能力，混部能力，灰度能力和容災降級能力等 。
3.2 NBF-Function Instances
NBF的函數實例對應的就是長在NBF服務市場的一個個服務背后的Bundle實現：
?? 
3.3 NBF-Event Sources
NBF的Event Sources是由流程中心提供的基于EventMap的服務編排能力：
?? 
3.4 NBF-FaaS Controller
NBF的FaaS Controller包括三種類型：
(1)流程中心調度服務 流程中心提供了調度SPI服務的事件驅動能力，包括流程事件，消息事件，定時事件等等，目前基本可以覆蓋所有的事件驅動的業務場景。
(2)Broker調用RPC服務 Broker支持多模式調用Bundle發布的RPC服務，包括服務的多態路由，降級路由和Mock路由等 。
(3)NBF-Rest調用HTTP服務，NBF-Rest支持調用Bundle發布的HTTP服務。
4. NBF的FaaS能力
4.1 Bundle生命周期管理——NBF容器
★ 4.1.1 NBF容器架構
NBF容器管理了Bundle的加載，啟動，卸載和注銷的完整周期，并采用OSGI機制實現了容器和Bundle之間的隔離和通信能力。
容器架構設計 :
?? 
NBF容器架構主要分為三層：
(1)Serverless層
這一層NBF和CSE團隊共建，CSE負責實現Fast Auto-Scaling，目前已經在雙十二和女王節等大促活動得到了充分驗證。NBF實現了Fast Cold Start和Fast Hot Start Fast Cold Start—優化Bundle服務發布的冷啟動時間 Fast Hot Start—優化Bundle服務Scaling up后的服務可用時間 底層依賴的CaaS服務目前也在跟隨CSE的節奏從Sigma3.0向ACK-EE遷移，未來將全面支持阿里云單元。
(2)NBF-OSGI Framework
NBF-OSGI Framework是采用OSGI機制實現了Bundle加載，啟動，卸載和注銷完整生命周期托管，目前在集團內部絕對多數都是Pandora應用，集團中間件都是通過ModuleClassLoader插件式加載，因此目前NBF容器的Bundle加載方式也是建立在Pandora的加載機制之上的NBF-OSGI Framework提供了一整套Bundle的隔離機制，Bundle與容器的通信機制以及Bundle之間的通信機制。
a. 容器與Bundle通信：容器提供了import機制，通過這種方式Bundle就可以使用容器能力，比如Spring的context托管，比如AOP能力
b. Bundle隔離：NBF容器會為每個Bundle建立獨立沙箱，從加載機制上保證了Bundle代碼級別隔離，避免Bundle之間的類和資源沖突。
c. Bundle之間通信：NBF容器持有BundleContext的全局管理器，支持Bundle把需要提供給其他Bundle使用的Context放到全局管理器中，從而實現了Bundle之間的通信。
(3)容器托管的Bundle和Plugin
Bundle無需多言，是業務方編寫的業務邏輯代碼 Plugin是NBF引擎提供的增值能力，采用插件化的方式進行加載，比如NBF-FaaS能力中最核心的服務發布能力。
★4.1.2 未來的NBF容器架構
前面提到了由于目前集團內部絕對多數都是Pandora應用，因此目前NBF的容器架構是建立Pandora的加載機制上的，本質上是Run在Pandora的容器內的。而未來的NBF容器架構是由NBF-OSGI Framework來托管外部容器，這些外部容器可以是Pandora容器，也可以是非Pandora容器，這樣就實現了NBF容器對于Pandora容器的依賴倒置。而對于Run在NBF-FaaS平臺的Bundle而言就具有更豐富的可變性。
NBF新容器架構 ：
?? 
4.2 Bundle服務發布
服務發布的核心原理如下圖比較詳細的介紹了NBF容器把Bundle發布成RPC服務的完整鏈路，核心主要包括三步：
- 依據路由表加載Bundle ;
- 通過NBF Framework加載和啟動Bundle ;
- 通過NBF Framework加載和啟動服務發布的Plugin 。
?? 
4.3 服務的路由和管控—Broker
★ 4.3.1 Broker架構 ：
?? 
Broker架構主要分為：
Broker Agent
Broker Agent實現了Broker的SPI和Implement的分離，通過BrokerBundleLoader動態加載implement，這樣Broker的版本升級對于使用方而言是不用做代碼變更和重新發布。想想某些重型的二方庫版本升級，每個業務方都需要深度感知，是不是覺得會舒爽很多。SPI Proxy則實現了采用注解的方式來實現無侵入的服務調用，從傳統的服務調用方式遷移到NBF的服務調用方式易如反掌。舉個栗子：
(1)傳統的服務調用方式：
(2)Broker SPI調用方式：
(3)注解的調用方式：
有了@DynamicInject，是不是覺得NBF服務調用跟原有的傳統調用方式沒啥區別， 對于@DynamicInject支持的幾種方式。
Broker Bundle
對于Broker Bundle核心功能包括以下幾塊核心功能：
4.3.1.1 BundleProxy
BundleProxy可以簡單理解成是對Bundle運行的代理機制，比如Bundle的主動熔斷和被動降級這些能力都是通過BundleProxy實現的，因為這些特性對于每個運行Bundle都是統一的機制。
4.3.1.2 服務發現
服務發現主要職責怎么找到需要調用的服務，怎么生成調用服務的URI，拿HSF的服務尋址策略來對比，整個機制就簡單了 HSF的尋址URI: Proxy://IP:port/service/version/method 對于Broker服務發現 IP和port對應的容器本身的網絡信息，這些可以通過APPName或者Armory分組以及未來serverless后的GroupId來獲取 serviceName，version這些數據就是第三層Broker數據層提供的spi和bundle元數據信息 有了這些基本信息以后，我們就可以生成NBF服務發現的URI了。
4.3.1.3 路由計算
在介紹路由計算之前，先介紹下先前提到@DynamicInject支持的幾種方式：默認模式，規則模式和動態模式。
(1)默認模式： 默認模式就是服務調用不需要指定任何路由參數，這種調用方式適合單Bundle實現的SPI，Bundle實現就是默認實現
(2)規則模式： 規則模式支持三種方式指定路由參數：Id(業務身份)，Expression(正則表達式)，Rule(規則表達式)。
(3)動態模式： 動態模式指的是編碼時無法確定調用參數的場景，路由參數需要調用時傳入。
路由計算又要再次提到我們先前提到過的SpiProxy了，SpiProxy的職能主要有兩個：
a.獲取SPIInfo，包括SPI的ClassName，SpiVersion和SpiCode等等
b.根據路由參數計算需要調用BundleId 然后再根據我們在服務發現中提到的尋址策略，不難發現我們已經可以生成NBF服務調用的URI，這就是NBF多態路由的核心原理 。
4.1.3.4 熔斷降級
熔斷降級包括兩個核心能力：被動降級和主動熔斷。
(1)被動降級：被動降級會在三種情況下觸發：服務找不到，服務返回異常和服務超時，這個時候服務調用會自動路由到Bundle對應的降級Bundle。用個簡單的表格解釋下降級的含義 ：
?? 
(2)主動熔斷：主動熔斷是通過NBF設置基線指標來實現的，如果超過服務的基線指標，則路由到降級Bundle 。
?? 
在截圖的栗子中我們選用Bundle(供應鏈-批發服務-大潤發實現)作為Bundle(供應鏈-批發服務-盒馬實現)的降級Bundle，在超過基線指標100ms就會路由到降級Bundle。對于熔斷降級實現的核心原理就是我們先前提到過的BundleProxy，這些特性對于每個運行Bundle都是統一的機制，通過BundleProxy識別是否滿足主動熔斷和被動降級的條件，然后再代理執行真正的Bundle 。
4.1.3.5 流量管控
流量管控提供了一種軟負載的能力，支持設置Bundle和降級Bundle之間的流量配比，我們仍以Bundle：供應鏈-批發服務-盒馬實現為例，以圖為證：
?? 
5. 服務的高可用運維
5.1 NBF-Serverless能力
在先前提到的NBF容器架構中，NBF-Serverless能力是NBF容器架構的重要基石，只有在Serverless實現毫秒級彈性擴縮容前提下，才能真正支撐錯峰場景，才能最大程度的節約機器資源。
只有在Serverless實現服務資源統一彈性調度的前提下，才能真正實現NBF的服務部署隔離，而不是目前通過定制容器規格(1Core2G,2Core4G,4Core8G等等)和Bundle混部的方式來實現Bundle部署隔離和機器資源之間的平衡。在這里一定要為NBF的深度合作伙伴——CSE團隊鼓個掌，他們已經具備了毫秒級Auto-Scaling能力，為我們提供了可靠的基礎設施。
當然對于Serverless配套運維設施(日志，監控報警，鏈路跟蹤等)和Serverless遷移到ACK-EE云單元這些事情，NBF和CSE都還在路上。那在NBF-Serverless能力的建設過程中，NBF又扮演什么角色呢?用一張圖來簡單表述下Serverless的實現原理以及CSE與NBF的職責劃分。
?? 
★ 5.1.1 Fast Auto-Scaling
Fast Auto-Scaling是CSE提供的核心基礎設施能力，毫秒級的彈性擴容主要包括幾個步驟：
(1)種子機器的啟動 種子機器的啟動就是冷啟動的過程，這個過程跟當前集團APP啟動的方式無異，就是容器啟動，鏡像加載和服務暴露的幾個步驟，因此冷啟動的時間普遍來說是分鐘級別的。
(2)種子分發 通過Fork2的技術實現了種子機器的內存復制，而把內存復制到擴容機器上的時間是極短的，因此CSE的Auto-Scaling可以毫秒級實現并行水平擴容。
(3)服務注冊 這個過程實際上就是在ConfigServer完成服務注冊，從而可以保障復制出來的Service Bean是可被調用的。
★ 5.1.2 Fast Cold Start
NBF在NBF-Serverless能力構建中第一個重要事項就是實現冷啟動優化，我們期望把冷啟動的啟動從分鐘級別優化到秒級，因此調整了NBF Bundle的冷啟動機制：
(1)在Bundle創建機器分組和擴容分組的時候提前部署Engine。
(2)通過NBF的FaaS能力動態加載Bundle，原來，冷啟動時間=Pandora容器的啟動時間+Engine的啟動時間+Bundle的install和start時間，經過優化以后，冷啟動時間=Bundle的install和start時間。
★ 5.1.3 Fast Hot Start
由于當前的擴容機制是通過內存復制實現的，而類似于UUID這種與機器有關的內存變量的復制是不合適的，因此NBF的熱啟動優化主要是提供了refresh內存變量的機制。NBF的Framework托管了Bundle生命周期管理，也提供相應的Hook能力，通過這些Hook就能解決UUID這種問題。
★ 5.1.4 Serverless實踐
雖然目前Serverless運維配套能力還不夠完善，但是我們仍然在去年雙十二和今年女王節上線了幾個P0級服務，驗證在大促場景下Serverless的穩定性和毫秒級的Auto-Scaling能力。當然我們敢在S級的大促中驗證P0級服務也是有所依仗的，那就是NBF的熔斷降級和流量管控能力。
?? 
文描服務在女王節當天的QPS流量從4000+飆升到12萬，Serverless非常迅速的擴容到10臺，妥妥的支撐了業務峰值。而對于機器資源的節約就顯而易見了，原來文描服務根據業務體量常態部署的10臺，而Serverless目前只需要常態部署2臺(其實可以只部署1臺，2臺可以認為是容災)，而終態Serverless將解決長尾服務的問題，最終可以縮容到0臺，這樣對機器資源是更大程度的節約。
下圖是女王節期間的Serverless前后的指標體系對比 ：
?? 
從圖中的數據可以看出，整個文描服務在大促期間表現出來的系統穩定性和服務穩定性是完全可靠的，這也就充分驗證NBF-Serverless的可行性。
5.2 極速回滾
極速回滾是NBF服務高可用運維一種非常有效的手段。傳統的APP回滾方式是重新編譯、構建、打包和部署，而NBF具備典型的FaaS能力，對于Bundle回滾只需要重新load指定回滾版本的Jar包而已，而NBF Engine又是常駐容器，因此Bundle回滾速度是非常之快的。
?? 
6.總結
文章比較詳細的介紹了NBF的FaaS能力，一句話總結：NBF是非典型的FaaS架構，但是具備典型的FaaS能力。
開篇介紹了業界對于FaaS的廣泛定義，然后對比了FaaS典型架構和NBF-FaaS的非典型架構之間的關系，之后重點介紹NBF的FaaS能力，包括NBF的容器架構，Bundle的服務發布和Bundle路由與管控的核心實現原理。最后表述了NBF的高可用運維能力，重點表述了NBF-Serverless的實現原理和具體實踐心得。現在NBF從生長的盒馬回歸到供應鏈中臺，為包括盒馬在內的25個BU和合作伙伴提供生態開放能力。
【本文為51CTO專欄作者“阿里巴巴官方技術”原創稿件，轉載請聯系原作者】
