FaaS—Function as a service，函數(shù)即服務。它是2014年由于亞馬遜的AWS Lambda的興起，而被大家廣泛認知。FaaS能力是NBF中的一項非常重要的能力，NBF是一個非典型的FaaS架構(gòu)，但是具備了典型的FaaS能力。文章將詳細介紹NBF的FaaS容器架構(gòu)、服務發(fā)布、服務路由和強大的Serverless能力以及NBF-FaaS在阿里大促期間的實踐心得。

1.NBF

NBF (New-Retail Business Framework) 是供應鏈中臺基礎技術(shù)團隊研發(fā)的新零售服務開放框架，提供了標準化業(yè)務定義、快捷服務開發(fā)和生態(tài)開放的能力，旨在為生態(tài)伙伴提供一整套完整的新零售PaaS和SaaS的解決方案。

2.FaaS

2.1定義

FaaS是Serverless的一種典型形式，由 Serverless平臺提供負載均衡、高可用、自動擴縮容、服務治理等最佳實踐，將這些最佳實踐對 Developer 透明化，進一步縮短 Developer 從想法到產(chǎn)品的時間，降低開發(fā)成本，同時保障 Developer 開發(fā)的服務的可靠性。通過事件驅(qū)動的方式，開發(fā)者的Function通過Event有效觸發(fā)，比如 HTTP 請求、消息事件等。

2.2典型架構(gòu)

??

• Event Sources Function 事件驅(qū)動的集合;
• Function Instances 提供服務的Function或微服務;
• FaaS Controller 管理Function的控制服務，比如典型的API Gateway或者BFF(Backend For Front)等;
• Platform Services Function依賴的平臺服務，如權(quán)限管理 API、對象存儲服務等。

3.NBF-FaaS架構(gòu)

??

3.1 NBF-Platform Services

NBF的平臺能力主要分為三層 ：

(1)Serverless平臺—CSE(Cloud Service Engine)：Serverless是FaaS平臺依賴的基礎能力，這一塊NBF與中間件CSE團隊深度合作，CSE提供快速的擴縮容的能力，可以在毫秒級別支持并行水平擴容和動態(tài)縮容，滿足業(yè)務的錯峰場景?；A技術(shù)團隊與CSE共建容器冷熱啟動的性能優(yōu)化以及Serverless運維工具(日志，監(jiān)控報警，鏈路跟蹤等)開發(fā)。

(2)NBF容器：NBF容器采用OSGI架構(gòu)，提供了Bundle完整的生命周期管理，包括Bundle的加載，啟動，卸載和注銷等等，以及容器和Bundle的隔離和通信能力。

(3)平臺能力：

服務發(fā)布：把Function/Bundle快速發(fā)布成服務的能力。

服務路由：服務多態(tài)，降級和Mock的路由能力。

服務管理：基于SPI和Bundle的版本管理和服務啟停能力。

服務運維：服務的Serverless能力，混部能力，灰度能力和容災降級能力等 。

3.2 NBF-Function Instances

NBF的函數(shù)實例對應的就是長在NBF服務市場的一個個服務背后的Bundle實現(xiàn)：

??

3.3 NBF-Event Sources

NBF的Event Sources是由流程中心提供的基于EventMap的服務編排能力：

??

3.4 NBF-FaaS Controller

NBF的FaaS Controller包括三種類型：

(1)流程中心調(diào)度服務 流程中心提供了調(diào)度SPI服務的事件驅(qū)動能力，包括流程事件，消息事件，定時事件等等，目前基本可以覆蓋所有的事件驅(qū)動的業(yè)務場景。

(2)Broker調(diào)用RPC服務 Broker支持多模式調(diào)用Bundle發(fā)布的RPC服務，包括服務的多態(tài)路由，降級路由和Mock路由等 。

(3)NBF-Rest調(diào)用HTTP服務，NBF-Rest支持調(diào)用Bundle發(fā)布的HTTP服務。

4. NBF的FaaS能力

4.1 Bundle生命周期管理——NBF容器

★ 4.1.1 NBF容器架構(gòu)

NBF容器管理了Bundle的加載，啟動，卸載和注銷的完整周期，并采用OSGI機制實現(xiàn)了容器和Bundle之間的隔離和通信能力。

容器架構(gòu)設計 :

??

NBF容器架構(gòu)主要分為三層：

(1)Serverless層

