精品国产黄色电影,美女操逼片,久久国产精品久久,操逼在线观看,www.俺去啦,国产成人大香蕉在线免费,7777男人的天堂,日本黄色视频在线观

點擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”

回復(fù)”669“獲取獨家整理的精選資料集

回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」

作者 | 搜索中臺團隊

出品?| 百度Geek說

一、背景

搜索中臺內(nèi)容計算架構(gòu)支持了數(shù)十個業(yè)務(wù)線的上百個檢索場景，每個場景的數(shù)據(jù)都有一定的差異性，之前這些差異性都是由業(yè)務(wù)同學(xué)通過自定義的腳本進行獨立開發(fā)。這些腳本存在開發(fā)成本高、維護成本高的情況，我們引入了業(yè)務(wù)框架+服務(wù)平臺，實現(xiàn)了業(yè)務(wù)可以獨立開發(fā)、自動部署和上線，同時代碼庫可以復(fù)用，一定程度上解決了開發(fā)成本和維護成本的問題。伴隨業(yè)務(wù)快速發(fā)展，自定義入場開發(fā)的場景和訴求越來越多，在此過程中出現(xiàn)了以下問題：

學(xué)習(xí)成本大: 業(yè)務(wù)框架做了抽象，業(yè)務(wù)要上手開發(fā)需要學(xué)習(xí)完整的接入規(guī)范、開發(fā)規(guī)范，有的場景可能只要較少的業(yè)務(wù)代碼開發(fā)，但是學(xué)習(xí)時間卻要一周甚至更久，在新場景接入、尤其是簡單業(yè)務(wù)場景，越來越多的情況下，學(xué)習(xí)成本變成了個棘手問題
資源成本高: 很多的業(yè)務(wù)場景有潮汐式特征，即每天只有一小段時間有內(nèi)容計算，假設(shè)它只有1小時有，那么之前的架構(gòu)浪費了23/24的資源，即另外23小時沒有任何計算確占著資源，導(dǎo)致巨大的資源浪費
維護成本高: 搜索自身的復(fù)雜性，導(dǎo)致出現(xiàn)問題的時候開發(fā)者排查異常困難，有時候強依賴某些有經(jīng)驗的同學(xué)，整個系統(tǒng)的維護成本越來越高

在業(yè)務(wù)接入越來越多、業(yè)務(wù)迭代也越來越高頻、業(yè)務(wù)的數(shù)據(jù)量越來越大的情況下，如何通過技術(shù)手段，實現(xiàn)開發(fā)成本、資源成本和維護成本的顯著提升？相信這個問題，也是一個業(yè)務(wù)系統(tǒng)經(jīng)過一定發(fā)展后，大概率會遇到的一個問題。

二、思路與目標(biāo)

業(yè)界對于Serverless的大規(guī)模實踐主要是聚焦于Web端應(yīng)用，中后臺的實踐相對少一些。我們面對的場景是搜索中臺數(shù)據(jù)的實時計算，而搜索本身又是非常復(fù)雜的業(yè)務(wù)。但是通過對我們場景的抽象與分析，我們具備了在中后臺復(fù)雜場景實踐Serverless/FaaS的可行性：

一方面，雖然業(yè)務(wù)開發(fā)的功能需求千差萬別，本質(zhì)上仍然有很多通用共性的地方。對于業(yè)務(wù)特定化的處理邏輯都可以將邏輯轉(zhuǎn)化成一個一個的函數(shù)。而共性的功能可以通過抽象成通用組件。通過函數(shù)的編排和組件的復(fù)用可以樂高式搭建出適合業(yè)務(wù)的搜索數(shù)據(jù)計算系統(tǒng)。同時業(yè)務(wù)完全聚焦于業(yè)務(wù)自身邏輯中去，高可用、高并發(fā)、高擴展這些用戶都不需要關(guān)注, 極大的簡化的業(yè)務(wù)接入成本。
另一方面，由于業(yè)務(wù)流量的波峰波谷異常明顯，通過深入業(yè)務(wù)層的智能化調(diào)度的實現(xiàn)，不僅可以提升業(yè)務(wù)在流量峰值的擴展能力，而且通過調(diào)度可以實現(xiàn)資源的充分利用，節(jié)約大量的資源成本。同時，針對越來越復(fù)雜的的系統(tǒng)，必然導(dǎo)致問題的排查恢復(fù)的成本也越來越高，通過智能化控制系統(tǒng)的引入，實時發(fā)現(xiàn)分析處理異常問題，使得整個系統(tǒng)更穩(wěn)定更有韌性。

結(jié)合業(yè)務(wù)痛點，總結(jié)起來主要是兩方面的工作：

通過FaaS化建設(shè)，業(yè)務(wù)從聚焦于服務(wù)研發(fā)轉(zhuǎn)變?yōu)榫劢褂诤瘮?shù)開發(fā)，全面的提升業(yè)務(wù)的開發(fā)效率。這里的FaaS化改造不僅僅說的是技術(shù)底座的變革，更是全系統(tǒng)全流程整體的業(yè)務(wù)效率的提升。
通過智能化建設(shè)，讓架構(gòu)系統(tǒng)根據(jù)服務(wù)的容量和狀態(tài)進行動態(tài)調(diào)整，使得可以在追求更低資源成本的同時提供更高質(zhì)量服務(wù)。智能化建設(shè)即包括從0到n極致化的智能伸縮調(diào)度，還包括根據(jù)系統(tǒng)的多維度實時狀態(tài)信息進行智能分析自愈的智能控制系統(tǒng)。

