來(lái)自：劉超的通俗云計(jì)算

本文由新浪微博架構(gòu)師陳飛撰寫(xiě)，因見(jiàn)解深刻，故在此轉(zhuǎn)載

現(xiàn)在越來(lái)越多的企業(yè)開(kāi)始全面擁抱云計(jì)算，開(kāi)始關(guān)注云原生技術(shù)。從管理物理數(shù)據(jù)中心到使用云主機(jī)，我們不用再關(guān)心基礎(chǔ)運(yùn)維。從云主機(jī)到  Kubernetes容器，我們不用再關(guān)心機(jī)器的管理。云上抽象層級(jí)越高，就越少人需要關(guān)心底層問(wèn)題，企業(yè)就能夠節(jié)省大量的人力成本與資源投入。云原生技術(shù)就是更高一層的抽象， CNCF對(duì)云原生技術(shù)的定義是：

有利利于各組織在公有云、私有云和混合云等新型動(dòng)態(tài)環(huán)境中，構(gòu)建和運(yùn)行可彈性擴(kuò)展應(yīng)用。通過(guò)容器?、 服務(wù)網(wǎng)格、微服務(wù)、不不可變基礎(chǔ)設(shè)施和聲明式API等技術(shù)，構(gòu)建容錯(cuò)性好、易易于管理和便于觀察的松耦合系統(tǒng)。

例如FaaS架構(gòu)，開(kāi)發(fā)者可以完全不用考慮服務(wù)?，構(gòu)建并運(yùn)行應(yīng)用程序和服務(wù)。還有面向開(kāi)源架構(gòu)的的云原生技術(shù)，與提供 MySQL, Redis 云服務(wù)類(lèi)似，提供基于Spring Cloud、Dubbo、HSF 等開(kāi)源微服務(wù)架構(gòu)的應(yīng)用管理服務(wù)，開(kāi)發(fā)者無(wú)需考慮部署、監(jiān)控、運(yùn)維的問(wèn)題。

微博也一直在致力于推動(dòng)基礎(chǔ)設(shè)施云原生化，我們圍繞Kubernetes構(gòu)建面向容器?的云原生基礎(chǔ)設(shè)施，形成了了物理數(shù)據(jù)中心加多個(gè)公有云的混合云 Kubernetes平臺(tái)，提供秒級(jí)伸縮能力。構(gòu)建開(kāi)箱即用的CI/CD體系，依托云原生伸縮能力，保證大量的Job穩(wěn)定運(yùn)行，讓開(kāi)發(fā)人員擺脫代碼發(fā)布泥沼。接下介紹這幾方面的實(shí)踐經(jīng)驗(yàn)。

物理數(shù)據(jù)中心Kubernetes化

面向單機(jī)?的基礎(chǔ)設(shè)施架構(gòu)已經(jīng)無(wú)法發(fā)揮云的最大優(yōu)勢(shì)。把容器按照服務(wù)顆粒度進(jìn)行管理，每個(gè)服務(wù)對(duì)應(yīng)一組虛擬機(jī)，雖然基礎(chǔ)運(yùn)維通過(guò) IaaS 層抽象得到了極大簡(jiǎn)化，但是業(yè)務(wù)的運(yùn)維成本依然很高，業(yè)務(wù)SRE需要維護(hù)復(fù)雜的設(shè)備配置腳本，管理不同服務(wù)設(shè)備配置的差異性，需要7*24小時(shí)對(duì)故障設(shè)備進(jìn)行干預(yù)。而且資源利用率無(wú)法最大化，服務(wù)池是按設(shè)備劃分，一個(gè)新設(shè)備添加到服務(wù)池后只能被這個(gè)服務(wù)使用，它的冗余的計(jì)算能力并不能為其他服務(wù)使用。另外不同業(yè)務(wù)容?運(yùn)行在不同的機(jī)器上，容器網(wǎng)絡(luò)架構(gòu)更關(guān)注性能而非隔離性，通常會(huì)采用Host模式，這也提高了服務(wù)混合部署的運(yùn)維成本。

