[[413767]]

一 背景

2018年7月9日，我通過(guò)校招加入阿里云，開(kāi)啟了職業(yè)生涯。有幸參與了資源編排服務(wù)從1.0到2.0的全部設(shè)計(jì)、開(kāi)發(fā)、測(cè)試工作，這對(duì)我了解云上服務(wù)起到了啟蒙作用。當(dāng)然，本文源于我在設(shè)計(jì)開(kāi)發(fā)過(guò)程中的思考和感悟。

在傳統(tǒng)軟件架構(gòu)下，撇開(kāi)業(yè)務(wù)層代碼，都需要部署計(jì)算節(jié)點(diǎn)、存儲(chǔ)資源、網(wǎng)絡(luò)資源，然后安裝、配置操作系統(tǒng)等。而云服務(wù)本質(zhì)上是實(shí)現(xiàn) IT 架構(gòu)軟件化和 IT 平臺(tái)智能化，通過(guò)軟件的形式定義這些硬件資源，充分抽象并封裝其操作接口，任何資源均可直接調(diào)用相關(guān) API 完成創(chuàng)建、刪除、修改、查詢(xún)等操作。

有賴(lài)于阿里云對(duì)資源的充分抽象以及高度統(tǒng)一的OpenAPI，這讓基于阿里云構(gòu)建一套完整的 IT 架構(gòu)并對(duì)各資源進(jìn)行生命周期管理成為可能。客戶(hù)按需求提供資源模板，編排服務(wù)將會(huì)根據(jù)編排邏輯自動(dòng)完成所有資源的創(chuàng)建和配置。

二 架構(gòu)設(shè)計(jì)

伴隨著業(yè)務(wù)場(chǎng)景的增加和業(yè)務(wù)規(guī)模的指數(shù)級(jí)增長(zhǎng)，原有架構(gòu)逐漸暴露出租戶(hù)隔離粒度大、并發(fā)量小、服務(wù)依賴(lài)嚴(yán)重等問(wèn)題，對(duì)于服務(wù)架構(gòu)的重構(gòu)迫在眉睫，其中最重要三個(gè)方面就是拓?fù)湓O(shè)計(jì)、并發(fā)模型設(shè)計(jì)和工作流設(shè)計(jì)。

1 拓?fù)湓O(shè)計(jì)

拓?fù)湓O(shè)計(jì)的核心問(wèn)題是明確產(chǎn)品形態(tài)和用戶(hù)需求、解決數(shù)據(jù)通路問(wèn)題。站在產(chǎn)品角度考慮的點(diǎn)包括: 1. 資源所有者(服務(wù)資源[計(jì)費(fèi)單元]、用戶(hù)資源)、2. 資源訪問(wèn)權(quán)限(隔離、授權(quán))。站在用戶(hù)角度需要考慮的點(diǎn)包括: 1. 服務(wù)類(lèi)型(WebService型-需公網(wǎng)訪問(wèn)、數(shù)據(jù)計(jì)算型-阿里云內(nèi)網(wǎng)訪問(wèn))、2. 數(shù)據(jù)打通(源數(shù)據(jù)、目的數(shù)據(jù))。

資源所有者分為服務(wù)賬號(hào)和用戶(hù)賬號(hào)。資源屬于服務(wù)賬號(hào)的模式又叫做大賬號(hào)模式，該模式優(yōu)點(diǎn)有: 1. 管控能力更強(qiáng);2.計(jì)費(fèi)更容易。但易成為瓶頸的點(diǎn)包括：1.資源配額;2. 依賴(lài)服務(wù)的接口流控。很顯然，全量資源托管是不現(xiàn)實(shí)的，比如VPC、VSwitch、SLB、SecurityGroup等資源客戶(hù)往往需要和其他系統(tǒng)打通，這部分資源通常是用戶(hù)提供的，而ECS實(shí)例則比較適合通過(guò)大賬號(hào)創(chuàng)建。

多租戶(hù)隔離在大賬號(hào)模式下是非常重要的問(wèn)題。既要保證某一用戶(hù)的資源彼此可以相互訪問(wèn)，又要保證多個(gè)客戶(hù)之間不能有越界行為。一個(gè)常見(jiàn)的例子是，所有用戶(hù)的ECS均開(kāi)在同一個(gè)服務(wù)VPC內(nèi)，同一個(gè)VPC內(nèi)實(shí)例默認(rèn)是可以相互訪問(wèn)的，存在安全風(fēng)險(xiǎn)，因此在系統(tǒng)設(shè)計(jì)初期就需要考慮到相關(guān)問(wèn)題的應(yīng)對(duì)方案。