三、FaaS化改造: 追求業(yè)務(wù)明顯感知的卓越效能

FaaS的極簡化的思維從直觀的角度上來說本身就會給業(yè)務(wù)帶來巨大的人效的提升，如下圖所示：

如上圖所示業(yè)務(wù)在過去的普通云化服務(wù)中需要關(guān)注內(nèi)容較多：從應(yīng)用程序本身、組件和數(shù)據(jù)，以及服務(wù)的運行時環(huán)境，到最后的服務(wù)容器等基礎(chǔ)設(shè)施的管理都需要業(yè)務(wù)方去關(guān)注。
當(dāng)業(yè)務(wù)轉(zhuǎn)變到FaaS化的思維中，業(yè)務(wù)需要開發(fā)處理的只是業(yè)務(wù)的一段邏輯表達，這里是以Function的方式表示，其他部分(包括組件、數(shù)據(jù)、運行時環(huán)境和基礎(chǔ)設(shè)施等一系列因素，業(yè)務(wù)甚至連原本應(yīng)用程序本身)都不需要管理。

搜索中臺內(nèi)容計算在FaaS化方面主要進行兩部分工作，其一是核心框架，其二是業(yè)務(wù)全流程系統(tǒng)建設(shè)，最終保證業(yè)務(wù)的開發(fā)效率與現(xiàn)在相比有根本性的轉(zhuǎn)變。

3.1 核心框架: 業(yè)務(wù)抽象與能力復(fù)用

核心框架是我們整個系統(tǒng)改造的基石，對業(yè)務(wù)來說主要包含兩部分:

極致抽象的業(yè)務(wù)框架：是核心框架基礎(chǔ)中的基礎(chǔ)，提供新的開發(fā)范式同時，為后續(xù)智能調(diào)度奠定良好基礎(chǔ)
高度復(fù)用的基礎(chǔ)服務(wù)：強大豐富的后端服務(wù)能力封裝，支持業(yè)務(wù)低成本復(fù)用，降低開發(fā)成本同時提升穩(wěn)定性。同時系統(tǒng)還提供強大的編排能力，低成本支持業(yè)務(wù)從簡單到復(fù)雜的發(fā)展

極致抽象的業(yè)務(wù)框架

業(yè)務(wù)框架作為FaaS層和業(yè)務(wù)代碼的載體，是整個業(yè)務(wù)邏輯的代碼框架。框架本身維護數(shù)據(jù)流語義，面向有向無環(huán)圖（DAG）的數(shù)據(jù)流，調(diào)用業(yè)務(wù)函數(shù)代碼。業(yè)務(wù)框架是面向有向無環(huán)圖的數(shù)據(jù)流實時計算，支持完備的流式計算語義：

業(yè)務(wù)端使用開發(fā)成本低的腳本語言進行開發(fā)（例如Python），基礎(chǔ)服務(wù)框架使用C++實現(xiàn)，通過架構(gòu)層面的優(yōu)化策略來達到服務(wù)性能和開發(fā)成本的平衡。

基礎(chǔ)框架的發(fā)展本身經(jīng)歷了兩個階段：

階段1:基礎(chǔ)框架引擎使用C++實現(xiàn)(原來業(yè)務(wù)框架階段基于腳本語言實現(xiàn))，架構(gòu)代碼與業(yè)務(wù)代碼的充分解耦，直接調(diào)用業(yè)務(wù)函數(shù)代碼，業(yè)務(wù)開發(fā)效率已經(jīng)有了質(zhì)的飛躍。
階段2:為了規(guī)避腳本語言在進程中只能使用單核（如Python、Php、JS等）特點，讓業(yè)務(wù)函數(shù)具備容器內(nèi)使用多核的能力，為后續(xù)支持極速擴容奠定基礎(chǔ)。

下面就來看下整體框架的構(gòu)成方式，看上圖右側(cè)部分:

流式計算框架: 我這邊是直接基于百度StreamCompute流式計算框架開發(fā)，該框架原生支持基礎(chǔ)流式計算數(shù)據(jù)流語義、支持拓?fù)浜瘮?shù)的編排描述，為整個FaaS提供堅實的基礎(chǔ)底座。大家實際使用過程中可以選取合適的流式計算框架開發(fā)。
數(shù)據(jù)預(yù)處理: 這里包含的功能比較多，從大體上協(xié)議解析、性能優(yōu)化和數(shù)據(jù)觀測等三個方面的工作

協(xié)議解析: 這里主要說明的框架的基礎(chǔ)通信協(xié)議的定義解析，為了各業(yè)務(wù)數(shù)據(jù)通用性定義為入?yún)?和出參均為原始字符串；
性能優(yōu)化: 接入數(shù)據(jù)流框架本身，通過批量順序讀寫、數(shù)據(jù)壓縮的方式提高數(shù)據(jù)穿入過程中的服務(wù)吞吐；
數(shù)據(jù)觀測: 進行基礎(chǔ)指標(biāo)匯報包括QPS、延時、內(nèi)部隊列等一系列信息，和異步的Trace信息(進入到Kafka中)。

進程管理&服務(wù)管理: 并不在數(shù)據(jù)的主通道上，主要是應(yīng)對整個容器內(nèi)部進程和服務(wù)的管理。