基礎(chǔ)設(shè)施只有形成集群，才能最大程度發(fā)揮容器的良好隔離、資源分配與編排管理的優(yōu)勢(shì)。目前Kubernetes已經(jīng)容器編排系統(tǒng)的事實(shí)標(biāo)準(zhǔn)，提供面向應(yīng)用的容?集群部署和管理系統(tǒng)，消除物理（虛擬）機(jī)，網(wǎng)絡(luò)和存儲(chǔ)基礎(chǔ)設(shè)施的負(fù)擔(dān)。同時(shí)CNCF推出一致性認(rèn)證，推動(dòng)各公有云廠商提供標(biāo)準(zhǔn)的 Kubernetes服務(wù)，這就確保通過(guò)Kubernetes部署的應(yīng)用在不不同云廠商之間具有可遷移性，避免被廠商鎖定。

之前提到微博的容器會(huì)獨(dú)占物理機(jī)的網(wǎng)絡(luò)協(xié)議棧，雖然能夠做到網(wǎng)絡(luò)效率的最大化，但是會(huì)導(dǎo)致多容器部署時(shí)出現(xiàn)端口沖突，無(wú)法滿(mǎn)足Kubernetes動(dòng)態(tài)編排的需求。為了了解決端口沖突問(wèn)題，我們首先測(cè)試了了vxlan網(wǎng)絡(luò)架構(gòu)，因?yàn)槠鋽?shù)據(jù)平面需要進(jìn)行封裝、解封操作，網(wǎng)絡(luò)性能損耗超過(guò)5%，并不不滿(mǎn)足微博后端服務(wù)對(duì)網(wǎng)絡(luò)性能的要求。最后我們?cè)u(píng)估可行的網(wǎng)絡(luò)方案有兩種 MacVlan和Calico BGP。

其中 MacVlan 成熟穩(wěn)定，通過(guò)機(jī)房上聯(lián)交換機(jī)改為Vlan Trunk模式，在物理機(jī)上創(chuàng)建MacVlan網(wǎng)卡子接口，通過(guò)CNI插件將虛擬網(wǎng)卡插入Pause容?中，實(shí)現(xiàn)容器網(wǎng)絡(luò)與物理網(wǎng)絡(luò)打通。容器的網(wǎng)絡(luò)通信直接通過(guò)MacVlan物理子接口，發(fā)出的報(bào)文在網(wǎng)卡上打VlanTag，數(shù)據(jù)平面基本沒(méi)有性能損耗?？刂破矫嬉蛐枰獙?duì)所有上聯(lián)交換機(jī)進(jìn)行Vlan Trunk改造，工作量量較大，所以這個(gè)方案僅針對(duì)高配物理機(jī)所在網(wǎng)絡(luò)進(jìn)行了改造。

Calico BGP是可以同時(shí)實(shí)現(xiàn)數(shù)據(jù)平面0損耗與控制平面自動(dòng)化的容器網(wǎng)絡(luò)解決方案。與MacVlan實(shí)現(xiàn)的扁平二層網(wǎng)絡(luò)不同，Calico在每個(gè)節(jié)點(diǎn)上部署 BGP Client與Reflector實(shí)現(xiàn)了一個(gè)扁平的三層網(wǎng)絡(luò)，每個(gè)節(jié)點(diǎn)發(fā)布的路由狀態(tài)由 Felix 維護(hù)。不過(guò)由于Felix采用iptables實(shí)現(xiàn)路路由ACLs功能，對(duì)性能存在一定影響。因?yàn)槲锢頂?shù)據(jù)中心不面向外部用戶(hù)開(kāi)放，所以ACLs功能對(duì)微博是可以去除的，我們對(duì) Calico 進(jìn)行了優(yōu)化，去除iptables依賴(lài)。

微博也主動(dòng)回饋Kubernetes社區(qū)，也包括為Kubernetes代碼庫(kù)做貢獻(xiàn)，例例如修復(fù)多租戶(hù)下網(wǎng)絡(luò)隔離TC資源泄露問(wèn)題。

