摘要：參與者流量來自于內(nèi)部系統(tǒng)和外部流量，其中大部分來自于外部流量。水平擴(kuò)容服務(wù)的水平擴(kuò)容重要性不言而喻。

目前微店中臺團(tuán)隊為了滿足公司大部分產(chǎn)品、運(yùn)營以及部分后端開發(fā)人員的嘗鮮和試錯的需求，提供了一套基于圖形化搭建的服務(wù)端接口交付方案，利用該方案及提供的系統(tǒng)可生成一副包含運(yùn)行時環(huán)境定義可立即運(yùn)行的工程代碼，最后，通過 “某種serverless平臺” 實(shí)現(xiàn)生成后代碼的部署、CI、運(yùn)行、反向代理、進(jìn)程守、日志上報、進(jìn)程分組擴(kuò)容等功能。

這樣，產(chǎn)品和運(yùn)營人員可基于此種方式搭建的接口配合常用的cms系統(tǒng)實(shí)現(xiàn)簡單查詢需求如活動大促的自主“研發(fā)”上線，代碼的可靠性、穩(wěn)定性由中臺研發(fā)側(cè)提供的“某種serverless平臺”保障，有效支撐了多個業(yè)務(wù)快速上線，節(jié)省后端開發(fā)人員的人力與硬件資源的開銷（大多數(shù)需求下，nodejs業(yè)務(wù)對虛擬機(jī)的資源開銷小于java業(yè)務(wù)）。