進程管理: 伴生服務(wù)，負(fù)責(zé)啟動、維護、銷毀整個子進程的生命周期。
服務(wù)管理: 伴生服務(wù)，負(fù)責(zé)初始化并且維護遠(yuǎn)端的rpc 的client，修改訪問參數(shù)，如超時、重試、下游訪問策略等。負(fù)責(zé)新進程的創(chuàng)建、回收，以及進程間交互信息的維護。

進程通信異步數(shù)據(jù)分發(fā): 這里有三個關(guān)鍵點:?數(shù)據(jù)不丟?、異常健全?和支持下游競爭消費。調(diào)研了包括數(shù)據(jù)管道通信、共享內(nèi)存、系統(tǒng)隊列和RPC等操作方式，考慮到穩(wěn)定性、擴展性和實現(xiàn)成本等因素選擇基于Baidu-RPC框架實現(xiàn)進程異步數(shù)據(jù)分發(fā)；

單進程模式：?當(dāng)進程個數(shù)為1的時候則跳過進程通信，直接在本進程內(nèi)部進行方法調(diào)用；
多進程模式：每個進程完全獨立啟動,業(yè)務(wù)視角隔離，但是公用一套業(yè)務(wù)代碼環(huán)境。子進程處理完成后將請求結(jié)果反饋給父進程。

業(yè)務(wù)邏輯處理: 主要包括校驗解析&函數(shù)調(diào)用&本地優(yōu)化加速幾部分，如上圖左邊就是業(yè)務(wù)邏輯處理的展開圖。

解析&校驗&優(yōu)化: 每個線程內(nèi)會進行參數(shù)解析協(xié)議校驗，為了方便老業(yè)務(wù)遷移，支持多用戶協(xié)議解析，線程并發(fā)優(yōu)化；
執(zhí)行引擎: 函數(shù)接口是真正函數(shù)調(diào)用地方，支持不同語言的調(diào)用引擎。eg: 如果業(yè)務(wù)使用Python，使用pybind。

數(shù)據(jù)提交: 執(zhí)行完成后會統(tǒng)一推送到本地輸出隊列，本地隊列里面的信息會異步提交到遠(yuǎn)端的消息隊列里面給后續(xù)算子消費。

高度復(fù)用的基礎(chǔ)服務(wù)

業(yè)務(wù)依賴的后端服務(wù)，包括多媒體長留服務(wù)，數(shù)據(jù)存儲服務(wù)，策略計算等十項服務(wù)能力，所有的服務(wù)架構(gòu)的支持目標(biāo)都是通過簡單配置、少量代碼的方式進行服務(wù)接入。

架構(gòu)通用能力：包括索引算分(倒排、正排、向量索引)，數(shù)據(jù)審核(政治敏感數(shù)據(jù)/色情數(shù)據(jù)識別&過濾)，多路分發(fā)、數(shù)據(jù)建庫等能力；
與業(yè)務(wù)聯(lián)合研發(fā)的能力：數(shù)據(jù)的低質(zhì)過濾能力(實現(xiàn)數(shù)據(jù)清洗/歸一化/數(shù)據(jù)去重/類目拼接)，數(shù)據(jù)多元融合，數(shù)據(jù)質(zhì)量打分計算(質(zhì)量打分/作弊識別/物料打分)
基于公司強大基礎(chǔ)能力: 多媒體處理服務(wù)(外鏈轉(zhuǎn)內(nèi)鏈/OCR/水印計算/重復(fù)圖計算/主體識別/視頻轉(zhuǎn)儲等)，自然語言處理服務(wù),數(shù)據(jù)沉淀服務(wù)

支持的BaaS服務(wù)主要是兩個特點:?簡單穩(wěn)定 & 充分集成公司內(nèi)其他優(yōu)質(zhì)能力。用戶通過SDK調(diào)用、算子復(fù)用和數(shù)據(jù)流復(fù)用等方式直接進行能力復(fù)用，完全不需要進行服務(wù)的部署和管理，服務(wù)易用性、穩(wěn)定性由搜索中臺來處理。使用任何服務(wù)后端都可以收口在一個地方，避免業(yè)務(wù)頻繁跟多個服務(wù)團隊進行交流處理，極大降低業(yè)務(wù)使用成本。

業(yè)務(wù)最開始接入通常只需要簡單的少數(shù)功能（例如，修改部分字段的信息)，多數(shù)業(yè)務(wù)直接用我們提供的平臺化的開發(fā)模板即可完成開發(fā)。但是隨著業(yè)務(wù)的逐步深耕,業(yè)務(wù)逐步使用，業(yè)務(wù)會向復(fù)雜逐步過渡，例如搜索中臺某業(yè)務(wù)通過復(fù)用超過8種能力的組合使用，建設(shè)出具有深度定制的數(shù)據(jù)系統(tǒng)。

3.2 全流程效能提升: 提供極簡的用戶使用體驗

如3.1中提到的核心框架是FaaS化的基礎(chǔ)但并不是全部。因為改造的底層邏輯是讓業(yè)務(wù)聚焦于開發(fā)業(yè)務(wù)邏輯。這個過程不僅僅包括代碼的開發(fā)階段，而是包括從接入、開發(fā)、調(diào)試測試、上線維護的全流程階段，因此我們需要對于系統(tǒng)進行全流程效能提升，才能最終保證業(yè)務(wù)的全面效率提升：