之前的運(yùn)維是面向物理機(jī)的，所以物理機(jī)上存在很多運(yùn)維工具，如日志推送、域名解析、時(shí)鐘同步、定時(shí)任務(wù)等。業(yè)務(wù)通過(guò)Kubernetes編排后，以上的功能都需要進(jìn)行容?化改造。例如在容器中使用systemd會(huì)涉及到提權(quán)問(wèn)題，在實(shí)踐過(guò)程中發(fā)現(xiàn)用systemd如果權(quán)限控制不當(dāng)會(huì)造成容器?被Kill的情況。所以我們單獨(dú)開(kāi)發(fā)了兼容linux crontab語(yǔ)法的定時(shí)任務(wù)工具gorun，把這個(gè)工具集成在了了運(yùn)維容器里面。

因?yàn)闃I(yè)務(wù)容?會(huì)產(chǎn)生大量日志，出于I/O性能考慮，同時(shí)為了方便快速定位，日志會(huì)存儲(chǔ)于本地PVC中，支持配額管理，避免一個(gè)容?把磁盤(pán)寫(xiě)滿(mǎn)。運(yùn)維基礎(chǔ)設(shè)施容?通過(guò)監(jiān)聽(tīng)文件，對(duì)老舊日志進(jìn)行壓縮清理，性能Profile日志會(huì)在本地進(jìn)行統(tǒng)計(jì)計(jì)算后通過(guò)UDP協(xié)議推送到Graphite或Prometheus。對(duì)于關(guān)鍵日志，會(huì)通過(guò)Flume推送到Kafka集群，而且支持失敗重傳，保證日志的一致性。

通過(guò)對(duì)運(yùn)維容?化后，所有業(yè)務(wù)Pod都具備相同的運(yùn)維能力，形成標(biāo)準(zhǔn)化的監(jiān)控報(bào)警、運(yùn)維決策、流量切換、服務(wù)降級(jí)，異常封殺、日志查詢(xún)的服務(wù)保障體系，服務(wù)可運(yùn)維性大幅度提升。

容器編排

Kubernetes的Deployment支持Pod自我修復(fù)，滾動(dòng)升級(jí)和回滾，擴(kuò)容和縮容，這些特性都是云原生基礎(chǔ)設(shè)施必備的。但是Kubernetes設(shè)計(jì)原則中對(duì)集群的管理尤其是服務(wù)升級(jí)過(guò)程中保持“無(wú)損”升級(jí)，對(duì)Deployment進(jìn)行行滾動(dòng)升級(jí)，會(huì)創(chuàng)建新Pod替換老Pod，以保證Deployment中Pod的副本數(shù)量。原有里面的IP地址和滾動(dòng)升級(jí)之前的IP地址是不會(huì)相同的。而如果集群夠大，一次滾動(dòng)發(fā)布就會(huì)導(dǎo)致負(fù)載均衡變更（集群副本數(shù)／滾動(dòng)發(fā)布步長(zhǎng)）次。對(duì)于微博服務(wù)來(lái)說(shuō)，頻繁變更會(huì)導(dǎo)致這個(gè)負(fù)載均衡管轄下的后端實(shí)例的接口不不穩(wěn)定。

