建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容介紹了“Serverless平臺(tái)建設(shè)舉例分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
永德網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)公司2013年開創(chuàng)至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)公司。
1. Why-高德為什么要搞 Serverless
高德為什么要搞 Serverless？背景原因是高德 FY21 財(cái)年啟動(dòng)了一個(gè)客戶端上云項(xiàng)目。客戶端上云項(xiàng)目的主要目的是為了提升客戶端的開發(fā)迭代效率。
以前客戶端業(yè)務(wù)邏輯都在端上，產(chǎn)品需求的變更需要走客戶端發(fā)版才能發(fā)布，而客戶端發(fā)版需要走各種測試流程、灰度流程，解決客戶端崩潰等問題，目前的節(jié)奏是一個(gè)月一個(gè)版本。
客戶端上云之后，某些易變的業(yè)務(wù)邏輯放到云上來。新的產(chǎn)品需求在云端來開發(fā)，不用走月度的版本發(fā)布，加快了需求的開發(fā)迭代效率，離產(chǎn)研同頻的理想目標(biāo)又近了一步（為什么要說“又”，是因?yàn)楦叩轮耙沧隽艘恍﹥?yōu)化往產(chǎn)研同頻的方向努力，但是我們希望云端一體化開發(fā)可以是其中最有效的一個(gè)技術(shù)助力）。
1.1 目標(biāo)：客戶端開發(fā)模式--端云一體
雖然開發(fā)模式從以前的端開發(fā)轉(zhuǎn)變?yōu)楝F(xiàn)在的云 + 端開發(fā)，開發(fā)同學(xué)應(yīng)該還是原來負(fù)責(zé)相應(yīng)業(yè)務(wù)的同學(xué)，但是大家知道，服務(wù)端開發(fā)和客戶端開發(fā)顯然是有差異的，客戶端開發(fā)是面向單機(jī)模式的開發(fā)，服務(wù)端開發(fā)通常是集群模式，需要考慮分布式系統(tǒng)的協(xié)調(diào)、負(fù)載均衡、故障轉(zhuǎn)移降級(jí)等各種復(fù)雜問題。如果使用傳統(tǒng)的服務(wù)端模式來開發(fā)，這個(gè)過渡風(fēng)險(xiǎn)就會(huì)比較大。
Faas 很好地解決了這一問題。我們結(jié)合高德客戶端現(xiàn)有的 xbus 框架（一套客戶端上的本地服務(wù)注冊(cè)、調(diào)用的框架），擴(kuò)展了 xbus-cloud 組件，使得云上的開發(fā)就像端上開發(fā)一樣，目標(biāo)是一套代碼、兩地運(yùn)行，一套業(yè)務(wù)代碼既能在客戶端上運(yùn)行，也能在服務(wù)端上運(yùn)行。
高德客戶端主要有三個(gè)端：IOS、android、車機(jī)（類 Linux 操作系統(tǒng)）。主要有兩種語言：C++ 和 Node.js。傳統(tǒng)地圖功能：如地圖顯示、導(dǎo)航路徑顯示、導(dǎo)航播報(bào)等等，由于需要跨三個(gè)端，采用的 C++ 語言來開發(fā)。地圖導(dǎo)航基礎(chǔ)之上的一些地圖應(yīng)用功能，如行前/行后卡片、推薦目的地等，主要用 Node.js 來開發(fā)。
FY20 財(cái)年淘系前端團(tuán)隊(duì)開發(fā)了 Node.js Faas runtime。高德客戶端上云項(xiàng)目，Node.js 的部分就采用了現(xiàn)有的淘系的 Node.js runtime，來接入集團(tuán)的 Faas 平臺(tái)，完成 Node.js 這部分的一些業(yè)務(wù)上云。2020 年十一期間很好地支撐了高德的十一出行節(jié)業(yè)務(wù)。
C++ Faas 沒有現(xiàn)有的解決方案，因此我們決定在集團(tuán)的基礎(chǔ)設(shè)施之上做加法，新建 C++ Faas 基礎(chǔ)平臺(tái)，來助力高德客戶端上云。
1.1.1 端云一體的最佳實(shí)踐關(guān)鍵：客戶端和 Faas 之間的接口抽象
原本客戶端的邏輯移到 Faas 服務(wù)端上來，或者新的需求一部分在 Faas 服務(wù)端上開發(fā)，這里的成敗關(guān)鍵點(diǎn)在于：客戶端和 Faas 的接口協(xié)議定義，也就是 Faas 的 API 定義，好的 API 定義除了對(duì)系統(tǒng)的可維護(hù)性有好處以外，對(duì)后續(xù)支撐業(yè)務(wù)的迭代開發(fā)也很重要，好的 API 定義請(qǐng)參考谷樸大神的文檔：《API 設(shè)計(jì)最佳實(shí)踐的思考》。
理想情況下：客戶端做成一個(gè)解析 Faas 返回結(jié)果數(shù)據(jù)的一個(gè)瀏覽器。瀏覽器協(xié)議一旦定義好，就不會(huì)經(jīng)常變換，你看 IE、Chrome 就很少更新。當(dāng)然我們的這個(gè)瀏覽器會(huì)復(fù)雜一些，我們這個(gè)瀏覽器是地圖瀏覽器。如何檢驗(yàn)客戶端和 Faas 之間的接口定義好不好，可以看后續(xù)的產(chǎn)品需求迭代，如果有些產(chǎn)品需求迭代只需要在 Faas 上完成，不需要客戶端的任何修改，那么這個(gè)接口抽象就是成功的。
1.2 BFF 層開發(fā)提效
提到高德，大家首先想到的應(yīng)該是其工具屬性：高德是一個(gè)導(dǎo)航工具（這個(gè)說法現(xiàn)在已經(jīng)不太準(zhǔn)確了，因?yàn)楦叩逻@幾年在做工具化往平臺(tái)化的轉(zhuǎn)型，我們要做萬能的高德，高德的交易類業(yè)務(wù)正在興起，高德打車、門票、酒店等業(yè)務(wù)發(fā)展很迅猛）。
針對(duì)高德導(dǎo)航來說，相比集團(tuán)其他業(yè)務(wù)（如電商）來說，有大量的只讀場景是高德業(yè)務(wù)的一大技術(shù)特點(diǎn)。這些只讀場景里，大量的需求是 BFF（Backend For Frontend）類型的只讀場景。為什么這么說？因?yàn)閷?dǎo)航的最核心功能，例如 routing、traffic、eta 等都是相對(duì)穩(wěn)定的，這部分的主要工作在持續(xù)不斷地優(yōu)化算法，使得高德的交通更準(zhǔn)，算出的路徑更優(yōu)。這些核心功能在接口和功能上都是相對(duì)比較穩(wěn)定的，而前端需求是多變的，例如增加個(gè)路徑上的限寬墩提示等。
Faas 特別適合做 BFF 層開發(fā)，在 Faas 上調(diào)用后端相對(duì)穩(wěn)定的各個(gè) Baas 服務(wù)，F(xiàn)aas 服務(wù)來做數(shù)據(jù)和調(diào)用邏輯封裝、快速開發(fā)、發(fā)布。在業(yè)界，F(xiàn)aas 用的最多的場景也正是 BFF 場景（另外一個(gè)叫法是 SFF 場景，service for frontend）。
1.3 Serverless 是云時(shí)代的高級(jí)語言
FY21，高德是集團(tuán)內(nèi)第一個(gè)全面上云的 BU，雖然高德已經(jīng)全面上云了，但是這還不是云時(shí)代的終局，目前主要是全面 pouch 化并上云，容器方面做了標(biāo)準(zhǔn)化，在規(guī)模化、資源利用率方面可以全面享受云的紅利，但是業(yè)務(wù)開發(fā)模式上基本上還和以前一樣，仍是一個(gè)大型的分布式系統(tǒng)的寫法。對(duì)于研發(fā)模式來說還并沒有享受云的紅利，可以類比為我們現(xiàn)在是在用匯編語言的方式來寫跑在云上的服務(wù)。而 Serverless、云原生可以理解為云時(shí)代的高級(jí)語言，真正做到了 Cloud as a computer，只需要關(guān)注于業(yè)務(wù)開發(fā)，不需要考慮大型分布式系統(tǒng)的各種復(fù)雜性。
1.4 Go-Faas 補(bǔ)充 Go 語言生態(tài)
前面講到了因?yàn)榭蛻舳松显祈?xiàng)目，我們?cè)诎⒗镌?FC（函數(shù)計(jì)算）團(tuán)隊(duì)之上做加法，開發(fā)了 C++ Faas Runtime。不僅如此，我們還開發(fā)了 Go-Faas，我們?yōu)槭裁磿?huì)做 Go-Faas 呢？這里也簡單介紹一下背景，高德服務(wù)端 Go 部分的 qps 峰值已超百萬。高德已補(bǔ)齊了阿里各中間件的 Go 客戶端，和集團(tuán)中間件部門共建。可觀測性、自動(dòng)化測試體系也基本完善，目前 Go 生態(tài)已基本完善。補(bǔ)齊了 Go-Faas 之后，我們就既能用 Go 寫 Baas 服務(wù)，又能用 Go 寫 Faas 服務(wù)了，在不同的業(yè)務(wù)場景采用不同的服務(wù)實(shí)現(xiàn)方式，Go-Faas 主要應(yīng)用于上文提到的 BFF 場景。
2. How-技術(shù)方案介紹：在集團(tuán)現(xiàn)有基礎(chǔ)設(shè)施之上做加法
2.1 整體技術(shù)架構(gòu)
上文講了我們?yōu)槭裁匆鲞@個(gè)事情，接下來講我們具體是怎么做這個(gè)事情的，是如何實(shí)現(xiàn)的，具體的技術(shù)方案是什么樣的。
本著在集團(tuán)現(xiàn)有的基礎(chǔ)設(shè)施、現(xiàn)有的中間件基礎(chǔ)之上做加法的思想，我們和 CSE、阿里云 FC 函數(shù)計(jì)算團(tuán)隊(duì)合作共建，開發(fā)了 C++ Faas Runtime 和 Go Faas Runtime。整體和集團(tuán)拉通的技術(shù)架構(gòu)如下圖所示，主要分為研發(fā)態(tài)、運(yùn)行態(tài)、運(yùn)維態(tài)三個(gè)部分。
2.1.1 運(yùn)行態(tài)
先說運(yùn)行態(tài)，業(yè)務(wù)流量從我們網(wǎng)關(guān)進(jìn)來，調(diào)用到 FC API Server，轉(zhuǎn)發(fā)到 C++/Go Faas Runtime，runtime 來完成用戶函數(shù)里的功能。runtime 的架構(gòu)本文下一章節(jié)會(huì)具體介紹。
和 runtime container 一起部署的有監(jiān)控、日志、Dapr 各種 side car，side car 來完成各種日志采集上報(bào)功能，dapr side car 來完成調(diào)用集團(tuán)中間件的功能。
另外目前 dapr 還在試點(diǎn)的階段，調(diào)用中間件主要是通過 Broker 和各個(gè)中間件 proxy 來完成，中間件調(diào)用的有HSF、Tair、metaq、diamond 等中間件 proxy。
最后 Autoscaling 模塊來管理函數(shù)實(shí)例的擴(kuò)縮容，達(dá)到函數(shù)自動(dòng)伸縮的目的。這里的調(diào)度就有各種策略了，有根據(jù)請(qǐng)求并發(fā)量的調(diào)度、函數(shù)實(shí)例的 CPU 使用率的調(diào)度。也能提前設(shè)置預(yù)留實(shí)例數(shù)，避免縮容到 0 之后的冷啟動(dòng)問題。
底層調(diào)用的是集團(tuán) ASI 的能力，ASI 可以簡單理解為集團(tuán)的 K8S+ sigma（集團(tuán)的調(diào)度系統(tǒng)），最終的部署是 FC 調(diào)用 ASI 來完成函數(shù)實(shí)例部署，彈性伸縮的，部署的最小單位是上圖中的 pod，一個(gè) pod 里包含 runtime container 和 sidecar set container。
2.1.2 研發(fā)態(tài)
再來看研發(fā)態(tài)，運(yùn)行態(tài)決定函數(shù)是如何運(yùn)行的，研發(fā)態(tài)關(guān)注函數(shù)的開發(fā)體驗(yàn)，如何方便地讓開發(fā)者開發(fā)、調(diào)試、部署、測試一個(gè)函數(shù)。
C++ Faas 有個(gè)跨平臺(tái)的難點(diǎn)問題，C++ Faas runtime 里有一些依賴庫，這些依賴庫沒有 Java 依賴庫管理那么方便。這樣依賴庫的安裝比較麻煩，F(xiàn)aas 腳手架就是為了解決這個(gè)問題，調(diào)用腳手架，一鍵生成 C++ Faas 示例工程，安裝好各種依賴包。為了本地能方便地 debug，開發(fā)了一個(gè) C++ Faas Runtime Boot 模塊，函數(shù) runtime 啟動(dòng)入口在 boot 模塊里，boot 模塊里集成 runtime 和用戶 Faas 函數(shù)，可以對(duì) runtime 來做 debug 單步調(diào)試。
我們和集團(tuán) Aone 團(tuán)隊(duì)合作，函數(shù)的發(fā)布集成到 Aone 環(huán)境上了，可以很方便地在 Aone 上來發(fā)布 Go 或者 C++ Faas，Aone 上也集成了一鍵生成 example 代碼庫的功能。
C++ 和 Go Faas 的編譯都依賴相應(yīng)的編譯環(huán)境，Aone 提供了自定義編譯鏡像的功能，我們上傳了編譯鏡像到集團(tuán)的公共鏡像庫，函數(shù)編譯時(shí)，在函數(shù)的代碼庫里指定相應(yīng)的編譯鏡像，編譯鏡像里安裝了 Faas 的依賴庫、SDK等。
2.1.3 運(yùn)維態(tài)
最后來看函數(shù)的運(yùn)維監(jiān)控，runtime 內(nèi)部集成了鷹眼、sunfire 采集日志的功能，runtime 里面會(huì)寫這些日志，通過 sidecar 里的 agent 采集到鷹眼、或者 sunfire 監(jiān)控平臺(tái)上去（FC 是通過 SLS 來采集的）之后，就能使用集團(tuán)現(xiàn)有的監(jiān)控平臺(tái)來做 Faas 的監(jiān)控了，也能接入集團(tuán)的 GOC 報(bào)警平臺(tái)。
2.2 C++/Go Faas Runtime 架構(gòu)
上面講的是和 Aone、FC/CSE、ASI 集成的一個(gè)整體架構(gòu)，Runtime 是這個(gè)整體架構(gòu)的一部分，下面具體講講 Runtime 的架構(gòu)是怎樣的，Runtime 是如何設(shè)計(jì)和實(shí)現(xiàn)的。
最上面部分的用戶 Faas代碼只需要依賴 Faas SDK 就可以了，用戶只需要實(shí)現(xiàn) Faas SDK 里的 Function 接口就能寫自己的 Faas 了。然后如果需要調(diào)用外部系統(tǒng)，可以通過 SDK 里的 Http Client 來調(diào)用，如果要調(diào)用外部中間件，通過 SDK 里的 Diamond/Tair/HSF/metaq Client 來調(diào)用中間件就可以。SDK 里的這些接口屏蔽了底層實(shí)現(xiàn)的復(fù)雜性，用戶不需要關(guān)心這些調(diào)用最后是如何實(shí)現(xiàn)，不需要關(guān)心 runtime 的具體實(shí)現(xiàn)。
SDK 層就是上面提到的 Function 定義和各種中間件調(diào)用的接口定義。SDK 代碼是開發(fā)給 Faas 用戶的。SDK 做的比較輕薄，主要是接口定義，不包含具體的實(shí)現(xiàn)。調(diào)用中間件的具體實(shí)現(xiàn)在 Runtime 里有兩種實(shí)現(xiàn)方式。
往下是 Runtime的一個(gè)整體架構(gòu)。Starter 是 runtime 的啟動(dòng)模塊，啟動(dòng)之后，runtime 自身是一個(gè) Server，啟動(dòng)的時(shí)候根據(jù) Function Config 模塊的配置來啟動(dòng) runtime，runtime 啟動(dòng)之后開啟請(qǐng)求和管理監(jiān)聽模式。
再往下是 Service 層，實(shí)現(xiàn) SDK 里定義的中間件調(diào)用的接口，包含 RSocket 和 dapr 兩種實(shí)現(xiàn)方式，RSocket 是通過 RSocket broker 的模式來調(diào)用中間件的，runtime 里集成了 dapr（distributed application runtime），調(diào)用中間件也可以通過 dapr 來調(diào)用，在前期 dapr 試點(diǎn)階段，如果通過 dapr 調(diào)用中間件失敗了，會(huì)降級(jí)到 rsocket 的方式來調(diào)用中間件。
再往下就是 rsocket 的協(xié)議層，封裝了調(diào)用 rsocket 的各種 metadata 協(xié)議。dapr 調(diào)用是通過 grpc 方式來調(diào)用的。
最下面一層就是集成了 rsocket 和 dapr 了。
rsocket 調(diào)用還涉及到 broker 選擇的問題，upstream 模塊來管理 broker cluster、broker 的注冊(cè)反注冊(cè)、keepalive 檢查等等，LoadBalance 模塊來實(shí)現(xiàn) broker 的負(fù)載均衡選擇以及事件管理、連接管理、重連等等。
最后 runtime 里的 metrics 模塊負(fù)責(zé)鷹眼 trace 的接入，通過 filter 模式來攔截 Faas 鏈路的耗時(shí)，并輸出鷹眼日志。打印 sunfire 日志，供 sidecar 去采集。下圖是一個(gè)實(shí)際業(yè)務(wù)的 sunfire 監(jiān)控界面：
2.2.1 Dapr
dapr 架構(gòu)如下圖所示，具體可以參考官方文檔。
runtime 里以前調(diào)用中間件是通過 rsocket 方式來調(diào)用的，這里 rsocket broker 會(huì)有一個(gè)中心化問題，為了解決 outgoing 流量去中心化問題，和集團(tuán)中間件團(tuán)隊(duì)合作引入了 dapr 架構(gòu)。只是 runtime 層面集成了 dapr，對(duì)于用戶 Faas 來說無感知，不需要關(guān)心具體調(diào)用中間件是通過 rsocket 調(diào)用的還是通過 dapr 調(diào)用的。后面 runtime 調(diào)用中間件切換到 dapr 之后，用戶 Faas 也是不需要做任何修改的。
3. How-業(yè)務(wù)如何接入 Serverless
如前文所述，接入統(tǒng)一在 Aone 上接入。提供了 C++ Faas/Go Faas 的接入文檔。提供了函數(shù)的 example 代碼庫，代碼庫有各種場景的示例，包括調(diào)用集團(tuán)各種中間件的代碼示例。C++ Faas/Go Faas 的接入對(duì)整個(gè)集團(tuán)開發(fā)，目前已經(jīng)有一些高德以外的 BU，在自己的業(yè)務(wù)中落地了 C++ /Go Faas。Node.js Faas 使用淘寶提供的 runtime 和模板來接入，Java Faas 使用阿里云 FC 提供的 runtime 和模板來接入就可以了。
3.1 接入規(guī)范-穩(wěn)定性三板斧：可監(jiān)控、可灰度、可回滾
針對(duì)落地新技術(shù)大家可能擔(dān)心的穩(wěn)定性問題，我們的應(yīng)對(duì)法寶是阿里集團(tuán)的穩(wěn)定性三板斧：可監(jiān)控、可灰度、可回滾。建立 Faas 鏈路保障群，拉通上下游各相關(guān)業(yè)務(wù)方、基礎(chǔ)平臺(tái)一起，按照集團(tuán)的 1-5-10 要求，共同努力做到 1 分鐘之內(nèi)響應(yīng)線上報(bào)警、快速排查；5 分鐘之內(nèi)處理；10 分鐘之內(nèi)恢復(fù)。
為了規(guī)范接入過程，避免犯錯(cuò)誤引發(fā)線上故障，我們制定了 Faas 接入規(guī)范和 checkList，來幫助業(yè)務(wù)方快速使用 Faas。
可監(jiān)控、可灰度、可回滾是硬性要求，除此之外，業(yè)務(wù)方如果能做到可降級(jí)就更好了。我們的 C++ 客戶端上云業(yè)務(wù)，在開始試點(diǎn)階段，就做好了可降級(jí)的準(zhǔn)備，如果調(diào)用 Faas 端失敗，本次調(diào)用將會(huì)自動(dòng)降級(jí)到本地調(diào)用。基本對(duì)客戶端功能無損，只是會(huì)增加一些響應(yīng)延遲，另外客戶端上該功能的版本，可能會(huì)比服務(wù)端稍微老一點(diǎn)，但是功能是向前兼容的，基本不影響客戶端使用。
4. Now-我們目前的情況
4.1 基礎(chǔ)平臺(tái)建設(shè)情況
Go/C++ Faas Runtime 開發(fā)完成，對(duì)接 FC-Ginkgo/CSE、Aone 完成，已發(fā)布穩(wěn)定的 1.0 版本。
做了大量的穩(wěn)定性建設(shè)、優(yōu)雅下線、性能優(yōu)化、C 編譯器優(yōu)化，使用了阿里云基礎(chǔ)軟件部編譯器優(yōu)化團(tuán)隊(duì)提供的編譯方式來優(yōu)化 C++ Faas 的編譯，性能提升明顯。
C++/Go Faas 接入鷹眼、sunfire 監(jiān)控完成，函數(shù)具備了可觀測性。
池化功能完成，具備秒級(jí)彈性的能力。池化 runtime 鏡像接入 CSE，擴(kuò)一個(gè)新實(shí)例的時(shí)間由原來的分鐘級(jí)變?yōu)槊爰?jí)。
4.2 高德的 Serverless 業(yè)務(wù)落地情況
C++ Faas 和 Go Faas 以及 Node.js Faas 在高德內(nèi)部已經(jīng)有大量的應(yīng)用落地。舉幾個(gè)例子：
上圖中的前兩個(gè)圖是 C++ Faas 開發(fā)的業(yè)務(wù)：長途天氣、沿途搜。后兩個(gè)截圖是 Go-Faas 開發(fā)的業(yè)務(wù)：導(dǎo)航 tips、足跡地圖。
高德是阿里集團(tuán)內(nèi) Serverless 應(yīng)用落地規(guī)模最大 的BU，已落地的 Serverless 應(yīng)用，日常峰值超過十萬 qps 量級(jí)。
4.3 主要收益
高德落地了集團(tuán)內(nèi)規(guī)模最大的 Serverless 應(yīng)用之后，都有哪些收益呢？
首先第一個(gè)最重要的收益是：開發(fā)提效。我們基于 Serverless 實(shí)現(xiàn)的端云一體組件，助力了客戶端上云，解除了需要實(shí)時(shí)的客戶端發(fā)版依賴問題，提升了客戶端的開發(fā)迭代效率。基于 Serverless 開發(fā)的 BFF 層，提升了 BFF 類場景的開發(fā)迭代效率。
第二個(gè)收益是：運(yùn)維提效。利用 Serverless 的自動(dòng)彈性擴(kuò)縮容技術(shù)，高德應(yīng)對(duì)各種出行高峰就更從容了。例如每年的十一出行節(jié)、五一、清明、春節(jié)的出行高峰，不再需要運(yùn)維或者業(yè)務(wù)開發(fā)同學(xué)在節(jié)前提前擴(kuò)容，節(jié)后再縮容了。高德業(yè)務(wù)高峰的特點(diǎn)還不同于電商的秒殺場景。出行高峰的流量不是在 1 秒內(nèi)突然漲起來的，我們目前利用池化技術(shù)實(shí)現(xiàn)的秒級(jí)彈性的能力，完全能滿足高德的這個(gè)業(yè)務(wù)場景需求。
第三個(gè)收益是：降低成本。高德的業(yè)務(wù)特點(diǎn)，白天流量大、夜間流量低，高峰值和低谷值差異較大，時(shí)間段區(qū)分明顯。利用 Serverless 在夜間流量低峰時(shí)自動(dòng)縮容技術(shù)，極大地降低了服務(wù)器資源的成本。
5. Next-后續(xù)計(jì)劃
FC 彈內(nèi)函數(shù)計(jì)算使用優(yōu)化，和 FC 團(tuán)隊(duì)一起持續(xù)優(yōu)化彈內(nèi)函數(shù)計(jì)算的性能、穩(wěn)定性、使用體驗(yàn)。用集團(tuán)內(nèi)豐富的大流量業(yè)務(wù)場景，來不斷打磨好 C++/Go Faas Runtime，并最終輸出到公有云，普惠數(shù)字化轉(zhuǎn)型浪潮中的更多企業(yè)。
Dapr 落地，解決 outcoming 流量去中心化問題，逐步上線一些 C++/Go Faas，使用 Dapr 的方式調(diào)用集團(tuán)中間件。
Faas 混沌工程，故障演練，逃生能力建設(shè)。Faas 在新財(cái)年也會(huì)參與我們 BU 的故障演練，逐一解決演練過程中發(fā)現(xiàn)的問題。
接入邊緣計(jì)算。端云一體的場景下，F(xiàn)aas + 邊緣計(jì)算，能提供更低的延時(shí)，更好的用戶體驗(yàn)。
“Serverless平臺(tái)建設(shè)舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
新聞標(biāo)題：Serverless平臺(tái)建設(shè)舉例分析
網(wǎng)站鏈接：http://ef60e0e.cn/article/ijgeis.html