對(duì)于上述問(wèn)題我們的設(shè)計(jì)是，ECS實(shí)例通過(guò)大賬號(hào)模式創(chuàng)建在服務(wù)賬號(hào)下的資源VPC內(nèi)， 通過(guò)企業(yè)級(jí)安全組實(shí)現(xiàn)不同用戶(hù)實(shí)例的訪問(wèn)隔離。涉及用戶(hù)數(shù)據(jù)(NAS、RDS等)訪問(wèn)的操作時(shí)，需要用戶(hù)提供這些訪問(wèn)點(diǎn)所在的VPC和Vswitch，通過(guò)在實(shí)例上創(chuàng)建ENI并綁定到用戶(hù)VPC上，實(shí)現(xiàn)對(duì)用戶(hù)數(shù)據(jù)的訪問(wèn)。具體數(shù)據(jù)通路如圖所示。

常見(jiàn)的服務(wù)架構(gòu)

2 并發(fā)模型設(shè)計(jì)

模型設(shè)計(jì)的核心是解決高并發(fā)(High Concurrency)、高性能(High Performance)、高可用(High Availability)問(wèn)題。

資源編排的高并發(fā)主要指標(biāo)為QPS(Queries-per-second)，對(duì)于動(dòng)輒以分鐘為單位的資源編排邏輯而言，同步模型顯然不能支撐較高并發(fā)請(qǐng)求。資源編排的高性能主要指標(biāo)為T(mén)PS(Transactions-per-second)，在根據(jù)用戶(hù)資源模板編排資源的過(guò)程中，資源彼此間存在一定的依賴(lài)關(guān)系，線性地創(chuàng)建資源會(huì)導(dǎo)致大量時(shí)間處于忙等狀態(tài)，服務(wù)吞吐嚴(yán)重受限。資源編排的高可用主要指標(biāo)為SLA(Service Level Agreement)，在HA基礎(chǔ)上若能解耦CRUD對(duì)內(nèi)部服務(wù)的依賴(lài)，在服務(wù)升級(jí)或發(fā)生異常時(shí)就可以減小對(duì)SLA的影響。

對(duì)于上述問(wèn)題我們的設(shè)計(jì)是，在服務(wù)前端僅進(jìn)行簡(jiǎn)單的參數(shù)檢查后立即將用戶(hù)模板寫(xiě)入持久化層，寫(xiě)入成功后立即返回資源ID，已持久化的資源模板將被視為未處理完成的任務(wù)等待調(diào)度處理。隨后，我們周期性掃表探測(cè)任務(wù)，有序創(chuàng)建資源并同步其狀態(tài)，如遇資源狀態(tài)不滿(mǎn)足向下推進(jìn)的條件則立即返回，經(jīng)過(guò)多輪次處理，最終達(dá)到期望的狀態(tài)， 一個(gè)簡(jiǎn)化的分布式模型如圖所示。

分布式并發(fā)模型

為了避免任務(wù)較多情況下的鎖爭(zhēng)搶問(wèn)題，我們?cè)O(shè)計(jì)一套任務(wù)發(fā)現(xiàn) + 租約續(xù)租的機(jī)制，一旦集群從數(shù)據(jù)庫(kù)池子中被某個(gè)節(jié)點(diǎn)爭(zhēng)搶到之后會(huì)被添加到該節(jié)點(diǎn)的調(diào)度池中并設(shè)定租約， 租約管理系統(tǒng)會(huì)對(duì)即將到期的租約進(jìn)行續(xù)租(加鎖)。這樣可以確保一個(gè)集群在下一次服務(wù)被拉起前一直只被某個(gè)節(jié)點(diǎn)處理，如果服務(wù)重啟，則任務(wù)會(huì)因超時(shí)自動(dòng)解鎖并被其他節(jié)點(diǎn)捕獲。

3 工作流設(shè)計(jì)