微博實(shí)現(xiàn)了常備Pod的In-place Rolling Updates功能，根據(jù)業(yè)務(wù)冗余度及業(yè)務(wù)實(shí)際需要來(lái)調(diào)整上線的步長(zhǎng)，上線過(guò)程中保持容器的IP不變，減少在上線過(guò)程中業(yè)務(wù)的抖動(dòng)。因?yàn)闃I(yè)務(wù)的啟動(dòng)需要一定時(shí)間，不能按照容?啟停來(lái)做步長(zhǎng)控制，我們利用Kubernetes容器生命周期管理的liveness/readiness probe 實(shí)現(xiàn)容器提供服務(wù)的狀態(tài)，避免了上線過(guò)程中容?大面積重啟的問(wèn)題。同時(shí)優(yōu)化了了Kubernetes的postStar的原生實(shí)現(xiàn)，因?yàn)樵锩嬷徽{(diào)用一次，不管成功與否都會(huì)殺掉容?，改成不成功會(huì)按照指定的次數(shù)或時(shí)間進(jìn)行重試。IP的靜態(tài)分配使用Calico CNI實(shí)現(xiàn)：

Kubernetes的編排策略相對(duì)靈活，分為三個(gè)階段，初篩階段用于篩選出符合基本要求的物理機(jī)節(jié)點(diǎn)，優(yōu)選階段用于得到在初篩的節(jié)點(diǎn)里面根據(jù)策略略來(lái)完成選擇最優(yōu)節(jié)點(diǎn)。在優(yōu)選完畢之后，還有一個(gè)綁定過(guò)程，用于把Pod和物理機(jī)進(jìn)行綁定，鎖定機(jī)器上的資源。這三步完成之后，位于節(jié)點(diǎn)上的 kubelet才開(kāi)始創(chuàng)建Pod。在實(shí)際情況中，把物理機(jī)上的容?遷移到 Kubernetes，需要保持容?的部署結(jié)構(gòu)盡量一致，例如一個(gè)服務(wù)池中每臺(tái)物理機(jī)上分配部署了wb_service_a和wb_service_b兩個(gè)容器，可以通過(guò) podAffinity來(lái)完成服務(wù)混部的編排：

一些比較復(fù)雜的，運(yùn)維復(fù)雜的集群，通過(guò)Kubernetes Operator進(jìn)行容器編排。Operator是由CoreOS 開(kāi)發(fā)的，用來(lái)擴(kuò)展Kubernetes API，特定的應(yīng)用程序控制器，它用來(lái)創(chuàng)建、配置和管理復(fù)雜的有狀態(tài)應(yīng)用，如數(shù)據(jù)庫(kù)、緩存和監(jiān)控系統(tǒng)。Operator基于Kubernetes的資源和控制?概念之上構(gòu)建，但同時(shí)又包含了了應(yīng)用程序特定的領(lǐng)域知識(shí)。Operator 可以將運(yùn)維人員對(duì)軟件操作的知識(shí)給代碼化，同時(shí)利用Kubernetes強(qiáng)大的抽象來(lái)管理大規(guī)模的軟件應(yīng)用。例如CacheService的運(yùn)維是比較復(fù)雜的，需要資源編排，數(shù)據(jù)同步，HA結(jié)構(gòu)編排，備份與恢復(fù)，故障恢復(fù)等等。通過(guò)實(shí)現(xiàn) CacheService Operator可以讓開(kāi)發(fā)通過(guò)聲明式的Yaml文件即可創(chuàng)建、配置、管理復(fù)雜的Cache集群。CacheService Operator支持：

1. 創(chuàng)建/銷(xiāo)毀：通過(guò)Yaml聲明CacheService規(guī)格，即可通過(guò)Kubernetes一鍵部署，刪除

2. 伸縮：可以修改Yaml中聲明的副本數(shù)量，Operator實(shí)現(xiàn)擴(kuò)容，配置主從結(jié)構(gòu)，掛載域名等操作

3. 備份：Operator根據(jù)Yaml中聲明的備份機(jī)制，實(shí)現(xiàn)自動(dòng)的備份功能，例例如定期備份，錯(cuò)峰備份等

4. 升級(jí)：實(shí)現(xiàn)不停機(jī)版本升級(jí)，并支持回滾

5. 故障恢復(fù)：?jiǎn)螜C(jī)故障時(shí)，自動(dòng)HA切換，同時(shí)恢復(fù)副本數(shù)量，并自動(dòng)恢復(fù)主從結(jié)構(gòu)

復(fù)雜的應(yīng)用在Kubernetes上部署，服務(wù)數(shù)量眾多，服務(wù)間的依賴(lài)關(guān)系也比較復(fù)雜，每個(gè)服務(wù)都有自己的資源文件，并且可以獨(dú)立的部署與伸縮，這給采用Kubernetes做應(yīng)用編排帶來(lái)了諸多挑戰(zhàn)：

1. 管理、編輯與更新大量的Yaml配置文件，

2. 部署一個(gè)含有大量配置文件的復(fù)雜Kubernetes應(yīng)用，例如上面提到的 CacheService Operator