快速接入:權(quán)限申請到數(shù)據(jù)接入的全面簡化。簡化的建設(shè)主要是兩方面思路：其一是流程上的簡化（例如: 權(quán)限申請流程無需架構(gòu)同學(xué)參與，組內(nèi)同學(xué)就可以審批處理）；其二開發(fā)過程的簡化，對于常見的流式數(shù)據(jù)系統(tǒng)(公司其他中臺或者官方數(shù)據(jù)系統(tǒng)) & 通用存儲(常用的公司數(shù)據(jù)存儲 eg Mysql、Mongo、公司內(nèi)部的表格存儲甚至原生FTP本地文件) 支持配置化的批量導(dǎo)入。同時我們也提自定義(完美適配Docker)的任務(wù)系統(tǒng)提供做夠的靈活性保證業(yè)務(wù)的低成本接入；
極速開發(fā):平臺完善函數(shù)內(nèi)容。我們這邊開發(fā)有兩種模式，一種適合初學(xué)者的Air模式，一種是適合高端玩家的Pro模式；針對于Air模式本身，用戶可以直接在平臺完成代碼的提交和調(diào)試功能，完全一鍵處理；
快速調(diào)試&測試:業(yè)務(wù)可以根據(jù)自己實際的需要可以通過平臺化的方式調(diào)試通用的模板函數(shù)，也可以通過線下集成調(diào)試環(huán)境一體化的對整個系統(tǒng)進行調(diào)試。針對于測試提供了平臺化的測試方案，業(yè)務(wù)可以默認(rèn)0配置的情況下進行服務(wù)性能和執(zhí)行數(shù)據(jù)結(jié)果的DIFF；
問題定位: 這部分對于業(yè)務(wù)問題解決尤為重要。主要包括監(jiān)控報警和云日志兩部分功能(具體架構(gòu)設(shè)計在2.1可觀測性建設(shè)?中有詳細(xì)的描述)：

監(jiān)控報警：包含兩部分信息通用部分和業(yè)務(wù)自定義兩部分。其中通用部分提供包括算子總體堆積程度，每個算子的處理的信息，app 實例狀態(tài) 等等20多項常用數(shù)據(jù)指標(biāo)，直接集成到管理平臺內(nèi)部，可以不需配置直接使用。而自定義部分提供了基礎(chǔ)的SDK函數(shù)裝飾器，可以極低成本給監(jiān)控自定義代碼段的成功率，延時等信息；
云日志：包含數(shù)據(jù)Trace(數(shù)據(jù)流向)、日志Trace以及相關(guān)的數(shù)據(jù)報表服務(wù),業(yè)務(wù)都可以極低成本進行服務(wù)接入。

通過的FaaS化建設(shè)，業(yè)務(wù)接入、開發(fā)、迭代、維護等全流程階段的效率都有了巨大的提升, 達到了10倍人效提升。

四、智能化:追求更低成本、更高質(zhì)量的服務(wù)

通過上一部分提到的FaaS化改造，業(yè)務(wù)的全流程服務(wù)效率問題得到巨大的改善。接下來通過智能化改造的工作在避免大量資源浪費、降低資源成本的同時，提高業(yè)務(wù)的服務(wù)質(zhì)量。智能化的工作主要包括兩部分：

通過智能化的資源調(diào)度方案，極大的節(jié)約用戶的資源成本，真正做到按需使用，而且可以有效處理流量洪峰，提高系統(tǒng)穩(wěn)定性。
通過智能化的控制架構(gòu)，有效處理異常問題，做到問題主動感知、決策并且主動處理，提升系統(tǒng)韌性的同時降低大量的維護人力成本。

下面針對于這兩部分系統(tǒng)設(shè)計進行詳細(xì)闡述。

4.1 智能調(diào)度: 極致化彈性伸縮

過去，業(yè)務(wù)的app主要配置固定容量配置，我們多數(shù)的業(yè)務(wù)流量都有明顯的潮汐式，大量業(yè)務(wù)天級別只有1個小時，甚至幾分鐘的流量，這樣就造成了大量資源浪費。

智能調(diào)度的核心作用就是實現(xiàn)業(yè)務(wù)的資源的按需分配, 實現(xiàn)從0→n的資源滿足，具體上來講主要有如下功能：

自動伸縮：根據(jù)當(dāng)前服務(wù)流量的波動情況自動分配出來對應(yīng)可以滿足整體實例消費情況的實例數(shù)進行消費,包含縱向本地擴容+容器橫向伸縮的方式相結(jié)合多階段擴容；
服務(wù)資源回收&冷啟動：保證長時間沒流量的服務(wù)容器，資源完全被回收，不占用任何服務(wù)資源，當(dāng)新流量資源到來的時候，服務(wù)接著過去資源的數(shù)據(jù)消費，保證數(shù)據(jù)生效穩(wěn)定性的同時，使得業(yè)務(wù)完全做到按需使用；
異常實例遷移：主要通過熱點實例遷移，長尾實例遷移保證服務(wù)全局的正常運行；
容器資源自適應(yīng)：主要通過檢測內(nèi)存使用狀態(tài)，對資源容器進行自適應(yīng)的調(diào)整，保證容器資源在不浪費的同時，保證服務(wù)不會超限而造成服務(wù)的OOM。

其中自動伸縮是一個這個場景下最典型的調(diào)度場景，下面以自動伸縮為出發(fā)點從設(shè)計思路&核心架構(gòu)兩個方面來具體闡述。