流程設(shè)計(jì)的核心是解決依賴(lài)問(wèn)題。依賴(lài)問(wèn)題包含兩種情況：前序資源的狀態(tài)不符合預(yù)期和資源本身狀態(tài)不符合預(yù)期。我們假設(shè)各資源的狀態(tài)只有可用和不可用，并且假定可用的資源不會(huì)跳轉(zhuǎn)到不可用狀態(tài)，最簡(jiǎn)單的情況就是一個(gè)線性任務(wù)，如圖所示。考慮到部分子資源的編排工作可以并行，編排過(guò)程就可以看作是一個(gè)有向無(wú)環(huán)圖( DAG, Direct Acyclic Graph)任務(wù)。

資源線性編排結(jié)構(gòu)

世界不只是非黑即白，資源的狀態(tài)也是一樣，有向無(wú)環(huán)成為了美好的愿望，有向有環(huán)才符合真實(shí)世界的運(yùn)行規(guī)律。對(duì)于這種情況，簡(jiǎn)單的工作流很難覆蓋復(fù)雜的流程，只有進(jìn)一步對(duì)工作流抽象，設(shè)計(jì)符合要求的有限狀態(tài)機(jī)(FSM, Finite State Machine)。有限狀態(tài)機(jī)說(shuō)起來(lái)過(guò)于抽象，但ECS實(shí)例的狀態(tài)轉(zhuǎn)移大家都接觸過(guò)，下圖就是ECS實(shí)例的狀態(tài)轉(zhuǎn)移模型。

ECS實(shí)例狀態(tài)轉(zhuǎn)移模型

結(jié)合實(shí)際業(yè)務(wù)需求，我設(shè)計(jì)了如下圖所示的集群狀態(tài)轉(zhuǎn)移模型。該模型簡(jiǎn)化了狀態(tài)轉(zhuǎn)移邏輯，有且僅有Running這一穩(wěn)態(tài)，其他三種狀態(tài)(Rolling、Deleting、Error)均為中間態(tài)。處于中間態(tài)的資源會(huì)根據(jù)當(dāng)前資源狀態(tài)嘗試向著穩(wěn)態(tài)越遷，每次狀態(tài)越遷過(guò)程均按照一定的Workflow執(zhí)行相關(guān)操作。

集群狀態(tài)轉(zhuǎn)移模型

從這時(shí)起，服務(wù)的整體架構(gòu)和設(shè)計(jì)思路基本確立。

三 核心競(jìng)爭(zhēng)力

資源(ECS)短缺問(wèn)題日益嚴(yán)峻，加上粗粒度的擴(kuò)縮容、升降配功能已不能滿(mǎn)足客戶(hù)的需求，資源池化(Resource Pooling)、自動(dòng)伸縮(Auto Scaling)、滾動(dòng)升級(jí)(Rolling Update)被提上日程并成為提升產(chǎn)品競(jìng)爭(zhēng)力的一大利器。

1 資源池化

資源池化簡(jiǎn)單來(lái)說(shuō)就是提前預(yù)留某些資源以備不時(shí)之需，很顯然，資源池化的前提一定是大賬號(hào)模式。對(duì)開(kāi)發(fā)者而言，線程池不是陌生的詞匯，但資源池卻相對(duì)比較遙遠(yuǎn)，實(shí)際上，資源池解決的就是資源創(chuàng)建、刪除時(shí)間開(kāi)銷(xiāo)很大以及庫(kù)存不可控的問(wèn)題。當(dāng)然， 池化資源另一個(gè)假設(shè)是，被池化的資源會(huì)被頻繁使用且可被回收利用(規(guī)格、配置相對(duì)單一)。

由于計(jì)算資源創(chuàng)建周期較長(zhǎng)且經(jīng)常被資源庫(kù)存等問(wèn)題困擾，加之產(chǎn)品期望在業(yè)務(wù)上有所拓展，因此我們?cè)O(shè)計(jì)了如圖所示的資源池化模型并對(duì)多種計(jì)算資源進(jìn)行抽象，提供了一套可以應(yīng)對(duì)異構(gòu)資源的處理邏輯。

資源池化模型

資源池化可以大大縮短資源創(chuàng)建等待時(shí)間，解決庫(kù)存不足問(wèn)題，另外，它可以幫上層使用到資源的服務(wù)解耦復(fù)雜的狀態(tài)轉(zhuǎn)移邏輯，對(duì)外提供的資源狀態(tài)可以精簡(jiǎn)到Available和Unknown兩種，所得即可用。但不得不考慮的問(wèn)題包括：

