6月3日，百度雲智峰會上，工商銀行（以下簡稱"工行") 軟開雲計算實驗室的進階經理周文澤發表了《工商銀行 Serverless 函數計算落地實踐》的主題演講，分享了工行使用百度函數計算産品的落地過程。
演講主要包括如下5個方面的内容：
- 工行雲平台概述
- 為什麼要做 Serverless？
- 工行函數計算技術選型
- 落地場景介紹
- 未來規劃
1. 工行雲平台概述
工行雲平台從2012年開始建設，基于業界領先雲産品和主流開源技術，結合工行特色實作了金融級的自主定制研發和加強。
- 2012年：基于伺服器虛拟化軟體，自主研發和推廣第一代基礎設施雲
- 2015年：率先于同業首家基于開源 Docker 容器技術、微服務，建設應用平台雲，并在生産運用
- 2016年：完成網際網路金融高并發場景的試點并順利支撐快捷支付“雙11”大促、雞年賀歲币雲上發行
- 2017年：基于 OpenStack、Ceph 等業界開源技術，建設新一代基礎設施雲；同時基于 Kubernetes，建設企業級應用平台雲 PaaS 2.0
- 2018年：金融生态雲 SaaS 上線，啟動 Serverless1.0 自研工作
- 2020年：建設新一代雲平台建設，包括分行雲，與此同時也是啟動了 Serverless2.0 相關的規劃研究和建設工作。
工行雲平台包含如下四個方面的技術特色：
- 引入業界領先的雲産品，結合生産營運運維需求進行客戶化定制，建構新一代基礎設施雲。
- 通過引入開源容器技術 Docker、容器叢集排程技術 Kubernetes 等，自主研發建設應用平台雲。
- 基于HAProxy、Dubbo、ElasticSearch等建立負載均衡、微服務、全息監控、日志中心等配套雲生态。
- 基于 Kubernetes Operator 機制提供有狀态應用容器化部署及自動化運維能力，實作基礎技術平台彈性擴縮，落地 ElasticSearch、Zookeeper 等複雜應用容器化部署場景。
2. 為什麼要做 Serverless？
"不是說 Serverless 發展好就去做，而是考慮了具體業務場景"周文澤表示。
一方面工行已建立了較為完備的雲計算、分布式架構體系及容器雲平台，分布式服務體系建設成效也比較顯著，包括積累了大量可複用的業務服務資産，同時業務量上漲較快，核心業務平均交易量超5億筆每天，大量的業務往線上走，對業務改造壓力非常大，大量的業務需要快速做線上化的處理，針對手機銀行或者其他的PC端都會面臨這樣的情況；另一方面，商業銀行競争加劇及網際網路企業的跨界滲透，要求銀行資訊系統必須滿足快速創新需要。
在這個背景下，工行看到了Serverless 的能力，它可以幫助快速上線服務。
Serverless 函數計算的技術優勢總結下來有以下幾個方面：
- 開發：無需擔心基礎服務的穩定可靠，無需設計複雜的分布式架構，無需關心灰階限流日志方案的實作，隻需專注業務代碼開發。
- 上線：無需像普通容器鏡像一樣對應用進行各種部署配置，隻需釋出即可運作。
- 運維：無需關心擴縮容，無需擔心底層資源問題，無需擔心高故障恢複問題。
這些優勢對業務開發有非常大的吸引力。
3. 工行函數計算技術選型
如前文所述，工行于2018年啟動了 Serverless 1.0 的設計，下圖就是1.0的技術架構，主要是以 Knative+自研事件驅動架構并存為核心的一套技術方案，提供了以 FaaS+BaaS模式的函數計算能力和 Serverless container 模式。
工行 Serverless 1.0平台技術架構
Serverless 1.0平台在工行内部進行了小規模的落地試點工作，實作了動态伸縮過程中應用執行個體數0到N，N到0的能力。但随着一些對請求響應要求較高的應用開始接入，Serverless平台也逐漸出現一些問題，比如執行個體冷啟動速度較慢，每次釋出都需要制作新的鏡像等等。
工行 Serverless 2.0平台技術架構
2020年，基于 Serverless 1.0 平台的不足，設計了2.0函數計算平台技術架構。2.0平台在技術選型上以百度天合Stack的函數計算産品為核心，并與工行現有的分布式、雲計算技術平台做對接，為應用提供完整的函數核心引擎、函數管理能力、開發傳遞能力。
具體來講，Serverless 2.0平台主要提供了以下三個方面的能力：
- 函數事件觸發器：捕獲外部事件，形成統一的事件規範，并将事件指定給函數核心引擎進行執行。
- 函數核心引擎：函數控制器實作事件解析和事件轉發并實作函數執行個體的擴縮容，同時實作與行内各系統子產品對接，實作統一的資源供給、監控、報警、運維等能力。
- 函數管理：為應用提供 API 和 WEB 服務實作函數編輯和釋出，對接行内 VCDS 持續傳遞系統實作函數生産傳遞。
綜合上述能力，使用百度私有化 Serverless 函數計算産品對接工行存儲、日志、監控、持續內建等能力，建構了工行函數計算平台。
工行函數計算平台能力視圖
上圖是工行函數計算平台能力視圖，基本上包含了函數計算該有的标準能力：
- 管理平台：面向開發運維人員，提供函數管理、釋出管理和日志監控功能，覆寫函數的開發測試、運維監控全鍊路環節。
- 事件觸發器：目前已支援HTTP觸發器、定時觸發器、Kafka觸發器，并将陸續提供對象存儲觸發器、資料庫觸發器和日志觸發器。
- Runtime 執行環境：支援Java（1.8）、Python（3.6）、Node.js（10）三大行内主流運作時，支援自定義運作時(自定義鏡像)。
- 平台底層支撐：下沉日志、監控、報警等應用基礎支撐能力，降低應用開發成本。
4. 落地場景介紹
周文澤認為 Serverless 目前更适合作為微服務的一種補充而存在，多用于相對獨立、架構簡單的業務應用。
他具體介紹了三個主要場景：
一個是應用後端服務，通過在函數内組合多個API、渲染頁面、直接編寫業務邏輯等方式建構後端服務，主要有BFF接口聚合服務、服務端渲染SSR、靜态資源服務三種主流場景，這個多用于小程式、H5等場景；
第二是批量任務，主要是批量運作時間不一定，但是運作的時候占用大量的資源，平時空閑着，這種時候其實這種技術非常适合它，可以通過在函數内編寫批量處理邏輯，再通過函數工作流實作多個批量邏輯的組合，如文本批量核對；
第三是模型釋出，模型一個是用量不穩定，涉及到AI相關的服務，釋出頻率非常高，将訓練好的模型通過函數計算快速釋出提供服務，如RAS智能基金組合回測模型。
接下來對具體使用的場景執行個體進行了展開介紹：
首先是接口聚合的内容，以上是手機銀行和 PC 銀行簡單的示意圖，手機銀行和PC端個人網銀需求變動較多，手機端和 PC 端的背後對接了大量子應用，這些子應用邊界較強，每個管道都有各自的研發運維團隊，實作需求時需要多個團隊互相配合關聯，導緻需求響應可能不夠及時。
跟團隊溝通後，解決思路是部分業務場景使用 Nodejs 建構 BFF 層，基于 Midway.js 建構前後端一體化架構，業務功能使用函數計算進行開發，前端适配 H5/RN/Vue 大前端元件，後端适配原生 Node.js、Egg、Koa 等應用開發架構，以 JS 方法調用替換HTTP 調用開發，實作業務開發前後端技術棧、研發模式統一，這樣在開發的時候響應速度得到明顯提高。
第二個是場景服務端渲染，本身是不錯的技術，但是存在一個問題，對現有的應用來說如果做服務端渲染的改造成本非常高，要配置一系列負載均衡實作這個能力，想用但是覺得成本太高還是不用了，通過函數計算把這個服務端渲染整個包裝成一個技術的服務，在上面隻需要把邏輯寫完之後把函數釋出出去就可以渲染這個能力，不用部署額外負載均衡的能力，不用關心怎麼部署、怎麼高可用、怎麼監控......一系列不用關心，這樣服務端渲染采用的接受度非常強，這樣做出來的功能比如說針對移動端、PC 端速度有明顯的提高。
第三個是批量場景，最開始做 Serverless 的原因，是因為有一個應用的批量任務場景有高可用的要求，在批量文本核對任務對資料庫進行分庫之後，需要多個節點運作支撐，由于文本核對任務不定期執行，存在大量空閑時間段資源備援問題。這種情況下可以通過函數計算實作文本核對資源彈性化，抽取共性的資料擷取、資料加工、資料持久化和資料回傳等關鍵文本核對步驟為函數，通過函數計算平台彈性執行；依托函數計算服務，實作定時或kafka消息觸發的方式觸文本核對任務執行；利用函數工作流機制編排執行函數任務。
第四個場景是資料庫安裝的場景，在 MySQL 資料庫上雲之前，使用部署在每台主控端上的 agent 進行資料庫腳本部。MySQL 上雲後，由于資料庫容器未部署 agent ，應用資料庫版本安裝時需申請跳闆機進行中轉安裝，目前跳闆機節點存在多應用共用、多節點共用時資源無法隔離，跳闆機與資料庫關系映射無序，跳闆機部署完後資源閑置浪費等問題。這種情況下，使用函數計算運作 agent 直接連接配接節點進行 DB 更新，并利用 Kafka 觸發器進行事件觸發執行，同時在投産高峰期，可以同時運作更多的 agent 函數執行個體。
最後是模型釋出場景，工行的線下投顧業務需要針對客戶出具千人千面的基金組合政策，但是缺乏對基金組合曆史業績及表現的回測展示，需要有線上能力支撐準實時的回測，并需要頻繁且快速地釋出模型，對基金配置模型進行優化與提升，目前釋出機制上不夠靈活，每次新的模型一出來都要去發版是非常繁瑣的事情。 研發思路将基金組合回測遷移到函數計算平台，采用線上直接釋出模式，快速上線不同種類模型進行計算，快速向使用者展示結果。
5. 未來規劃
最後簡單分享工行對函數計算的下一步發展規劃：
第一，統一 BaaS 服務接口規範，通過類似微服務建構架構 Dapr 思路，形成通用接口形式如HTTP API、gRPC API，供函數内部進行調用，加快業務函數建構；
第二，運用雲原生 Java 技術，Java 是工行最主要的開發語言，而普通的 Java 存在啟動緩慢，記憶體占用大的問題，在 Serverless 場景下的運用會出現啟動緩慢的問題，需要引入 Quarkus、Spring Native 等雲原生Java 架構；
第三，推進 Serverless CloudIDE 建設，使用更加強大的 CloudIDE 産品如 JetBrains 的Projector，支付相對複雜的應用程式開發，同時也能最大程度保持現有開發人員使用IDEA 的開發習慣；
第四，建構函數模闆中心，函數計算整體開發較為友善，但仍可以進一步抽取通用的函數代碼，形成函數模闆，供開發人員進行使用，實作技術資産複用，進而更快實作業務功能開發。
通過提供以上四種産品能力，從開發、運作層面，為應用提供更友好的開發體驗，更快的啟動速度，進而增加業務應用的對産品的接受度。
關于百度 Serverless 函數計算産品
官網位址：
https://cloud.baidu.com/product/cfc.html
百度函數計算引擎 EasyFaaS 已開源，Star 有獎：
github.com/baidu/EasyFaaS
- End -
相關閱讀：
百度 Serverless 函數計算引擎 EasyFaaS 正式開源
掃描下方二維碼發送暗号“Serverless”加入技術交流群，技術問題随時答疑
了解更多微服務、雲原生技術的相關資訊，請關注我們的微信公衆号【雲原生計算】！