設(shè)計思路：多階段擴容的設(shè)計原因

擴縮容最初只有傳統(tǒng)意義上的橫向擴縮容，在我們的業(yè)務(wù)場景下可以達到分鐘級的是時效性，多數(shù)業(yè)務(wù)可以滿足需求。然而，針對于高時效業(yè)務(wù)，當(dāng)流量高峰突然到來的時候(例如3倍過去高峰流量)，分鐘級的擴容速度業(yè)務(wù)無法接受。為了解決這個問題一般只能給一定業(yè)務(wù)流量BUFFER(比如2倍流量)。如果資源BUFFER充足，業(yè)務(wù)方則有大規(guī)模的的資源浪費，如果資源BUFFER不足時效性依然沒有完全解決。

其實業(yè)務(wù)的核心訴求是架構(gòu)能否做到相對穩(wěn)定的秒級伸縮?？梢钥焖倬徑鈽I(yè)務(wù)流量洪峰的壓力，提高系統(tǒng)穩(wěn)定性擴展性的同時達到最佳的資源利用。通過分析橫向擴縮容底層現(xiàn)狀我們發(fā)現(xiàn):

啟動時間分析:?容器的調(diào)度時間+rumtime初始化時間占據(jù)了整個啟動時間的98%以上，一般需要5分鐘，依賴于公司基礎(chǔ)PaaS環(huán)境，優(yōu)化成本非常高；
開發(fā)業(yè)務(wù)：業(yè)務(wù)都是通過腳本語言開發(fā)（通常是Python），受到解釋器限制極限只能用滿CPU單核, 有時甚至由于業(yè)務(wù)代碼邏輯問題遠(yuǎn)遠(yuǎn)無法達到；
資源占用：容器規(guī)格很小(CPU規(guī)格極小、容器內(nèi)存資源充足)，多數(shù)機器上的剩余quota足夠。

因此我們就想到使用，增加縱向本地擴容階段：1. 通過Quota Resize 解決容器資源擴容問題；2.通過框架的多進程并發(fā)解決大容器下的業(yè)務(wù)能力上限問題。

結(jié)合3.1核心框架中提到的多進程框架的實現(xiàn)，實際擴容包含兩個階段：

縱向本地擴容階段：可以滿足在高時效業(yè)務(wù)場景下突發(fā)流量到來的極速資源滿足速度，通常可以瞬間滿足5~10倍的資源。此外，擴容過程中是允許少數(shù)實例縱向擴容失敗的，通過流量均勻分發(fā)的能力，將縱向失敗的流量實例流量均攤到成功的實例上。
容器橫向伸縮階段：兩種情況會進行橫向擴容階段：

其一，當(dāng)高峰流量持續(xù)時間較長(一般超過10分鐘)時，會進行橫向擴容實讓服務(wù)容器分裂(例如：2個實例10進程 → 20個實例1進程)；
其二，縱向擴容后仍然不能完全滿足吞吐要求(例如100倍的服務(wù)吞吐需求)，則會在縱向擴容后瞬間觸發(fā)橫向擴容，不過此時業(yè)務(wù)完全滿足效率退化成分鐘級。

以上描述的是擴容過程，縮容過程類似，優(yōu)先進行本地縮容。這樣保證容器的均勻分布，隨時都能有本地擴容的能力。

核心實現(xiàn): 調(diào)度核心架構(gòu)

如下圖是我們智能調(diào)度簡化架構(gòu)圖:

主要分成下面幾個階段:

采集層: 采集數(shù)據(jù)的基礎(chǔ)信息，這里主要需要集中類型的信息，尤其是擴縮容其實主要關(guān)注兩個隊列信息:

數(shù)據(jù)流的隊列信息
流式算子之間的隊列信息

決策層: 根據(jù)歷史調(diào)度信息和當(dāng)前的實際狀態(tài)信息進行決策，實現(xiàn)多階段可變步長的擴容:

優(yōu)先進行本地擴容，根據(jù)當(dāng)前容器的資源使用量最多需要平均可以擴容5→20倍
長時間當(dāng)本地擴容到(或者接近)極限，則會進行橫向擴容，這個資源水平?jīng)]有特殊限制
多階段: 本地擴容(縱向) + 橫向擴容
可變步長: 數(shù)據(jù)堆積都有多個閾值，每個閾值關(guān)系到不同的步長(默認(rèn)每個APP至少兩個步長)。eg: 政務(wù)業(yè)務(wù)的數(shù)據(jù)流堆積1000持續(xù)超過30s則觸發(fā)擴容1倍，如果超過10000，則直接擴容到最大實例數(shù)

分析層: 在整體資源低于閾值(默認(rèn)85%)的時候默認(rèn)是跳過該階段；在整體資源超過閾值后，為了保證高優(yōu)先級的資源進行優(yōu)先級調(diào)度使用的，必要的時候會對低優(yōu)任務(wù)進行淘汰
執(zhí)行層: 根據(jù)決策分析層提供的信息執(zhí)行