3. 參數(shù)化配置模板支持多個(gè)環(huán)境

Helm可以解決這些問(wèn)題。Helm把Kubernetes資源（如Pods, Deployments, Services等) 打包到一個(gè) Chart中，實(shí)現(xiàn)可配置的發(fā)布是通過(guò)模板加配置文件，動(dòng)態(tài)生成資源清單文件。

彈性伸縮

在云時(shí)代，彈性已經(jīng)成為新常態(tài)。而且微博的社交媒體屬性，不可提前預(yù)期的突發(fā)峰值是家常便飯，所以基礎(chǔ)設(shè)施不但需要具備彈性，而且需要具備在短時(shí)間內(nèi)提供足夠資源的能力。Kubernetes基于容?技術(shù)在啟動(dòng)時(shí)間方面比虛擬機(jī)更具優(yōu)勢(shì)，省去了虛擬機(jī)創(chuàng)建、環(huán)境初始化、配置管理等諸多環(huán)節(jié)，直接拉起業(yè)務(wù) Pod， 擴(kuò)容時(shí)間可以從分鐘級(jí)縮短到秒級(jí)。

而且峰值流量突發(fā)時(shí)，運(yùn)維、開(kāi)發(fā)同學(xué)可能是在吃飯、睡覺(jué)、休假，這個(gè)時(shí)候靠人為干預(yù)肯定是來(lái)不及的，所以系統(tǒng)需要自動(dòng)做出擴(kuò)容決策。對(duì)于復(fù)雜的分布式系統(tǒng)，實(shí)現(xiàn)自動(dòng)決策需要解決兩個(gè)問(wèn)題，一個(gè)是容量量決策，一個(gè)是依賴(lài)關(guān)系。Kubernetes的HPA(Horizontal Pod Autoscaling)可以根據(jù) Metric自動(dòng)伸縮一個(gè)Deployment 中的 Pod 數(shù)量。HPA由一個(gè)控制循環(huán)實(shí)現(xiàn)，循環(huán)周期由horizontal-pod-autoscaler-sync-period標(biāo)志指定（默認(rèn)是 30 秒）。在每個(gè)周期內(nèi)，查詢(xún)HPA中定義的資源利利用率。并且在擴(kuò)容前會(huì)有一個(gè)冷靜期，一般是5分鐘（可通過(guò)horizontal-pod-autoscaler-downscale-stabilization參數(shù)設(shè)置），然后通過(guò)下面的公式進(jìn)行擴(kuò)縮容：

但是這種容量決策存在兩個(gè)問(wèn)題。因?yàn)橥话l(fā)峰值流量上漲迅速，上述擴(kuò)容機(jī)制第一次擴(kuò)容往擴(kuò)不不到位，觸發(fā)連續(xù)多次擴(kuò)容，導(dǎo)致服務(wù)在流量上漲期間一直處于過(guò)載狀態(tài)，影響服務(wù)SLA。另一個(gè)問(wèn)題是冷靜期問(wèn)題， 如果冷靜期過(guò)長(zhǎng)，會(huì)導(dǎo)致峰值流量無(wú)法得到及時(shí)擴(kuò)容，冷靜期過(guò)短會(huì)錯(cuò)把抖動(dòng)當(dāng)做峰值，造成不必要的成本浪費(fèi)。第三個(gè)問(wèn)題是復(fù)雜的業(yè)務(wù)系統(tǒng)依賴(lài)關(guān)系復(fù)雜，每個(gè)服務(wù)根據(jù)各自指標(biāo)進(jìn)行伸縮，由于上面還未伸縮流量被擋在了了上游，下游這時(shí)感知不到準(zhǔn)確流量趨勢(shì)，從整體應(yīng)用角度看很容易出現(xiàn)上游泄洪下游被淹的問(wèn)題。

