爲何它有典型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之間的通訊機制。

1. 容器與Bundle通訊：容器提供了import機制，經過這種方式Bundle就可使用容器能力，好比Spring的context託管，好比AOP能力

<imported>
 <packages>
 <package>org.springframework</package>
 <package>org.apache.commons.logging</package>
 <package>org.aopalliance</package>
 <package>org.aspectj</package>
 </packages>
</imported>

1. Bundle隔離：NBF容器會爲每一個Bundle創建獨立沙箱，從加載機制上保證了Bundle代碼級別隔離，避免Bundle之間的類和資源衝突。
2. 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）傳統的服務調用方式：

@Autowired
ServiceA serviceA；
serviceA.invoke(params);

（2）Broker SPI調用方式：

@Autowired
BundleBroker bundleBroker;
bundleBroker.get(ServiceA.class).invoke(params);

（3）註解的調用方式：

@DynamicInject
ServiceA serviceA;
serviceA.invoke(params);

有了@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實現就是默認實現

@DynamicInject
private ConfigReadService configReadService;
ResultDO<List<ConfigDTO>> result = configReadService.queryConfig(new ConfigQuery);

（2）規則模式： 規則模式支持三種方式指定路由參數：Id(業務身份)，Expression(正則表達式)，Rule(規則表達式)。

// 指定bundleId方式, type默認爲ID
@DynamicInject(pattern = "drf")
// 指定正則方式
@DynamicInject(pattern = "^drf-hz.*$", type = "REG")
// 指定Rule方式
@DynamicInject(pattern = "{\"wareHouseId\":\"2001\"}", type = "RULE")

（3）動態模式： 動態模式指的是編碼時沒法肯定調用參數的場景，路由參數須要調用時傳入。

@DynamicInject
private DynamicInvoker<ConfigReadService> configReadServiceDynamic;
ResultDO<List<ConfigDTO>> result;
// 動態傳入bundleId
result = configReadServiceDynamic.getService(bundleId).queryConfig(new ConfigQuery);
// 動態傳入規則參數
Map<String, Object> params = new HashMap<>();
params.put("merchant", merchant);
result = configReadServiceDynamic.getService(params).queryConfig(new ConfigQuery);

路由計算又要再次提到咱們先前提到過的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和合做夥伴提供生態開放能力。

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。