本地擴容: 直接調(diào)整容器Quota信息的同時基礎(chǔ)框架的進程管理啟動服務(wù)的進程數(shù)來實現(xiàn)本地的極速擴容(比橫向擴容快一個數(shù)量級)
橫向擴容: 普通橫向調(diào)整實例個數(shù)，由于涉及到資源調(diào)度，數(shù)據(jù)環(huán)境的初始化，需要的時間周期是分鐘級
過濾: 擴容生效都有一個時間周期(本地擴容秒級，橫向擴容分鐘級)，每個決策后都有一個靜默期(比如10分鐘)從而避免重復(fù)決策執(zhí)行
跳檔: 過濾只針對于完全相同的操作攔截，針對于不同步長擴容不攔截，保證業(yè)務(wù)在流量洪峰下的感知執(zhí)行速度
執(zhí)行: 真正執(zhí)行操作，例如擴縮容操作

關(guān)于本地計算擴容: 進程管理的時候每啟動一個子進程，實際內(nèi)存增加約60M，CPU極限增加1核心(10個實例資源只是600M內(nèi)存，10個邏輯核心)，超過實例 90%?情況都可以實現(xiàn)本地極速擴容。

按需計費的實現(xiàn)考慮到不同業(yè)務(wù)有不同的調(diào)度邏輯和配置場景: 有的業(yè)務(wù)需要資源預(yù)留（保證最低實例數(shù)), 則這部分業(yè)務(wù)有最低資源占有成本；而多數(shù)業(yè)務(wù)沒有特定的需求，一般冷啟動延遲業(yè)務(wù)可以接受，則不需要保證最低實例數(shù);有的業(yè)務(wù)需要時效性要求比較高，擴容敏感度高，縮容敏感度低，而對于普通擴容敏感度，甚至敏感度更低的業(yè)務(wù)，相同狀況下擴容的資源數(shù)可能完善不一致;有的業(yè)務(wù)不需要容器自動適配，而多數(shù)業(yè)務(wù)需要在容器尤其是內(nèi)存設(shè)置不合理的時候主動獲取更大的容器。業(yè)務(wù)實際上的收費就是按照業(yè)務(wù)不同的調(diào)度策略進行計費，真正做到不多不漏，合理計費。

通過智能調(diào)度服務(wù)實現(xiàn)了核心生產(chǎn)環(huán)境多數(shù)場景支持秒級自動伸縮，支持0→n的極致擴容。按需計費，整體資源節(jié)約87%。

4.2 智能控制: 防止問題升級擴散，全自動實時處理

智能化調(diào)度實現(xiàn)了極致化的彈性伸縮，做到了資源的極大節(jié)省。我們的整個系統(tǒng)也隨著系統(tǒng)云原生化的改造下變得越來越復(fù)雜，但是問題的排查成本卻越來越高。因此問題的排查通常需要多個方向的同學(xué)通力合作(或者依賴個別專家同學(xué)的定位)才能處理解決。這不僅僅是對架構(gòu)人力的巨大浪費，而且干預(yù)時間常常不可控，對于線上有很大風(fēng)險。為了解決這個問題，搜索中臺內(nèi)容生效架構(gòu)引入了智能控制系統(tǒng), 快速、準(zhǔn)確的發(fā)現(xiàn)問題、處理問題并且整個過程是完全自動化的：

快速: 處理速度快，主動發(fā)現(xiàn) 與消息通知相結(jié)合的方式，全面進行問題排查
準(zhǔn)確: 歷史出現(xiàn)過的問題轉(zhuǎn)化成系統(tǒng)規(guī)則，整個過程模擬專家進行處理解決。只要規(guī)則合理，沒有誤操作，沒有非預(yù)期行為
自動: 處理過程完全無需人工干預(yù)，全程自動化處理

智能控制系統(tǒng)總體上是以可觀測為基石，以健全的自愈能力為手段，通過智能分析引擎進行實時動態(tài)分析決策，決策的結(jié)果會影響到觀測數(shù)據(jù)做下一輪的數(shù)據(jù)分析。它們的相互關(guān)系如下。

通過整體系統(tǒng)的執(zhí)行自愈的連續(xù)迭代調(diào)整，最終讓系統(tǒng)調(diào)整到一個健康的狀態(tài)。

完善可觀測系統(tǒng)(基礎(chǔ))

可觀測系統(tǒng)并非此次敘述的核心，但是它仍然是智能控制的基礎(chǔ)。沒有完備的可觀測系統(tǒng)建設(shè)，一切有效的控制系統(tǒng)都是空談，如下圖就是整體可觀測系統(tǒng)的概覽:

基礎(chǔ)采集層: 為所有的觀測系統(tǒng)的數(shù)據(jù)提供最原始的基礎(chǔ)數(shù)據(jù)采集。從數(shù)據(jù)類型來分主要是三類:

流式數(shù)據(jù): 需要記錄每條數(shù)據(jù)的信息，主要借助于Kafka的數(shù)據(jù)隊列收集
指標(biāo)數(shù)據(jù): 對外匯報每個實例的指標(biāo)數(shù)據(jù)，對外exporter匯報數(shù)，或者直接原始公司公司內(nèi)的監(jiān)控系統(tǒng)進行采集
自定義數(shù)據(jù): 這種一般使用腳本以特定化的方式采集，作為基礎(chǔ)指標(biāo)采集的補充

數(shù)據(jù)處理層: 該層主要是針對于流式原始數(shù)據(jù)的數(shù)據(jù)處理，從圖中可以看到主要是兩部分?jǐn)?shù)據(jù)，很多基礎(chǔ)數(shù)據(jù)信息不需要額外聚合