這一層NBF和CSE團隊共建，CSE負責實現(xiàn)Fast Auto-Scaling，目前已經(jīng)在雙十二和女王節(jié)等大促活動得到了充分驗證。NBF實現(xiàn)了Fast Cold Start和Fast Hot Start Fast Cold Start—優(yōu)化Bundle服務發(fā)布的冷啟動時間 Fast Hot Start—優(yōu)化Bundle服務Scaling up后的服務可用時間 底層依賴的CaaS服務目前也在跟隨CSE的節(jié)奏從Sigma3.0向ACK-EE遷移，未來將全面支持阿里云單元。

(2)NBF-OSGI Framework

NBF-OSGI Framework是采用OSGI機制實現(xiàn)了Bundle加載，啟動，卸載和注銷完整生命周期托管，目前在集團內(nèi)部絕對多數(shù)都是Pandora應用，集團中間件都是通過ModuleClassLoader插件式加載，因此目前NBF容器的Bundle加載方式也是建立在Pandora的加載機制之上的NBF-OSGI Framework提供了一整套Bundle的隔離機制，Bundle與容器的通信機制以及Bundle之間的通信機制。

a. 容器與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>

b. Bundle隔離：NBF容器會為每個Bundle建立獨立沙箱，從加載機制上保證了Bundle代碼級別隔離，避免Bundle之間的類和資源沖突。

c. Bundle之間通信：NBF容器持有BundleContext的全局管理器，支持Bundle把需要提供給其他Bundle使用的Context放到全局管理器中，從而實現(xiàn)了Bundle之間的通信。

(3)容器托管的Bundle和Plugin

Bundle無需多言，是業(yè)務方編寫的業(yè)務邏輯代碼 Plugin是NBF引擎提供的增值能力，采用插件化的方式進行加載，比如NBF-FaaS能力中最核心的服務發(fā)布能力。

★4.1.2 未來的NBF容器架構(gòu)

前面提到了由于目前集團內(nèi)部絕對多數(shù)都是Pandora應用，因此目前NBF的容器架構(gòu)是建立Pandora的加載機制上的，本質(zhì)上是Run在Pandora的容器內(nèi)的。而未來的NBF容器架構(gòu)是由NBF-OSGI Framework來托管外部容器，這些外部容器可以是Pandora容器，也可以是非Pandora容器，這樣就實現(xiàn)了NBF容器對于Pandora容器的依賴倒置。而對于Run在NBF-FaaS平臺的Bundle而言就具有更豐富的可變性。

NBF新容器架構(gòu) ：

??

4.2 Bundle服務發(fā)布

服務發(fā)布的核心原理如下圖比較詳細的介紹了NBF容器把Bundle發(fā)布成RPC服務的完整鏈路，核心主要包括三步：

• 依據(jù)路由表加載Bundle ;
• 通過NBF Framework加載和啟動Bundle ;
• 通過NBF Framework加載和啟動服務發(fā)布的Plugin 。

??

4.3 服務的路由和管控—Broker

★ 4.3.1 Broker架構(gòu) ：

??

Broker架構(gòu)主要分為：

Broker Agent

Broker Agent實現(xiàn)了Broker的SPI和Implement的分離，通過BrokerBundleLoader動態(tài)加載implement，這樣Broker的版本升級對于使用方而言是不用做代碼變更和重新發(fā)布。想想某些重型的二方庫版本升級，每個業(yè)務方都需要深度感知，是不是覺得會舒爽很多。SPI Proxy則實現(xiàn)了采用注解的方式來實現(xiàn)無侵入的服務調(diào)用，從傳統(tǒng)的服務調(diào)用方式遷移到NBF的服務調(diào)用方式易如反掌。舉個栗子：

(1)傳統(tǒng)的服務調(diào)用方式：

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

(2)Broker SPI調(diào)用方式：

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

(3)注解的調(diào)用方式：

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

有了@DynamicInject，是不是覺得NBF服務調(diào)用跟原有的傳統(tǒng)調(diào)用方式?jīng)]啥區(qū)別， 對于@DynamicInject支持的幾種方式。

Broker Bundle

對于Broker Bundle核心功能包括以下幾塊核心功能：

4.3.1.1 BundleProxy

BundleProxy可以簡單理解成是對Bundle運行的代理機制，比如Bundle的主動熔斷和被動降級這些能力都是通過BundleProxy實現(xiàn)的，因為這些特性對于每個運行Bundle都是統(tǒng)一的機制。

4.3.1.2 服務發(fā)現(xiàn)