此處并不講解接口搭建系統(tǒng)的原理與實(shí)現(xiàn)，只說明其與上文提到的 “某種serverless平臺” 的關(guān)系。

](https://si.geilicdn.com/viewm...

這是系統(tǒng)的全貌，部分細(xì)節(jié)由于敏感信息而省略。平臺使用方可基于每個功能組件搭建出一套復(fù)雜的業(yè)務(wù)流，在搭建階段，提供在線debug和日志功能，可用于排錯；在部署CI階段，可集成不同的運(yùn)行時平臺，既可以是自主實(shí)現(xiàn)的運(yùn)行時，也可是第三方云平臺；在運(yùn)行階段，通過使用agentool工具實(shí)時監(jiān)控當(dāng)前服務(wù)的性能，并可通過traceId一覽請求在各系統(tǒng)的全貌。

本節(jié)以資源隔離粒度為度量，介紹了我對三種serverless方案的取舍以及最終為何選擇了隔離程度更高的kubeless云平臺。

Parse Server提供了基礎(chǔ)功能：基于類與對象的權(quán)限控制、基于document的nosql存儲、簡易的用戶身份認(rèn)證、基于hook的自定義邏輯等，但經(jīng)過筆者的調(diào)查與論證，最終并沒有采用類似單進(jìn)程下基于函數(shù)隔離的Parse Server及類似方案，這有幾點(diǎn)原因：

Parse Server方案很重，額外引入了非常多不需要的功能，如權(quán)限控制、認(rèn)證、存儲等

服務(wù)隔離級別低，多個服務(wù)在一個進(jìn)程運(yùn)行，多個服務(wù)會在libuv層互相搶占CPU，互相影響對方的業(yè)務(wù)處理

水平擴(kuò)容難度大，針對單個服務(wù)的擴(kuò)容無法做到

底層基于express框架，無法滿足運(yùn)行時接口調(diào)用鏈路的trace追蹤

當(dāng)多個服務(wù)同時引入不同的資源如db、es或者服務(wù)創(chuàng)建的對象足夠多時，會存在Parse Server主進(jìn)程溢出的風(fēng)險，畢竟64位機(jī)的node堆內(nèi)存是有1.4GB上限的，盡管這個上限是可配置的

Parser Server發(fā)布的接口需通過其client調(diào)用，這在公司商用情況下需要做許多額外的配置才能滿足

Parse Server官網(wǎng)

為了解決多個服務(wù)搶占libuv的問題，我選擇了自主研發(fā)的 super-agent方案，通過其名稱便可知它是一個超級代理，但它不僅是代理，還是一個具有極簡功能且可靠的發(fā)布系統(tǒng)和運(yùn)行時容器；它是一個分布式應(yīng)用，節(jié)點(diǎn)間功能劃分明確；它同時提供實(shí)時調(diào)試功能。

super-agent是一個多角色分布式系統(tǒng)，它即可以看做node容器，也可看成serverless的node實(shí)現(xiàn)，它以進(jìn)程為粒度管理服務(wù)。它分為“協(xié)調(diào)者”和“參與者”，協(xié)調(diào)者實(shí)現(xiàn) 應(yīng)用CI部署、啟動、進(jìn)程維護(hù)與管理和反向代理功能，參與者實(shí)現(xiàn) 業(yè)務(wù)請求代理、接受協(xié)調(diào)者調(diào)度。

在super-agent架構(gòu)中，端口是區(qū)分服務(wù)的唯一標(biāo)識，端口對客戶端而言是透明的，這層端口資源的隔離由super-agent來做掉，因此多個服務(wù)可避免在libuv層的互相競爭，提供水平擴(kuò)容的可能性。

super-agent最核心的功能在于反向代理。由于每個服務(wù)都被包裝成有多帶帶端口的獨(dú)立HTTP應(yīng)用，因此當(dāng)用戶請求流量經(jīng)過前端轉(zhuǎn)發(fā)層后進(jìn)入super-agent，由其根據(jù)相關(guān)規(guī)則做二次轉(zhuǎn)發(fā)，目前支持基于 “路徑、端口”規(guī)則的轉(zhuǎn)發(fā)。

后端應(yīng)用部署需要進(jìn)行 “優(yōu)雅降級、流量摘除、健康檢查、應(yīng)用初始化完畢檢查、流量導(dǎo)入、所有參與節(jié)點(diǎn)的部署狀態(tài)查詢” 等步驟，需要妥善處理；同時，協(xié)調(diào)者負(fù)責(zé)協(xié)調(diào)眾多參與節(jié)點(diǎn)全部完成部署操作，這是一個分布式事務(wù)，需要做好事務(wù)出錯后的相關(guān)業(yè)務(wù)補(bǔ)償。

上圖并未畫出節(jié)點(diǎn)角色的區(qū)別，實(shí)際上只有參與者節(jié)點(diǎn)才真正接受用戶請求。

協(xié)調(diào)者流量全部來自于內(nèi)部系統(tǒng)，包括接受 “接口搭建系統(tǒng)”調(diào)用或者其他系統(tǒng)實(shí)現(xiàn)的dashboard服務(wù)；同時其會向參與者發(fā)送相關(guān)信令信息，如部署、擴(kuò)容、下線、debug等。

參與者流量來自于內(nèi)部系統(tǒng)和外部流量，其中大部分來自于外部流量。內(nèi)部流量則承載協(xié)調(diào)者的信令信息。

服務(wù)的水平擴(kuò)容重要性不言而喻。super-agent方案中，協(xié)調(diào)者負(fù)責(zé)管理服務(wù)的擴(kuò)容與邏輯分組。

此處的服務(wù)是通過服務(wù)搭建平臺通過拖拽生成的nodejs代碼，它是一個包含復(fù)雜業(yè)務(wù)邏輯的函數(shù)，可以是多文件。具體的，super-agent通過將該服務(wù)包裝成一個HTTP服務(wù)在多帶帶的進(jìn)程中執(zhí)行。因此，如果要對服務(wù)進(jìn)行水平擴(kuò)容，提供多種策略的選擇：

默認(rèn)每臺虛擬機(jī)或物理機(jī)一個服務(wù)進(jìn)程，總體上N個機(jī)器N個服務(wù)進(jìn)程

擴(kuò)容時默認(rèn)每臺機(jī)器再fork一個服務(wù)進(jìn)程，N機(jī)器2*N個服務(wù)進(jìn)程

為了更充分利用資源，可為每臺機(jī)器劃分為邏輯組，同時選擇在某幾個組的機(jī)器多帶帶擴(kuò)容

這些策略對下游應(yīng)用透明，只需選擇相關(guān)策略即可。

水平擴(kuò)容的缺點(diǎn)：每臺虛擬機(jī)或物理機(jī)資源有上限，一個正常的node進(jìn)程最多消耗1.4GB內(nèi)存，計算資源共享，在一臺8C16G的虛擬機(jī)上，最多可同時運(yùn)行16個服務(wù)。及時通過分組擴(kuò)容的方式，每當(dāng)擴(kuò)展新的虛擬機(jī)或物理機(jī)，都需要由super-agent根據(jù)分組信息實(shí)現(xiàn)進(jìn)程守護(hù)，同時每次服務(wù)CI部署也同樣如此。運(yùn)維管理上需要配合非常清晰明了的dashboard后臺才能快速定位問題，這點(diǎn)在多服務(wù)的問題上尤其突出。

super-agent提供消息機(jī)制，由搭建平臺中組件開發(fā)人員使用提供的serverless-toolkit工具debug相關(guān)邏輯，最終可在super-agent的協(xié)調(diào)者后臺查看實(shí)時debug結(jié)果。

super-agent是符合常規(guī)的基于業(yè)務(wù)進(jìn)程隔離的解決方案，它有效的支撐了微店的幾個活動及產(chǎn)品，雖然峰值QPS不高（100左右），但它也論證了super-agent的穩(wěn)定性及可靠性（線上無事故，服務(wù)無重啟，平穩(wěn)升級）。

但是，super-agent仍然存在幾個問題，它讓我們不得不另覓他法：

日常運(yùn)維困難，需要開發(fā)一系列后臺系統(tǒng)輔助運(yùn)維，這需要不少人力成本

這是一個典型的一機(jī)多應(yīng)用場景，當(dāng)部署super-agent時會對運(yùn)行其上的服務(wù)有所影響（重啟），盡管這個影響并不影響用戶訪問（此時流量已摘除），但仍然是個風(fēng)險點(diǎn)

水平擴(kuò)容實(shí)現(xiàn)繁瑣，當(dāng)下掉某幾臺參與節(jié)點(diǎn)時會帶來不少影響

基于kubeless的方案則是隔離最為徹底的解決方法，kubeless是建立在K8s之上的serverless框架，因此它可以利用K8s實(shí)現(xiàn)一些非常有用的特性：

敏捷構(gòu)建 - 能夠基于用戶提交的源碼迅速構(gòu)建可執(zhí)行的函數(shù)，簡化部署流程；

靈活觸發(fā) - 能夠方便地基于各類事件觸發(fā)函數(shù)的執(zhí)行，并能方便快捷地集成新的事件源；

自動伸縮 - 能夠根據(jù)業(yè)務(wù)需求，自動完成擴(kuò)容縮容，無須人工干預(yù)。

其中，自動伸縮則解決了 super-agent 的痛點(diǎn)。

kubeless中與我們緊密相關(guān)的有兩個概念：“function和runtime” ，function是一個統(tǒng)稱，它包括運(yùn)行時代碼、依賴以及其他配置文件；runtime則定義運(yùn)行時依賴的環(huán)境，是一個docker鏡像。

若要接入kubeless平臺，我們需要解決如下幾個問題：

開發(fā)自定義運(yùn)行時，滿足商用需求，如trace、日志分片、上報采集

自定義構(gòu)建鏡像，實(shí)現(xiàn)ts編譯

基于yaml的function創(chuàng)建、更新、刪除流程探索，并自動化

function部署，包括流量摘除、流量導(dǎo)入、業(yè)務(wù)健康檢查

中間件日志、業(yè)務(wù)日志、trace日志隔離與掛載

function運(yùn)行時用戶權(quán)限問題

水平擴(kuò)容探索與嘗試

資源申請規(guī)范指定與部署規(guī)范約定

因此，前進(jìn)的道路仍然很曲折，而且很多需求需要自己從源碼上去尋找解決方法。

kubeless實(shí)現(xiàn)的serverless體系中，function所在pod中的所有容器共享網(wǎng)絡(luò)和存儲namespace，但是默認(rèn)外網(wǎng)是不可訪問k8s集群的所有pods，因此需要通過一層代理實(shí)現(xiàn)請求的轉(zhuǎn)發(fā)，這就是“Service”。Service負(fù)責(zé)服務(wù)發(fā)現(xiàn)及轉(zhuǎn)發(fā)（iptables四層），因此在Kubeless或者K8s中不會直接通過pod IP來訪問服務(wù)，而是通過Service轉(zhuǎn)發(fā)四層流量完成。Service有K8s分配的cluserIp，clusterIp是集群內(nèi)部虛擬IP，無法被外部尋址，而是通過Kube-Proxy在容器網(wǎng)絡(luò)之上又抽象了一層虛擬網(wǎng)絡(luò)，Kube-Proxy負(fù)責(zé)Service的路由與轉(zhuǎn)發(fā)(關(guān)于kube-proxy細(xì)節(jié)，請看參考資料)。

Service后端對應(yīng)是一個或多個pods，這些pods中的一個容器則運(yùn)行相同的業(yè)務(wù)代碼。那么流量是如何路由至Service上來呢？這就涉及到Service的“發(fā)布”，常用的是Ingress。Ingress包括HTTP代理服務(wù)器和ingress controller，代理服務(wù)器負(fù)責(zé)將請求按照規(guī)則路由至對應(yīng)Service，這層需要Kube-Proxy實(shí)現(xiàn)虛擬網(wǎng)絡(luò)的路由；ingress controller負(fù)責(zé)從K8s API拉取最新的HTTP匹配規(guī)則。
](https://si.geilicdn.com/viewm...

自定義鏡像：這里的鏡像包括兩部分：構(gòu)建鏡像和運(yùn)行時鏡像。運(yùn)行時鏡像需要解決宿主代碼的魯棒性，以及提供 livenessProbe、readinessProbe、metric接口實(shí)現(xiàn)；構(gòu)建鏡像則負(fù)責(zé)構(gòu)建階段的操作，如編譯、依賴安裝、環(huán)境變量注入等操作。具體編寫可參考 implement runtime images)。