微博整體的彈性伸縮架構(gòu)是基于混合云的架構(gòu)，內(nèi)網(wǎng)私有云，公有云虛機(jī)，云Kubernetes，一體化Kubernetes彈性集群，實(shí)現(xiàn)快速自動(dòng)化資源調(diào)度，解決了跨IDC調(diào)度、定制的調(diào)度算法與策略、容量評(píng)估、服務(wù)間擴(kuò)容依賴(lài)關(guān)系等，構(gòu)建了全鏈路路，壓測(cè)，指標(biāo)，報(bào)警，干預(yù)多維度的能力：

1. 全鏈路路是構(gòu)建一個(gè)應(yīng)用整體的容量決策體系，各服務(wù)不再獨(dú)自判定容量，而是根據(jù)全鏈路路容量指標(biāo)作出一致性擴(kuò)容決策

2. 壓測(cè)可以幫助了解目前部署的冗余情況，合理的設(shè)定擴(kuò)容公式，避免多次重復(fù)性擴(kuò)容

3. 指標(biāo)體系是要從成千上萬(wàn)個(gè)Metric中抽象出可以作為決策的依據(jù)，打通負(fù)載均衡，Web服務(wù)，數(shù)據(jù)庫(kù)資源等多維度指標(biāo)

4. 報(bào)警及時(shí)多路徑觸達(dá)，避免單點(diǎn)

5. 干預(yù)不但要支持快速伸縮，還應(yīng)支持快速優(yōu)雅降級(jí)，為服務(wù)擴(kuò)容爭(zhēng)取時(shí)間

CI/CD

云計(jì)算技術(shù)的普及，研發(fā)流程也隨之變化，越來(lái)越多的組織和團(tuán)隊(duì)開(kāi)始接受 DevOps 理念。持續(xù)集成（CI） 和持續(xù)交付（CD）是 DevOps 的基石。但是 CI/CD 在實(shí)際落地過(guò)程中存在諸多困難，導(dǎo)致實(shí)際效果不不理想。以 CI為例，開(kāi)發(fā)同學(xué)應(yīng)該對(duì)“順利利的話(huà)，會(huì)有大約100個(gè)失敗的測(cè)試”這種情形并不不陌生。由于開(kāi)發(fā)環(huán)境與測(cè)試環(huán)境并不一致等諸多因素，CI經(jīng)常出現(xiàn)不相干的偶發(fā)失敗，長(zhǎng)此以往開(kāi)發(fā)同學(xué)會(huì)默認(rèn)選擇忽略CI環(huán)節(jié)的報(bào)錯(cuò)警告，最終導(dǎo)致CI/CD淪為一句口號(hào)。

利用云原生的聲明性基礎(chǔ)架構(gòu)，可以將應(yīng)用系統(tǒng)的和應(yīng)用程序存放在 Git 的版本控制庫(kù)中，每個(gè)開(kāi)發(fā)人員都可以提交拉取請(qǐng)求代碼，輕松在Kubernetes 上部署應(yīng)用程序和運(yùn)維任務(wù)，開(kāi)發(fā)人員可以更高效地將注意力集中在創(chuàng)建新功能而不是運(yùn)維相關(guān)任務(wù)上?；贕it的持續(xù)交付流水線，有諸多優(yōu)勢(shì)和特點(diǎn)：

1. 版本控制的聲明性容器?編排，Kubermetes作為一個(gè)云原生的工具，可以把它的“聲明性”看作是“代碼”，聲明意味著配置由一組事實(shí)而不不是一組指令組成，例如，“有十個(gè)redis服務(wù)器”，而不是“啟動(dòng)十個(gè)redis服務(wù)?，告訴我它是否有效”

2. Git作為事實(shí)的唯一真實(shí)來(lái)源，任何能夠被描述的內(nèi)容都必須存儲(chǔ)在Git庫(kù)中，包括系統(tǒng)相關(guān)的：策略， 代碼，配置，甚至監(jiān)控事件

3. 與其他工具相結(jié)合，例如監(jiān)控系統(tǒng)可以方便地監(jiān)控集群，以及檢查比較實(shí)際環(huán)境的狀態(tài)與代碼庫(kù)上的狀態(tài)是否一致