• ECS實(shí)例的創(chuàng)建是否受用戶(hù)資源的限制(如用戶(hù)提供VSwitch會(huì)限制ECS可用區(qū))。
• 如何解決資源閑置問(wèn)題(成本問(wèn)題)。

對(duì)于第一個(gè)問(wèn)題，目前受制于VSwitch由客戶(hù)提供，暫時(shí)還沒(méi)有比較好的解法，只能盡量要求客戶(hù)提供的VSwitch覆蓋更多的可用區(qū)，如果VSwitch屬于服務(wù)賬號(hào)，就可以比較好規(guī)劃資源池建在哪個(gè)AZ。對(duì)于第二個(gè)問(wèn)題，資源池本身也是一種資源，成本控制我們可以從接下來(lái)提到的自動(dòng)伸縮上得到答案。

2 自動(dòng)伸縮

云計(jì)算最大的吸引力就是降低成本，對(duì)資源而言，最大的好處就是可以按量付費(fèi)。實(shí)際上，幾乎所有線上服務(wù)都有其峰谷，而自動(dòng)伸縮解決的正是成本控制問(wèn)題。它在客戶(hù)業(yè)務(wù)增長(zhǎng)時(shí)增加ECS實(shí)例以保證算力，業(yè)務(wù)下降時(shí)減少ECS實(shí)例以節(jié)約成本，如圖所示。

自動(dòng)伸縮示意圖

我對(duì)自動(dòng)伸縮的設(shè)計(jì)思路是，先對(duì)時(shí)間分片觸發(fā)定時(shí)任務(wù)，再對(duì)時(shí)間段內(nèi)配置伸縮策略。伸縮策略也包含兩部分，一部分是最大ECS規(guī)模和最小ECS規(guī)模，它指定了該時(shí)間段內(nèi)集群規(guī)模的浮動(dòng)范圍，另一部分是監(jiān)控指標(biāo)、耐受度和步進(jìn)規(guī)則，它提供了伸縮依據(jù)和標(biāo)準(zhǔn)。這里監(jiān)控指標(biāo)是比較有意思的點(diǎn)，除了采集云監(jiān)控的CPU、Memory利用率外，還可以通過(guò)對(duì)ECS空閑、忙碌狀態(tài)的標(biāo)記，計(jì)算出工作節(jié)點(diǎn)占比率，一旦超出耐受范圍，即可按步進(jìn)大小觸發(fā)一次擴(kuò)容或縮容事件。

3 滾動(dòng)升級(jí)

客戶(hù)服務(wù)架構(gòu)的修改往往涉及復(fù)雜的重建邏輯，在重建過(guò)程中不可避免的會(huì)影響服務(wù)質(zhì)量，如何優(yōu)雅平滑地做升降配成為了諸多客戶(hù)的剛需。滾動(dòng)升級(jí)正是解決不停服、可調(diào)控的升降配問(wèn)題的。

滾動(dòng)升級(jí)示意圖

一次簡(jiǎn)化的滾動(dòng)升級(jí)過(guò)程如上圖所示。滾動(dòng)升級(jí)的核心是對(duì)升級(jí)進(jìn)行灰度，按照一定比例開(kāi)出Standby資源直到它們可以順利服役，隨后再下線掉相應(yīng)臺(tái)數(shù)的資源。經(jīng)過(guò)多次滾動(dòng)之后，使其全部資源更新到最新預(yù)期，通過(guò)冗余實(shí)現(xiàn)升級(jí)不停服。

四 可觀測(cè)性

服務(wù)可觀測(cè)性將來(lái)必將成為云服務(wù)的核心競(jìng)爭(zhēng)力之一，它包括面向用戶(hù)的可觀測(cè)行和面向開(kāi)發(fā)者的可觀測(cè)性?xún)刹糠?。時(shí)至今日，仍然記得半夜被客戶(hù)電話支配的恐懼，仍記得對(duì)著海量日志調(diào)查問(wèn)題的不知所措，仍記得客戶(hù)一通抱怨后毫無(wú)頭緒的茫然。

1 面向用戶(hù)