服務發(fā)現(xiàn)主要職責怎么找到需要調(diào)用的服務，怎么生成調(diào)用服務的URI，拿HSF的服務尋址策略來對比，整個機制就簡單了 HSF的尋址URI: Proxy://IP:port/service/version/method 對于Broker服務發(fā)現(xiàn) IP和port對應的容器本身的網(wǎng)絡信息，這些可以通過APPName或者Armory分組以及未來serverless后的GroupId來獲取 serviceName，version這些數(shù)據(jù)就是第三層Broker數(shù)據(jù)層提供的spi和bundle元數(shù)據(jù)信息 有了這些基本信息以后，我們就可以生成NBF服務發(fā)現(xiàn)的URI了。

4.3.1.3 路由計算

在介紹路由計算之前，先介紹下先前提到@DynamicInject支持的幾種方式：默認模式，規(guī)則模式和動態(tài)模式。

(1)默認模式： 默認模式就是服務調(diào)用不需要指定任何路由參數(shù)，這種調(diào)用方式適合單Bundle實現(xiàn)的SPI，Bundle實現(xiàn)就是默認實現(xiàn)

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

(2)規(guī)則模式： 規(guī)則模式支持三種方式指定路由參數(shù)：Id(業(yè)務身份)，Expression(正則表達式)，Rule(規(guī)則表達式)。

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

(3)動態(tài)模式： 動態(tài)模式指的是編碼時無法確定調(diào)用參數(shù)的場景，路由參數(shù)需要調(diào)用時傳入。

@DynamicInject 
 private DynamicInvoker<ConfigReadService> configReadServiceDynamic; 
  
 ResultDO<List<ConfigDTO>> result; 
 // 動態(tài)傳入bundleId 
 result = configReadServiceDynamic.getService(bundleId).queryConfig(new ConfigQuery); 
  
 // 動態(tài)傳入規(guī)則參數(shù) 
 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.根據(jù)路由參數(shù)計算需要調(diào)用BundleId 然后再根據(jù)我們在服務發(fā)現(xiàn)中提到的尋址策略，不難發(fā)現(xiàn)我們已經(jīng)可以生成NBF服務調(diào)用的URI，這就是NBF多態(tài)路由的核心原理 。

4.1.3.4 熔斷降級

熔斷降級包括兩個核心能力：被動降級和主動熔斷。

(1)被動降級：被動降級會在三種情況下觸發(fā)：服務找不到，服務返回異常和服務超時，這個時候服務調(diào)用會自動路由到Bundle對應的降級Bundle。用個簡單的表格解釋下降級的含義 ：

??

(2)主動熔斷：主動熔斷是通過NBF設置基線指標來實現(xiàn)的，如果超過服務的基線指標，則路由到降級Bundle 。

??

在截圖的栗子中我們選用Bundle(供應鏈-批發(fā)服務-大潤發(fā)實現(xiàn))作為Bundle(供應鏈-批發(fā)服務-盒馬實現(xiàn))的降級Bundle，在超過基線指標100ms就會路由到降級Bundle。對于熔斷降級實現(xiàn)的核心原理就是我們先前提到過的BundleProxy，這些特性對于每個運行Bundle都是統(tǒng)一的機制，通過BundleProxy識別是否滿足主動熔斷和被動降級的條件，然后再代理執(zhí)行真正的Bundle 。

4.1.3.5 流量管控

流量管控提供了一種軟負載的能力，支持設置Bundle和降級Bundle之間的流量配比，我們?nèi)砸訠undle：供應鏈-批發(fā)服務-盒馬實現(xiàn)為例，以圖為證：

??

5. 服務的高可用運維

5.1 NBF-Serverless能力

在先前提到的NBF容器架構(gòu)中，NBF-Serverless能力是NBF容器架構(gòu)的重要基石，只有在Serverless實現(xiàn)毫秒級彈性擴縮容前提下，才能真正支撐錯峰場景，才能最大程度的節(jié)約機器資源。

只有在Serverless實現(xiàn)服務資源統(tǒng)一彈性調(diào)度的前提下，才能真正實現(xiàn)NBF的服務部署隔離，而不是目前通過定制容器規(guī)格(1Core2G,2Core4G,4Core8G等等)和Bundle混部的方式來實現(xiàn)Bundle部署隔離和機器資源之間的平衡。在這里一定要為NBF的深度合作伙伴——CSE團隊鼓個掌，他們已經(jīng)具備了毫秒級Auto-Scaling能力，為我們提供了可靠的基礎設施。

當然對于Serverless配套運維設施(日志，監(jiān)控報警，鏈路跟蹤等)和Serverless遷移到ACK-EE云單元這些事情，NBF和CSE都還在路上。那在NBF-Serverless能力的建設過程中，NBF又扮演什么角色呢?用一張圖來簡單表述下Serverless的實現(xiàn)原理以及CSE與NBF的職責劃分。

??

★ 5.1.1 Fast Auto-Scaling

