來自：劉超的通俗云計算

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

容器編排

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

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

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

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

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

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

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

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

5. 故障恢復：單機故障時，自動HA切換，同時恢復副本數(shù)量，并自動恢復主從結(jié)構(gòu)

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

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

2. 部署一個含有大量配置文件的復雜Kubernetes應用，例如上面提到的 CacheService Operator

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

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

彈性伸縮

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

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

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

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

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

2. 壓測可以幫助了解目前部署的冗余情況，合理的設定擴容公式，避免多次重復性擴容

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

4. 報警及時多路徑觸達，避免單點

5. 干預不但要支持快速伸縮，還應支持快速優(yōu)雅降級，為服務擴容爭取時間

CI/CD

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

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

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

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

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

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

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

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

Weibo Mesh

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

1. 升級困難，框架、SDK 的與業(yè)務代碼強綁定

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

還有一種是集中式Proxy形式，例如Nginx, Twemproxy, SQL Proxy等。雖然Proxy的形式一定程度上解決了胖客戶端的問題，沒有了升級問題，多語言可以統(tǒng)一接入。但是在性能方面的損耗，對于耗時較長的請求來說還可以接受，但這在服務間調(diào)用這種毫秒級請求時，性能是不能容忍的，而且服務的拆分勢必導致整個體系內(nèi)耗時隨著微服務規(guī)模的擴大而劇增，而且Proxy本身很容易成為整個系統(tǒng)中的瓶頸點。所以經(jīng)常可以看到后端服務是同時使用 Proxy和RPC的情況。

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

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

除了代理Service的能力外，Mesh體系提供了緩存、隊列等服務化代理，業(yè)務方可以與依賴緩存、隊列資源治理解耦的能力。可以大幅提高那些治理能力比較薄弱的業(yè)務和語言的架構(gòu)水平。隨著云原生技術的日趨完善，會有越來越多的基礎設施從原有的 SDK 中抽象出來。未來數(shù)據(jù)庫訪問會以 Database Mesh形式提供訪問，封裝數(shù)據(jù)分片、讀寫分離、從庫負載均衡、熔斷、鏈路路采集能力，例如Google Cloud SQL提供本地Proxy，業(yè)務方無需將IP地址列入白名單或配置SSL，即可安全地訪問Cloud SQL。

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