構(gòu)建鏡像參考1

關(guān)于function的CRUD操作，筆者先通過命令行走通整個流程后，又切換成基于yaml的配置文件啟動，使用yaml啟動好處在于：a，可使用kubeless自帶的流量導(dǎo)入與摘除策略 b，水平擴(kuò)容簡單 c，命令簡單 d，配置文件模板化，自動化

部署策略由于涉及到業(yè)務(wù)特點(diǎn)，此處不詳細(xì)介紹

日志的掛載是必要的，否則pod一旦重啟，容器內(nèi)的所有日志全部丟失。盡管會存在日志收集的操作，可是日志收集進(jìn)程大多數(shù)都是異步進(jìn)行，因此會存在丟失日志的情況。因此，必須通過掛載volumn的形式在K8s node上映射文件。但在這過程中會出現(xiàn)權(quán)限的問題，這在下一點(diǎn)說明

權(quán)限問題在于kubeless將function的執(zhí)行權(quán)限設(shè)置為非root。這是安全且符合常理的設(shè)定，但有時function需要root權(quán)限，這需要修改K8s的security context配置，需要謹(jǐn)慎處理

水平擴(kuò)容基于K8s的HPA組件完成，目前支持基于CPU和QPS等指標(biāo)進(jìn)行擴(kuò)容，目前筆者并未專門測試這項內(nèi)容，因為它足夠可靠

資源申請的指定需要符合每個公司的實(shí)際情況以及業(yè)務(wù)特點(diǎn)，以node技術(shù)棧為例，pod中每個容器設(shè)置1C2GB的內(nèi)存符合實(shí)際情況；而至于部署規(guī)范，則要兼顧運(yùn)行時容器的特點(diǎn)，合理配置K8s的node與pod、function的對應(yīng)關(guān)系

運(yùn)行在kubeless 中的函數(shù)和運(yùn)行在super-agent的代碼沒有什么不同，可是周邊的環(huán)境準(zhǔn)備可大大不同。為了讓kubeless中的function可以接入公司內(nèi)部中間件服務(wù)，筆者費(fèi)了不少功夫，主要集中在日志及收集部分。好在事在人為，解決的辦法總是多于失敗的方法。

目前，super-agent方案已承載了10+個線上應(yīng)用或活動，穩(wěn)定運(yùn)行4個月，資源使用率符合預(yù)期；

kubeless方案還未正式接入流量，等待進(jìn)一步做相關(guān)異常測試。

kubeless介紹
security-context
kube-proxy)