Fast Auto-Scaling是CSE提供的核心基礎設施能力，毫秒級的彈性擴容主要包括幾個步驟：

(1)種子機器的啟動 種子機器的啟動就是冷啟動的過程，這個過程跟當前集團APP啟動的方式無異，就是容器啟動，鏡像加載和服務暴露的幾個步驟，因此冷啟動的時間普遍來說是分鐘級別的。

(2)種子分發(fā) 通過Fork2的技術(shù)實現(xiàn)了種子機器的內(nèi)存復制，而把內(nèi)存復制到擴容機器上的時間是極短的，因此CSE的Auto-Scaling可以毫秒級實現(xiàn)并行水平擴容。

(3)服務注冊 這個過程實際上就是在ConfigServer完成服務注冊，從而可以保障復制出來的Service Bean是可被調(diào)用的。

★ 5.1.2 Fast Cold Start

NBF在NBF-Serverless能力構(gòu)建中第一個重要事項就是實現(xiàn)冷啟動優(yōu)化，我們期望把冷啟動的啟動從分鐘級別優(yōu)化到秒級，因此調(diào)整了NBF Bundle的冷啟動機制：

(1)在Bundle創(chuàng)建機器分組和擴容分組的時候提前部署Engine。

(2)通過NBF的FaaS能力動態(tài)加載Bundle，原來，冷啟動時間=Pandora容器的啟動時間+Engine的啟動時間+Bundle的install和start時間，經(jīng)過優(yōu)化以后，冷啟動時間=Bundle的install和start時間。

★ 5.1.3 Fast Hot Start

由于當前的擴容機制是通過內(nèi)存復制實現(xiàn)的，而類似于UUID這種與機器有關(guān)的內(nèi)存變量的復制是不合適的，因此NBF的熱啟動優(yōu)化主要是提供了refresh內(nèi)存變量的機制。NBF的Framework托管了Bundle生命周期管理，也提供相應的Hook能力，通過這些Hook就能解決UUID這種問題。

★ 5.1.4 Serverless實踐

雖然目前Serverless運維配套能力還不夠完善，但是我們?nèi)匀辉谌ツ觌p十二和今年女王節(jié)上線了幾個P0級服務，驗證在大促場景下Serverless的穩(wěn)定性和毫秒級的Auto-Scaling能力。當然我們敢在S級的大促中驗證P0級服務也是有所依仗的，那就是NBF的熔斷降級和流量管控能力。

??

文描服務在女王節(jié)當天的QPS流量從4000+飆升到12萬，Serverless非常迅速的擴容到10臺，妥妥的支撐了業(yè)務峰值。而對于機器資源的節(jié)約就顯而易見了，原來文描服務根據(jù)業(yè)務體量常態(tài)部署的10臺，而Serverless目前只需要常態(tài)部署2臺(其實可以只部署1臺，2臺可以認為是容災)，而終態(tài)Serverless將解決長尾服務的問題，最終可以縮容到0臺，這樣對機器資源是更大程度的節(jié)約。

下圖是女王節(jié)期間的Serverless前后的指標體系對比 ：

??

從圖中的數(shù)據(jù)可以看出，整個文描服務在大促期間表現(xiàn)出來的系統(tǒng)穩(wěn)定性和服務穩(wěn)定性是完全可靠的，這也就充分驗證NBF-Serverless的可行性。

5.2 極速回滾

極速回滾是NBF服務高可用運維一種非常有效的手段。傳統(tǒng)的APP回滾方式是重新編譯、構(gòu)建、打包和部署，而NBF具備典型的FaaS能力，對于Bundle回滾只需要重新load指定回滾版本的Jar包而已，而NBF Engine又是常駐容器，因此Bundle回滾速度是非常之快的。

??

6.總結(jié)

文章比較詳細的介紹了NBF的FaaS能力，一句話總結(jié)：NBF是非典型的FaaS架構(gòu)，但是具備典型的FaaS能力。

開篇介紹了業(yè)界對于FaaS的廣泛定義，然后對比了FaaS典型架構(gòu)和NBF-FaaS的非典型架構(gòu)之間的關(guān)系，之后重點介紹NBF的FaaS能力，包括NBF的容器架構(gòu)，Bundle的服務發(fā)布和Bundle路由與管控的核心實現(xiàn)原理。最后表述了NBF的高可用運維能力，重點表述了NBF-Serverless的實現(xiàn)原理和具體實踐心得。現(xiàn)在NBF從生長的盒馬回歸到供應鏈中臺，為包括盒馬在內(nèi)的25個BU和合作伙伴提供生態(tài)開放能力。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??