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

1.NBF

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

2.FaaS

2.1定義

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

2.2典型架構(gòu)

??

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

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

??

3.1 NBF-Platform Services

NBF的平臺(tái)能力主要分為三層 ：

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

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

(3)平臺(tái)能力：

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

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

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

服務(wù)運(yùn)維：服務(wù)的Serverless能力，混部能力，灰度能力和容災(zāi)降級(jí)能力等 。

3.2 NBF-Function Instances

NBF的函數(shù)實(shí)例對(duì)應(yīng)的就是長(zhǎng)在NBF服務(wù)市場(chǎng)的一個(gè)個(gè)服務(wù)背后的Bundle實(shí)現(xiàn)：

??

3.3 NBF-Event Sources

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

??

3.4 NBF-FaaS Controller

NBF的FaaS Controller包括三種類型：

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

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

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

4. NBF的FaaS能力

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

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

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

容器架構(gòu)設(shè)計(jì) :

??

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

(1)Serverless層

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

(2)NBF-OSGI Framework

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

a. 容器與Bundle通信：容器提供了import機(jī)制，通過這種方式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容器會(huì)為每個(gè)Bundle建立獨(dú)立沙箱，從加載機(jī)制上保證了Bundle代碼級(jí)別隔離，避免Bundle之間的類和資源沖突。

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

(3)容器托管的Bundle和Plugin

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

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

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

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

??

4.2 Bundle服務(wù)發(fā)布

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

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

??

4.3 服務(wù)的路由和管控—Broker

★ 4.3.1 Broker架構(gòu) ：

??

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

Broker Agent

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

(1)傳統(tǒng)的服務(wù)調(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服務(wù)調(diào)用跟原有的傳統(tǒng)調(diào)用方式?jīng)]啥區(qū)別， 對(duì)于@DynamicInject支持的幾種方式。

Broker Bundle

對(duì)于Broker Bundle核心功能包括以下幾塊核心功能：

4.3.1.1 BundleProxy

BundleProxy可以簡(jiǎn)單理解成是對(duì)Bundle運(yùn)行的代理機(jī)制，比如Bundle的主動(dòng)熔斷和被動(dòng)降級(jí)這些能力都是通過BundleProxy實(shí)現(xiàn)的，因?yàn)檫@些特性對(duì)于每個(gè)運(yùn)行Bundle都是統(tǒng)一的機(jī)制。

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

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

4.3.1.3 路由計(jì)算

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

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

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

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

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

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

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

路由計(jì)算又要再次提到我們先前提到過的SpiProxy了，SpiProxy的職能主要有兩個(gè)：

a.獲取SPIInfo，包括SPI的ClassName，SpiVersion和SpiCode等等

b.根據(jù)路由參數(shù)計(jì)算需要調(diào)用BundleId 然后再根據(jù)我們?cè)诜?wù)發(fā)現(xiàn)中提到的尋址策略，不難發(fā)現(xiàn)我們已經(jīng)可以生成NBF服務(wù)調(diào)用的URI，這就是NBF多態(tài)路由的核心原理 。

4.1.3.4 熔斷降級(jí)

熔斷降級(jí)包括兩個(gè)核心能力：被動(dòng)降級(jí)和主動(dòng)熔斷。

(1)被動(dòng)降級(jí)：被動(dòng)降級(jí)會(huì)在三種情況下觸發(fā)：服務(wù)找不到，服務(wù)返回異常和服務(wù)超時(shí)，這個(gè)時(shí)候服務(wù)調(diào)用會(huì)自動(dòng)路由到Bundle對(duì)應(yīng)的降級(jí)Bundle。用個(gè)簡(jiǎn)單的表格解釋下降級(jí)的含義 ：

??

(2)主動(dòng)熔斷：主動(dòng)熔斷是通過NBF設(shè)置基線指標(biāo)來實(shí)現(xiàn)的，如果超過服務(wù)的基線指標(biāo)，則路由到降級(jí)Bundle 。

??

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

4.1.3.5 流量管控

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

??

5. 服務(wù)的高可用運(yùn)維

5.1 NBF-Serverless能力

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

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

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

??

★ 5.1.1 Fast Auto-Scaling

Fast Auto-Scaling是CSE提供的核心基礎(chǔ)設(shè)施能力，毫秒級(jí)的彈性擴(kuò)容主要包括幾個(gè)步驟：

(1)種子機(jī)器的啟動(dòng) 種子機(jī)器的啟動(dòng)就是冷啟動(dòng)的過程，這個(gè)過程跟當(dāng)前集團(tuán)APP啟動(dòng)的方式無異，就是容器啟動(dòng)，鏡像加載和服務(wù)暴露的幾個(gè)步驟，因此冷啟動(dòng)的時(shí)間普遍來說是分鐘級(jí)別的。

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

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

★ 5.1.2 Fast Cold Start

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

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

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

★ 5.1.3 Fast Hot Start

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

★ 5.1.4 Serverless實(shí)踐

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

??

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

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

??

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

5.2 極速回滾

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

??

6.總結(jié)

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

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

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

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