目前大多數(shù)CI/CD工具都使用基于推送的模型?；谕扑偷牧魉€意味著代碼從CI系統(tǒng)開(kāi)始，通過(guò)一系列構(gòu)建測(cè)試等最終生成鏡像，最后手動(dòng)使用 “kubectl” 將部署到 Kubernetes 集群。程序員是最不喜歡開(kāi)發(fā)流程被打斷，多個(gè)系統(tǒng)間的切換會(huì)極大影響程序員的開(kāi)發(fā)效率。所以我們通過(guò)CI和 IDE結(jié)合，把CI流程融入到開(kāi)發(fā)自測(cè)環(huán)節(jié)中，讓程序員可以進(jìn)行面向CI的測(cè)試驅(qū)動(dòng)開(kāi)發(fā)，提高對(duì)交付代碼質(zhì)量的信心。

CI/CD流水線是圍繞程序員經(jīng)常使用的GitLab構(gòu)建，程序員可以對(duì)Merge Request的CI結(jié)果一目了然，避免了在多個(gè)系統(tǒng)間來(lái)回切換。每次代碼提交都要執(zhí)行基于分支的完整CI流程，借助云原生的彈性能力和共享存儲(chǔ)，解決了大量并發(fā)的Job的計(jì)算資源瓶頸，同時(shí)緩解了Job間共享數(shù)據(jù)的帶寬壓力以及網(wǎng)絡(luò)傳輸延時(shí)。

持續(xù)部署要比持續(xù)集成更加復(fù)雜。部署流程中依賴(lài)人工的環(huán)節(jié)非常多，例如灰度是由運(yùn)維部署到生產(chǎn)環(huán)境部分機(jī)?，驗(yàn)證需要依靠開(kāi)發(fā)和運(yùn)維同學(xué)經(jīng)驗(yàn)檢查新版本各項(xiàng)指標(biāo)是否正常，滾動(dòng)發(fā)布與回滾也需要運(yùn)維同學(xué)全程干預(yù)。金絲雀部署可以有效規(guī)避風(fēng)險(xiǎn)，在生產(chǎn)環(huán)境的基礎(chǔ)設(shè)施中小范圍的部署新的應(yīng)用代碼，如果沒(méi)有錯(cuò)誤，新版本才逐漸推廣到整個(gè)服務(wù)，而不用一次性從老版本切換到新版本。不過(guò)如何驗(yàn)證沒(méi)有錯(cuò)誤是比較有挑戰(zhàn)的，微服務(wù)依賴(lài)復(fù)雜、部署范圍廣、指標(biāo)維度多，是最易出錯(cuò)，最耗時(shí)的環(huán)節(jié)。我們針對(duì)這個(gè)問(wèn)題，開(kāi)發(fā)了智能時(shí)序數(shù)據(jù)異常識(shí)別服務(wù)，覆蓋操作系統(tǒng)，JVM，資源 SLA，業(yè)務(wù) SLA 的上千維度指標(biāo)。它不不但可以自動(dòng)準(zhǔn)確識(shí)別異常識(shí)別，性能衰減等人工經(jīng)驗(yàn)?zāi)軌虬l(fā)現(xiàn)的問(wèn)題，也能夠識(shí)別如資源不不合理訪問(wèn)等人工很難察覺(jué)的問(wèn)題?，F(xiàn)在的CD流程包含部署、集成測(cè)試、金絲雀驗(yàn)證、滾動(dòng)發(fā)布、回滾自動(dòng)化環(huán)節(jié)。

Weibo Mesh

Service Mesh并不是什么新的技術(shù)，它所關(guān)注的高性能、高可用、服務(wù)發(fā)現(xiàn)和治理等有服務(wù)化的一天就已經(jīng)存在，社區(qū)也不不乏這方面的最佳實(shí)踐。不不過(guò)之前主要是兩種方式，一種是微服務(wù)RPC框架形式，例如Motan, gRPC, Thrift, Dubbo等。傳統(tǒng)微服務(wù)框架有諸多弊端：

1. 升級(jí)困難，框架、SDK 的與業(yè)務(wù)代碼強(qiáng)綁定