是的，我希望用戶(hù)在向我們反饋遇到的問(wèn)題時(shí)，提供的信息是有效的，甚至是能直接指向病灶的。對(duì)用戶(hù)而言，能夠直接通過(guò)API獲取資源編排所處的階段以及各階段對(duì)應(yīng)資源的狀態(tài)信息，確實(shí)能夠極大地提高用戶(hù)體驗(yàn)。針對(duì)這個(gè)問(wèn)題，我分析了系統(tǒng)處理流程， 設(shè)計(jì)了面向“階段 - 事件 - 狀態(tài)”的運(yùn)行狀態(tài)收集器。

具體包括：對(duì)的業(yè)務(wù)流程進(jìn)行拆分得到多個(gè)處理階段，對(duì)每個(gè)階段依賴(lài)的事件(資源及其狀態(tài))進(jìn)行整理，對(duì)每個(gè)事件可能出現(xiàn)的狀態(tài)做結(jié)構(gòu)化定義(尤其是異常狀態(tài))。一個(gè)典型的樣例如代碼樣例所示。

[ 
    { 
        "Condition":"Launched", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-17T18:08:30.559586077+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.574196182+08:00" 
    }, 
    { 
        "Condition":"Authenticated", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-17T18:08:30.941994575+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.592222594+08:00" 
    }, 
    { 
        "Condition":"Timed", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-17T18:08:30.944626198+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.599628262+08:00" 
    }, 
    { 
        "Condition":"Tracked", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-17T18:08:30.947530873+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.608807786+08:00" 
    }, 
    { 
        "Condition":"Allocated", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-17T18:08:30.952310811+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.618390582+08:00" 
    }, 
    { 
        "Condition":"Managed", 
        "Status":"True", 
        "LastTransitionTime":"2021-06-18T10:09:00.611588546+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.627946404+08:00" 
    }, 
    { 
        "Condition":"Scaled", 
        "Status":"False", 
        "LastTransitionTime":"2021-06-18T10:09:00.7172905+08:00", 
        "LastProbeTime":"2021-06-18T14:35:30.74967891+08:00", 
        "Errors":[ 
            { 
                "Action":"ScaleCluster", 
                "Code":"SystemError", 
                "Message":"cls-13LJYthRjnrdOYMBug0I54kpXum : destroy worker failed", 
                "Repeat":534 
            } 
        ] 
    } 
] 

代碼樣例：集群維度狀態(tài)收集

2 面向開(kāi)發(fā)者

對(duì)開(kāi)發(fā)者而言，可觀測(cè)性包含監(jiān)控和日志兩部分，監(jiān)控可以幫助開(kāi)發(fā)者查看系統(tǒng)的運(yùn)行狀態(tài)，而日志可以協(xié)助問(wèn)題的排查和診斷。產(chǎn)品從基礎(chǔ)設(shè)施、容器服務(wù)、服務(wù)本身、客戶(hù)業(yè)務(wù)四個(gè)維度進(jìn)行了監(jiān)控和數(shù)據(jù)聚合，具體用到的組件如圖所示。

各級(jí)別監(jiān)控、告警體系

基礎(chǔ)設(shè)施主要依托云監(jiān)控(Cloud Monitor)追蹤C(jī)PU、Memory等使用率;容器服務(wù)主要依賴(lài)普羅米修斯(Prometheus)監(jiān)控部署服務(wù)的K8S集群情況。對(duì)服務(wù)本身，我們?cè)诟鱾€(gè)運(yùn)行階段都接入了Trace用于故障定位;對(duì)最難處理的客戶(hù)業(yè)務(wù)部分，我們按通過(guò)SLS收集客戶(hù)使用情況，通過(guò)UserId和ProjectId進(jìn)行數(shù)據(jù)聚合，并整理出普羅米修斯的DashBoard，可以快速分析某個(gè)用戶(hù)的使用情況。

除監(jiān)控外，已接入云監(jiān)控告警、普羅米修斯告警和SLS告警，系統(tǒng)、業(yè)務(wù)分別設(shè)置不同告警優(yōu)先級(jí)，并整理了豐富的應(yīng)急響應(yīng)方案。

五 其他

從懵懂到能夠獨(dú)立負(fù)責(zé)資源編排服務(wù)的設(shè)計(jì)、開(kāi)發(fā)工作，阿里云提供了寶貴的學(xué)習(xí)平臺(tái)。如今秋招大幕已經(jīng)拉開(kāi)，歡迎應(yīng)屆同學(xué)加入我們，簡(jiǎn)歷請(qǐng)投遞郵箱: yuanyin.lw@alibaba-inc.com. 此時(shí)此刻，非你莫屬。