指標(biāo)聚合層: 主要是提供于拓?fù)浞治鱿到y(tǒng)，這里基于StatsD和Prometheus的轉(zhuǎn)換接口，實現(xiàn)的指標(biāo)動態(tài)分桶機制,極少資源完成大量數(shù)據(jù)信息
數(shù)據(jù)聚合層: 主要提供于實時成功率監(jiān)控系統(tǒng)，這里是基于數(shù)據(jù)的動態(tài)Hash和流式計算完成的

存儲層: 該層是可觀測系統(tǒng)的中間核心，這里我們用到的數(shù)據(jù)存儲既有開源的系統(tǒng)(包括ES/Prometheus/Mongo等)，也有公司內(nèi)的監(jiān)控系統(tǒng)(以復(fù)用為主)。有兩個大系統(tǒng)提供原始數(shù)據(jù):

一方面，給上層應(yīng)用系統(tǒng)提供數(shù)據(jù)展示的原始數(shù)據(jù)；
另一方面，給智能控制提供決策的原始數(shù)據(jù)。

展現(xiàn)層: 用戶直接訪問的前端接口，這里有我們自定義的平臺，也有直接借助開源系統(tǒng)Grafana和Skywalking之上進行建設(shè)
應(yīng)用層: 用戶或者是架構(gòu)所需的對外查看的系統(tǒng)，有6大業(yè)務(wù)系統(tǒng)，包括:

Trace系統(tǒng): 包括數(shù)據(jù)Trace 和日志Trace，確認(rèn)任意單條數(shù)據(jù)信息
指標(biāo)系統(tǒng): 最關(guān)鍵的基礎(chǔ)數(shù)據(jù)信息，所有架構(gòu)層和業(yè)務(wù)層的核心指標(biāo)都收錄于此
健康刻畫系統(tǒng): 通過當(dāng)前全局的報警信息（報警級別、時間、個數(shù)）刻畫出整體當(dāng)前系統(tǒng)的健康程度
拓?fù)浞治鱿到y(tǒng): 分析業(yè)務(wù)側(cè)面和架構(gòu)側(cè)數(shù)據(jù)流是否存在異常（數(shù)據(jù)流量變化，異常點分析）
效果監(jiān)控系統(tǒng): 從數(shù)據(jù)生效結(jié)果監(jiān)控，從架構(gòu)效果端反推業(yè)務(wù)問題，比如監(jiān)控關(guān)鍵數(shù)據(jù)變更的時間戳反推架構(gòu)系統(tǒng)問題
實時成功率監(jiān)控: 查看數(shù)據(jù)流整體端到端的實時成功率信息

通過一整套監(jiān)控系統(tǒng)建讓架構(gòu)掌握大量實時多維度的數(shù)據(jù)指標(biāo)。所有的系統(tǒng)的問題都會反應(yīng)到一個（或者幾個）指標(biāo)數(shù)據(jù)的變化中去。一方面，可以作為后續(xù)自動控制的數(shù)據(jù)原材料；另一方面，架構(gòu)通過將這些指標(biāo)的分級(高中低)分通路(電話、短信、通信軟件消息)的方式保證系統(tǒng)的人工兜底。

健全的自愈能力建設(shè)(手段)

完善可觀測性提供決策的數(shù)據(jù)源，它是智能控制的基礎(chǔ)。而自愈能力的建設(shè)是自動化的控制的重要手段，否則依賴純?nèi)斯じ深A(yù)（例如”手動刪除一個實例” 或者 “線上修改一個配置”）的操作是沒辦法實現(xiàn)自動化和快速止損的。自愈能力建設(shè)這里重點描述所覆蓋的功能集合，不僅僅包含我們傳統(tǒng)意義上的容器管理功能(例如：實例重啟、遷移等)，還有深入到業(yè)務(wù)系統(tǒng)架構(gòu)中的服務(wù)管理類和通路控制類的功能：

服務(wù)管理類: 主要是基于資源&服務(wù)的管理，包括通路切換（主備切換，優(yōu)先級切換）、數(shù)據(jù)攔截、數(shù)據(jù)回灌和服務(wù)降級等
通路管理類: 主要是基于提供基礎(chǔ)組件的管理功能，包括流量清理、查詢攔截(異常查詢&慢查詢查殺)

自動化問題分析引擎(核心): 規(guī)則+Function

自動化問題分析引擎是整個智能控制系統(tǒng)的大腦。它上游接收觀測提供的原始數(shù)據(jù)，進行自動的分析決策后，通過系統(tǒng)提供的自愈能力處理。自動化問題分析引擎的核心思路: 只要歷史上出現(xiàn)過的問題，RD同學(xué)能找到問題和解決方案，就可以轉(zhuǎn)化為系統(tǒng)規(guī)則和后置函數(shù)梳理。那當(dāng)下一次遇到問題則無需人工干預(yù)。規(guī)則引擎的核心分析過程是2段式的:

階段1: 傳統(tǒng)配置化的規(guī)則引擎的配置（上圖中右上角黃色部分），配置多個采集指標(biāo)項的邏輯關(guān)系（與或交非），這里主要是針對問題的基礎(chǔ)分析功能,判定規(guī)則是否觸發(fā)。
階段2: 基于這個基礎(chǔ)分析的結(jié)果，進行后置Function的執(zhí)行分析，這個主要是針對復(fù)雜問題的分析補充，最終執(zhí)行引擎根據(jù)這個返回結(jié)果進行函數(shù)執(zhí)行。

下面針對問題分析引擎的執(zhí)行結(jié)果如下:

