深度了解微博云原生技術(shù)的思考與實(shí)踐

移動(dòng)互聯(lián)網(wǎng)高速發(fā)展的早期，企業(yè)更多關(guān)注業(yè)務(wù)擴(kuò)張，用成本投入來(lái)?yè)Q取市場(chǎng)占用率。但如今移動(dòng)互聯(lián)網(wǎng)經(jīng)歷了近十年的高速發(fā)展，互聯(lián)網(wǎng)人口紅利逐漸消退，幾乎沒(méi)有公司能夠再忽視成本。無(wú)論是蘋(píng)果公司的供應(yīng)鏈、庫(kù)存管理，還是特斯拉通過(guò)國(guó)產(chǎn)化降低成本，又或者是各大云廠(chǎng)商對(duì)企業(yè) IT 成本的優(yōu)化，都是這些企業(yè)保持高速發(fā)展的重要因素。

企業(yè)在早期的資源使用上以滿(mǎn)足業(yè)務(wù)需求為第一要?jiǎng)?wù)，資源的使用率管理相對(duì)粗放。無(wú)論是機(jī)器規(guī)劃的多樣化還是容量規(guī)劃問(wèn)題，或者是在離線(xiàn)資源的整合問(wèn)題，歸納起來(lái)其實(shí)都是額外預(yù)留了不需要的資源，導(dǎo)致成本浪費(fèi)。

近些年隨著云原生的興起和建設(shè)，服務(wù)已經(jīng)具備快速遷移能力?；诖耍Y源容量就可以按需申請(qǐng)，最小化閑置資源，業(yè)務(wù)也可以在不同的時(shí)間段在相同的機(jī)器上按需要部署，不同規(guī)格的機(jī)器可以基于超高規(guī)格的機(jī)器(256C/2T)混合部署，化零為整，大幅降低資源成本。微博在云原生改造過(guò)程中也嘗試進(jìn)行了各種能力建設(shè)，并梳理了以下 6 種有效的成本優(yōu)化手段。

現(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)各公有云廠(chǎng)商提供標(biāo)準(zhǔn)的 Kubernetes 服務(wù)，這就確保通過(guò) Kubernetes 部署的應(yīng)用在不同云廠(chǎng)商之間具有可遷移性，避免被廠(chǎ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)整上線(xiàn)的步長(zhǎng)，上線(xiàn)過(guò)程中保持容器的IP不變，減少在上線(xiàn)過(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)，避免了上線(xiàn)過(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)：

apiVersion: v1 kind: Pod metadata: name: wb_service annotations: "cni.projectcalico.org/ipAddrs": "[\"10.142.0.50\"]"

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ù)混部的編排：

apiVersion: v1 kind: Pod metadata: name: wb_service_b annotations: "cni.projectcalico.org/ipAddrs": "[\"10.142.0.50\"]" labels: service: wb_service_b spec: affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: service operator: In values: ["wb_service_a"] topologyKey: "kubernetes.io/hostname"

一些比較復(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 支持：

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

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

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

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

故障恢復(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)：

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

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

參數(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ò)縮容：

desired = ceil[current * ( currentMetric / desiredMetric )]

但是這種容量決策存在兩個(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ù)多維度的能力：

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

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

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

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

干預(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ù)上?；?Git 的持續(xù)交付流水線(xiàn)，有諸多優(yōu)勢(shì)和特點(diǎn)：

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

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

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

目前大多數(shù) CI/CD 工具都使用基于推送的模型?；谕扑偷牧魉€(xiàn)意味著代碼從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 流水線(xiàn)是圍繞程序員經(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í)別如資源不合理訪(fǎng)問(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ù)框架有諸多弊端：

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

多語(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ù)訪(fǎng)問(wèn)會(huì)以 Database Mesh 形式提供訪(fǎng)問(wèn)，封裝數(shù)據(jù)分片、讀寫(xiě)分離、從庫(kù)負(fù)載均衡、熔斷、鏈路采集能力，例如 Google Cloud SQL 提供本地 Proxy，業(yè)務(wù)方無(wú)需將 IP 地址列入白名單或配置 SSL，即可安全地訪(fǎng)問(wèn) Cloud SQL。

Kubernetes入門(mén)與實(shí)戰(zhàn)培訓(xùn)

Kubernetes入門(mén)與實(shí)戰(zhàn)培訓(xùn)將于2019年11月22日在北京開(kāi)課，3天時(shí)間帶你系統(tǒng)掌握Kubernetes，學(xué)習(xí)效果不好可以繼續(xù)學(xué)習(xí)。本次培訓(xùn)包括：Docker基礎(chǔ)、容器技術(shù)、Docker鏡像、數(shù)據(jù)共享與持久化、Docker實(shí)踐、Kubernetes基礎(chǔ)、Pod基礎(chǔ)與進(jìn)階、常用對(duì)象操作、服務(wù)發(fā)現(xiàn)、Helm、Kubernetes核心組件原理分析、Kubernetes服務(wù)質(zhì)量保證、調(diào)度詳解與應(yīng)用場(chǎng)景、網(wǎng)絡(luò)、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等等，點(diǎn)擊下方圖片或者閱讀原文鏈接查看詳情。