2. 多語(yǔ)言問(wèn)題，各種語(yǔ)言的服務(wù)治理能力天差地別，服務(wù)質(zhì)量體系難以統(tǒng)一

還有一種是集中式Proxy形式，例如Nginx, Twemproxy, SQL Proxy等。雖然Proxy的形式一定程度上解決了胖客戶(hù)端的問(wèn)題，沒(méi)有了升級(jí)問(wèn)題，多語(yǔ)言可以統(tǒng)一接入。但是在性能方面的損耗，對(duì)于耗時(shí)較長(zhǎng)的請(qǐng)求來(lái)說(shuō)還可以接受，但這在服務(wù)間調(diào)用這種毫秒級(jí)請(qǐng)求時(shí)，性能是不能容忍的，而且服務(wù)的拆分勢(shì)必導(dǎo)致整個(gè)體系內(nèi)耗時(shí)隨著微服務(wù)規(guī)模的擴(kuò)大而劇增，而且Proxy本身很容易成為整個(gè)系統(tǒng)中的瓶頸點(diǎn)。所以經(jīng)?？梢钥吹胶蠖朔?wù)是同時(shí)使用 Proxy和RPC的情況。

而Cloud Native會(huì)催生出如此火爆的Service Mesh，最主要的因素是 Kubernetes使基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)化，大家發(fā)現(xiàn)之前這些很重的RPC框架可以抽離出來(lái)，原本需要增加維護(hù)的復(fù)雜性被Kubernetes解決掉了，跨語(yǔ)言、服務(wù)治理等收益凸顯出來(lái)。而且Mesh的SideCard形式，相比Proxy在請(qǐng)求耗時(shí)方面優(yōu)勢(shì)也相當(dāng)明顯。

微博將Motan RPC胖客戶(hù)端實(shí)現(xiàn)的治理功能下沉到Agent上，服務(wù)注冊(cè)和發(fā)現(xiàn)依賴(lài)微博自研Vintage命名和配置服務(wù)，對(duì)服務(wù)的訂閱和發(fā)現(xiàn)來(lái)建立服務(wù)間依賴(lài)的邏輯網(wǎng)絡(luò)。業(yè)務(wù)與的通信協(xié)議保持一致，Agent支持HTTP和RPC的調(diào)用，業(yè)務(wù)只需把原有的調(diào)用指向Agent即可，不需要改造業(yè)務(wù)代碼。在跨語(yǔ)言通信協(xié)議設(shè)計(jì)方面，Google的Protocol Buffers（pb）序列化能夠提供優(yōu)秀的跨語(yǔ)言序列化能力，但是在一是老舊HTTP遷移到pb 協(xié)議的改造成本過(guò)高，二是部分語(yǔ)言（例如 PHP）在做復(fù)雜pb對(duì)象序列化時(shí)性能比較差，甚至比json序列化還要慢3倍左右。微博實(shí)現(xiàn)了全新語(yǔ)言無(wú)關(guān)的通信協(xié)議 Motan2和跨語(yǔ)言友好的數(shù)據(jù)序列化協(xié)議Simple來(lái)應(yīng)對(duì)跨語(yǔ)。

除了代理Service的能力外，Mesh體系提供了緩存、隊(duì)列等服務(wù)化代理，業(yè)務(wù)方可以與依賴(lài)緩存、隊(duì)列資源治理解耦的能力?？梢源蠓岣吣切┲卫砟芰Ρ容^薄弱的業(yè)務(wù)和語(yǔ)言的架構(gòu)水平。隨著云原生技術(shù)的日趨完善，會(huì)有越來(lái)越多的基礎(chǔ)設(shè)施從原有的 SDK 中抽象出來(lái)。未來(lái)數(shù)據(jù)庫(kù)訪問(wèn)會(huì)以 Database Mesh形式提供訪問(wèn)，封裝數(shù)據(jù)分片、讀寫(xiě)分離、從庫(kù)負(fù)載均衡、熔斷、鏈路路采集能力，例如Google Cloud SQL提供本地Proxy，業(yè)務(wù)方無(wú)需將IP地址列入白名單或配置SSL，即可安全地訪問(wèn)Cloud SQL。

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