前提: 開發(fā)者需要配置好處理邏輯規(guī)則（以及規(guī)則依賴的數(shù)據(jù)項，必填） &?回調(diào)函數(shù)（選填）。
數(shù)據(jù)解析器: 數(shù)據(jù)解析器主要承擔(dān)的數(shù)據(jù)的原始抽取的工作，一共分成如下3步；

配置解析: 邏輯執(zhí)行根據(jù)開發(fā)者配置的數(shù)據(jù)信息解析；
數(shù)據(jù)抽取: 根據(jù)解析出來的配置通過數(shù)據(jù)接口進行獲取，可以從統(tǒng)一接口根據(jù)配置的信息從不同的介質(zhì)充抽取所需求的信息；
數(shù)據(jù)歸一化: 將不同介質(zhì)的原始數(shù)據(jù)歸一化成為統(tǒng)一的數(shù)據(jù)格式供規(guī)則管理器使用。

規(guī)則管理器: 規(guī)則管理器主要承擔(dān)核心的邏輯分析工作，一共分成如下幾步:

規(guī)則解析: 根據(jù)開發(fā)者配置的規(guī)則邏輯，將原始配置信息，解釋成原始的規(guī)則樹；
執(zhí)行計算: 根據(jù)數(shù)據(jù)解析器提供的數(shù)據(jù)結(jié)果和配置的函數(shù)規(guī)則分別執(zhí)行計算。執(zhí)行計算過程中最重要的就是基礎(chǔ)分析器，整體提供了5大基礎(chǔ)能力，數(shù)十種常見的邏輯計算來輔助規(guī)則配置。
規(guī)則邏輯運算: 根據(jù)上層解析出來的規(guī)則樹和每個數(shù)據(jù)項執(zhí)行完成的計算結(jié)果進行邏輯運算，并根據(jù)執(zhí)行的結(jié)果確定是否進行高級數(shù)據(jù)分析器，如果判斷結(jié)果為真則根據(jù)所配置的后置函數(shù)進行處理；

高級數(shù)據(jù)分析器: 如圖所示有兩種模式，對于簡單基礎(chǔ)分析可以判斷結(jié)果的，直接給默認(rèn)的處理函數(shù)進行數(shù)據(jù)拓傳；對于簡單邏輯規(guī)則無法準(zhǔn)確表達的，開發(fā)者可以自定義后置分析函數(shù)，函數(shù)會將原始數(shù)據(jù)和基礎(chǔ)計算的計算結(jié)果作為參數(shù)傳出來，開發(fā)者只需要通過處理后的數(shù)據(jù)描述清楚分析邏輯即可；
動作執(zhí)行器: 就是這個分析器的真正的執(zhí)行引擎，根據(jù)規(guī)則運算的結(jié)果中包含的參數(shù)進行動態(tài)調(diào)整。

通過智能控制系統(tǒng)的建設(shè)，月級別分析處理上萬的異常問題，自動恢復(fù)的比例占總數(shù)的96.72%，所有問題的恢復(fù)時間平均在1.5分鐘， 90分位小于3分鐘，核心故障同比減少60%?（由于預(yù)處理防止普通問題惡化成嚴(yán)重問題）。

五、總結(jié)

整體的工作思路以Serverless為指導(dǎo)思想，通過FaaS化和智能化兩個維度的系統(tǒng)化建設(shè)，以技術(shù)手段系統(tǒng)性實現(xiàn)了降本、增效、提質(zhì)：

通過FaaS化的建設(shè)，提升基礎(chǔ)服務(wù)性能的同時全流程服務(wù)效率的提高，具體來說包括兩部分：

打造新一代的核心框架，提供強大的基礎(chǔ)底座讓業(yè)務(wù)核心關(guān)注點從原來的云化服務(wù)思維聚焦到邏輯實現(xiàn)，業(yè)務(wù)通過簡單復(fù)用和編排實現(xiàn)復(fù)雜的功能，讓業(yè)務(wù)開發(fā)更簡單
提供一體化全流程系統(tǒng)建設(shè)，讓業(yè)務(wù)從接入、開發(fā)、調(diào)試測試到最終系統(tǒng)維護全流程的流暢體驗，助力業(yè)務(wù)更高效的交付

通過智能化建設(shè)，在穩(wěn)定性有巨大提升的同時大幅度降低資源成本和系統(tǒng)的維護成本，具體來說也包含兩部分：

通過智能化調(diào)度, 實現(xiàn)業(yè)務(wù)的按需分配(0→n), 秒級應(yīng)對突發(fā)流量, 節(jié)約大量的資源成本；
通過智能化控制，實現(xiàn)全系統(tǒng)絕大多數(shù)問題問題的自動感知、自動分析、自動處理，提升穩(wěn)定性的同時降低了系統(tǒng)的維護成本。

在Serverless上線之后，同時FaaS化和智能化的建設(shè)，業(yè)務(wù)真切感受到降本增效的同時穩(wěn)定性和架構(gòu)維護成本也顯著降低，讓架構(gòu)和業(yè)務(wù)同學(xué)都切實感受到了新研發(fā)范式下的技術(shù)紅利。Serverless 帶給我們的是一種新的研發(fā)范式，實現(xiàn)了業(yè)務(wù)創(chuàng)新能力的巨大提升，期待在越來越多的場景中，涌現(xiàn)更多的最佳實踐。

— 本文結(jié)束 —