云原生架構(gòu)下的持續(xù)交付實(shí)踐
點(diǎn)擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”
回復(fù)”669“獲取獨(dú)家整理的精選資料集
回復(fù)”加群“加入全國(guó)服務(wù)端高端社群「后端圈」
全文約6100字，預(yù)計(jì)閱讀時(shí)間15分鐘
導(dǎo)讀
1. 微服務(wù)架構(gòu)下效能體系面臨的挑戰(zhàn)
愛(ài)番番是典型的 toB 型業(yè)務(wù)，具有以下特點(diǎn)：
從產(chǎn)品形態(tài)上，產(chǎn)品戰(zhàn)線長(zhǎng)，涵蓋 ( 拓、聊、追、洞察 ) 等核心產(chǎn)品能力。 從市場(chǎng)環(huán)境上，市場(chǎng)環(huán)境環(huán)境競(jìng)爭(zhēng)異常激烈，對(duì)產(chǎn)研的效率與質(zhì)量提出更高的要求。 從研發(fā)模式上，產(chǎn)品與研發(fā)采用敏捷思維研發(fā)，需要不斷的創(chuàng)新與試錯(cuò)，快速完成 PoC及 MVP 產(chǎn)品的研發(fā)上線。 從部署形態(tài)上，除了提供 SaaS 服務(wù)外，同時(shí)具有多樣化售賣的訴求。
團(tuán)隊(duì)以業(yè)務(wù)領(lǐng)域劃分的多個(gè)?scrumTeam，如下圖：
團(tuán)隊(duì)持續(xù)交付面臨的挑戰(zhàn)：
服務(wù)爆炸導(dǎo)致的基礎(chǔ)設(shè)施成本劇增。活躍模塊數(shù) 200+，月均新增模塊 8個(gè)，每個(gè)模塊需要接入的基礎(chǔ)設(shè)施如下圖，導(dǎo)致需要大量人力進(jìn)行流水線、監(jiān)控等基礎(chǔ)設(shè)施接入管理維護(hù)。
復(fù)雜拓?fù)鋵?dǎo)致的問(wèn)題定位困難和回歸范圍難以評(píng)估。服務(wù)間拓?fù)鋸?fù)雜，導(dǎo)致升級(jí)影響難評(píng)估、回歸漏測(cè)多、線上問(wèn)題定位困難、環(huán)境規(guī)模龐大，聯(lián)調(diào)測(cè)試成本高等問(wèn)題。
越來(lái)越高頻的發(fā)布需求和隨拓?fù)鋸?fù)雜度提升的發(fā)布成本的矛盾。模塊眾多且復(fù)雜拓?fù)?，而且模塊間上線有依賴關(guān)系，每次上線 100+ 模塊，人工控制流程，風(fēng)險(xiǎn)高而且效率越發(fā)低下，但業(yè)務(wù)上發(fā)布的需求愈發(fā)頻繁，在高頻次的發(fā)布下，如何保障發(fā)布過(guò)程的高效、安全也是一項(xiàng)極大的挑戰(zhàn)。
2. 云原生架構(gòu)下的持續(xù)交付實(shí)踐
為實(shí)現(xiàn)團(tuán)隊(duì)高效的價(jià)值交付，我們從敏捷機(jī)制改進(jìn)和全流程持續(xù)交付能力提升兩方面開(kāi)展了建設(shè)：
流程機(jī)制層面：?用戶價(jià)值，流動(dòng)效率提升為核心的敏捷體系建設(shè)，包含以下幾個(gè)方面：
敏捷迭代機(jī)制：以用戶價(jià)值流動(dòng)效率為核心理念，保障團(tuán)隊(duì)目標(biāo)一致，信息透明。 需求拆分管理：標(biāo)準(zhǔn)化、可視化、自動(dòng)化的管理機(jī)制，在成本可控的前提下達(dá)成小批量需求加速流動(dòng)，快速驗(yàn)證價(jià)值。 分支模式和環(huán)境管理：基于云原生強(qiáng)大的流量管控能力，實(shí)現(xiàn)基于 istio 的全鏈路灰度環(huán)境能力，實(shí)現(xiàn)簡(jiǎn)潔、靈活、低風(fēng)險(xiǎn)的分支模式。 全流程的數(shù)據(jù)度量體系：通過(guò)目標(biāo)指標(biāo)度量了解現(xiàn)狀，過(guò)程指標(biāo)度量挖掘問(wèn)題，問(wèn)題自動(dòng)創(chuàng)建任務(wù)，協(xié)同 peer 推動(dòng)問(wèn)題閉環(huán)。
技術(shù)層面：全流程環(huán)節(jié)自動(dòng)化智能化提升，包含以下幾個(gè)方面：
基礎(chǔ)設(shè)施：建設(shè)與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施服務(wù)，解決服務(wù)爆炸帶來(lái)的成本問(wèn)題。
自動(dòng)化：微服務(wù)下合理分層自動(dòng)化體系，可控投入下保障有效質(zhì)量召回，解決復(fù)雜拓?fù)鋷?lái)的回歸漏測(cè)問(wèn)題。
發(fā)布能力：一鍵操作高效執(zhí)行、過(guò)程可視、可感知、可控的極致發(fā)布體驗(yàn)，解決高頻發(fā)布需求下的發(fā)布成本問(wèn)題。
工具賦能：豐富的工具能力賦能研發(fā)測(cè)試各效能痛點(diǎn)環(huán)節(jié)，為人員賦能（建設(shè)中，本文暫不詳細(xì)介紹）。
2.1 基礎(chǔ)設(shè)施：與業(yè)務(wù)解耦的 Devops 基礎(chǔ)設(shè)施服務(wù)
什么是與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施？
2.1.1 基礎(chǔ)設(shè)施標(biāo)準(zhǔn)化
2.1.2 聲明式基礎(chǔ)設(shè)施
與業(yè)務(wù)解耦的第二步，是基于標(biāo)準(zhǔn)化的基礎(chǔ)上，建立聲明式的基礎(chǔ)設(shè)施能力。這里的聲明式是指給業(yè)務(wù)團(tuán)隊(duì)聲明式的基礎(chǔ)設(shè)施體驗(yàn)。業(yè)務(wù)團(tuán)隊(duì)只需要在標(biāo)準(zhǔn)配置中聲明一些基礎(chǔ)屬性，即可自動(dòng)完成所有基礎(chǔ)設(shè)施的接入，且后續(xù)維護(hù)上業(yè)務(wù) 0 成本。主要分為兩個(gè)環(huán)節(jié)的建設(shè)：
接入時(shí)：分鐘級(jí)的一鍵接入
我們的做法是通過(guò)腳手架為抓手來(lái)構(gòu)建基礎(chǔ)設(shè)施的一鍵接入能力。如下圖所示：
腳手架：自動(dòng)生成框架代碼，包含基礎(chǔ) apm 組件、api 管理平臺(tái)等的接入。
configMap：自動(dòng)生成應(yīng)用標(biāo)準(zhǔn)配置并基于配置新增/變更主動(dòng)觸發(fā)接入服務(wù)。
接入服務(wù)：拉取 configMap 配置并解析，根據(jù)配置內(nèi)容調(diào)度不同的基礎(chǔ)設(shè)施服務(wù)完成接入初始化。
腳手架是我們這邊新模塊創(chuàng)建的入口。所有新代碼庫(kù)都是通過(guò)腳手架創(chuàng)建，他會(huì)幫助開(kāi)發(fā)自動(dòng)生成一整套集成了標(biāo)準(zhǔn)組件的代碼框架。
在腳手架創(chuàng)建新模塊的時(shí)候，根據(jù)業(yè)務(wù)聲明的模塊屬性，如是否接入 apm、模塊代碼類型、模塊服務(wù)類型等等自動(dòng)完流水線創(chuàng)建、基礎(chǔ)組件接入、集群環(huán)境申請(qǐng)、配置文件生成等操作。一個(gè)新的服務(wù)，從創(chuàng)建代碼庫(kù)到服務(wù)全套基礎(chǔ)設(shè)施接入完成，服務(wù)可直接部署到測(cè)試集群的時(shí)間< 10 分鐘。
運(yùn)行時(shí)：根據(jù)服務(wù)聲明內(nèi)容動(dòng)態(tài)運(yùn)行，實(shí)現(xiàn)業(yè)務(wù)升級(jí)維護(hù)0成本
2.1.3?智能化基礎(chǔ)設(shè)施
與業(yè)務(wù)解耦的第三步，通過(guò)智能化的策略能力，實(shí)現(xiàn)高穩(wěn)定的基礎(chǔ)設(shè)施服務(wù)。
服務(wù)化之后，基礎(chǔ)設(shè)施作為獨(dú)立運(yùn)維的服務(wù)，所有的問(wèn)題都需要設(shè)施團(tuán)隊(duì)獨(dú)立維護(hù)排查，所以與業(yè)務(wù)解耦的第三步就是建立高穩(wěn)定高效低運(yùn)維成本的基礎(chǔ)設(shè)施能力。我們的思路是通過(guò)智能化的策略，來(lái)保障高效和穩(wěn)定。在流水線運(yùn)行的前中后通過(guò)策略給流水線增加一個(gè)”監(jiān)工”，模擬人工判斷任務(wù)是否應(yīng)該執(zhí)行，模擬人工分析跟進(jìn)、修復(fù)問(wèn)題等。
典型場(chǎng)景：
排隊(duì)策略：在自動(dòng)化等任務(wù)執(zhí)行之前，自動(dòng)檢測(cè)依賴環(huán)境是否正常，從而降低運(yùn)行失敗導(dǎo)致的紅燈。
2.1.4?與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施帶來(lái)的收益
成本：模版創(chuàng)建&維護(hù)流水線 1000+，降低創(chuàng)建和維護(hù)成本 90%。
穩(wěn)定：流水線整體穩(wěn)定性從 85% 提升到 95%， 工具鏈穩(wěn)定性從 95% 提升到 99%。
效率：代碼提交到部署完成 80 分位時(shí)間從 30+ 分鐘降低到 10 分鐘。
2.2 自動(dòng)化：分層自動(dòng)化體系
解決了服務(wù)暴增的問(wèn)題，下面我們來(lái)看復(fù)雜拓?fù)湎碌幕貧w漏測(cè)問(wèn)題。通常情況下解決回歸的質(zhì)量和效率問(wèn)題，都會(huì)想到自動(dòng)化測(cè)試。但是云原生微服務(wù)架構(gòu)下，什么樣的分層自動(dòng)化體系，可以既保障召回，又不引入過(guò)多的自動(dòng)化建設(shè)和維護(hù)成本呢？和傳統(tǒng) 3 層金字塔自動(dòng)化不一樣，云原生架構(gòu)下的自動(dòng)化，由于服務(wù)內(nèi)部相對(duì)簡(jiǎn)單，而服務(wù)拓?fù)鋸?fù)雜，所以測(cè)試的重點(diǎn)是在系統(tǒng)端到端測(cè)試，實(shí)際的分層測(cè)試的比重更像一個(gè)倒過(guò)來(lái)的金字塔。
2.2.1?基于全鏈路灰度環(huán)境的接口DIFF自動(dòng)化
2.2.1.1?全鏈路灰度方案
我們接口的 DIFF 測(cè)試是基于強(qiáng)大的全鏈路灰度環(huán)境能力來(lái)建設(shè)的，這是云原生架構(gòu)給我們帶來(lái)的紅利。先介紹下我們的全鏈路灰度方案。
2.2.1.2?測(cè)試環(huán)境多路復(fù)用
測(cè)試環(huán)境多路復(fù)用是指，使用有限的資源，在一套基礎(chǔ)環(huán)境上邏輯隔離出多套環(huán)境，支持并行開(kāi)發(fā)、聯(lián)調(diào)的需求。
如下圖所示，不同的分支對(duì)應(yīng)著不同的 feature，通過(guò)流量染色 + 流量規(guī)則路由的方式，使得不同分支擁有邏輯上隔離的環(huán)境，支持并行開(kāi)發(fā)。在前端給流量打上橘色標(biāo)記之后，全鏈路的請(qǐng)求會(huì)走橘色的鏈路進(jìn)行訪問(wèn)。
2.2.1.3?基于多路復(fù)用的 DIFF 測(cè)試
基于流量回放的接口 diff，最大限度的覆蓋線上用戶真實(shí)場(chǎng)景。
全流程自動(dòng)化，無(wú)人工參與。
配置化的流量篩選策略和 diff 策略接入，便于擴(kuò)展優(yōu)化。
分布式任務(wù)運(yùn)行，支持大批量并發(fā)。
2.2.2?保障召回服務(wù)間調(diào)用問(wèn)題的契約測(cè)試
2.2.2.1?什么是契約測(cè)試
微服務(wù)的架構(gòu)，服務(wù)之間依賴復(fù)雜，而且通常每個(gè)服務(wù)都是獨(dú)立的團(tuán)隊(duì)維護(hù)，服務(wù)和服務(wù)之間，前后端之間大多通過(guò) API 調(diào)用。那么這種情況下可能就會(huì)出現(xiàn)如下場(chǎng)景：A 團(tuán)隊(duì)開(kāi)發(fā)的 API 同時(shí)服務(wù)于 B\C 團(tuán)隊(duì)。最開(kāi)始測(cè)試的時(shí)候都是通過(guò)的。但是后續(xù)迭代中，B 團(tuán)隊(duì)對(duì)字段 A 有一些調(diào)整的需求，A 團(tuán)隊(duì)根據(jù)需求改了，也測(cè)試通過(guò)了，但是上線后發(fā)現(xiàn) C 團(tuán)隊(duì)功能異常了。
以上問(wèn)題的本質(zhì)原因?yàn)椋?/p>
服務(wù)提供方服務(wù)的消費(fèi)者越來(lái)越多的情況下，服務(wù)的變更影響難以評(píng)估，服務(wù)的變更也不能及時(shí)同步到所有消費(fèi)者，所以往往是消費(fèi)方發(fā)現(xiàn)問(wèn)題了反饋，導(dǎo)致?lián)p失。為了避免上述問(wèn)題，我們引入了契約測(cè)試。
契約測(cè)試的核心思路是通過(guò)消費(fèi)者驅(qū)動(dòng)的方式，建立服務(wù)端和各個(gè)消費(fèi)端之前的契約，在服務(wù)端有修改之后，通過(guò)測(cè)試和所有消費(fèi)方之前的契約是否被毀壞來(lái)保障服務(wù)升級(jí)的安全性。同時(shí)，契約也可以作為雙方測(cè)試解耦的手段。通過(guò)契約測(cè)試，團(tuán)隊(duì)能以一種離線的方式 ( 不需要消費(fèi)者、提供者同時(shí)在線 )，通過(guò)契約作為中間的標(biāo)準(zhǔn)，驗(yàn)證提供者提供的內(nèi)容是否滿足消費(fèi)者的期望。
2.2.2.2?常見(jiàn)的契約測(cè)試方案
常見(jiàn)的契約測(cè)試方案有真正實(shí)踐消費(fèi)者驅(qū)動(dòng)的如 pact，契約由消費(fèi)端生成并維護(hù)，提供方代碼更新之后，拉取所有消費(fèi)方契約進(jìn)行測(cè)試，即解決了集成測(cè)試解耦問(wèn)題，又保障了服務(wù)方能滿足所有消費(fèi)方需求。（ 下左圖 ）
2.2.2.3?愛(ài)番番的契約測(cè)試方案
愛(ài)番番的方案則是取了折中。一方面由于團(tuán)隊(duì)習(xí)慣，契約一直是服務(wù)提供方給出，另一方面又希望保留消費(fèi)者驅(qū)動(dòng)特性，從而保障服務(wù)方能滿足所有消費(fèi)方需求。我們選擇了在提供方生成契約，但是通過(guò)線上日志和調(diào)用鏈解析的方式來(lái)補(bǔ)充模擬消費(fèi)端契約case。且整個(gè)過(guò)程全自動(dòng)化。
2.2.3?問(wèn)題智能定位降低自動(dòng)化維護(hù)成本
比如，環(huán)境問(wèn)題會(huì)自動(dòng)重試，批量未知會(huì)發(fā)送到自動(dòng)化小組進(jìn)行排查，元素找不到會(huì)發(fā)送到業(yè)務(wù) QA 排查。
2.3 發(fā)布能力：高效安全的持續(xù)發(fā)布
2.3.1?發(fā)布困境
不同類型模塊對(duì)接了不同的發(fā)布平臺(tái)和流程，統(tǒng)一發(fā)布困難，底層發(fā)布方式的變更需要各模塊升級(jí)，遷移成本高。
由于模塊眾多且復(fù)雜拓?fù)?，而且模塊間上線有依賴關(guān)系，每次上線 100+ 模塊，人工控制流程，風(fēng)險(xiǎn)高而且效率低。上線過(guò)程的的記錄和分析人耗也很高。
整體上線過(guò)程不可見(jiàn)，風(fēng)險(xiǎn)感知滯后。
如何解決以上問(wèn)題？
2.3.2?多平臺(tái)部署引擎
2.3.3?發(fā)布劇本設(shè)計(jì)
有了統(tǒng)一的發(fā)布平臺(tái)之后，為了解決上線過(guò)程復(fù)雜低效的問(wèn)題，我們希望實(shí)現(xiàn)完全自動(dòng)化的發(fā)布過(guò)程。
2.3.4?過(guò)程可視、可感知、可控的一鍵發(fā)布
有了自動(dòng)化分發(fā)布過(guò)程之后，為了能夠及時(shí)感知發(fā)布過(guò)程中的問(wèn)題，降低發(fā)布風(fēng)險(xiǎn)，進(jìn)行了發(fā)布過(guò)程可視化建設(shè)，并與 APM、金絲雀發(fā)布等策略結(jié)合，保障發(fā)布的安全。
金絲雀發(fā)布策略：發(fā)布無(wú)損、風(fēng)險(xiǎn)及時(shí)感知并召回。
3. 整體收益
迭代 story 量增長(zhǎng) 85.8%，發(fā)布周期穩(wěn)定，研發(fā)測(cè)試周期下降 30%，千行?bug 率從 1.5 降低到 0.5。
4. 未來(lái)展望
Local 工具箱賦能開(kāi)發(fā)效能，通過(guò) IDE 本地插件工具，賦能開(kāi)發(fā)編碼測(cè)試過(guò)程，提升研發(fā)環(huán)節(jié)效能。
智能風(fēng)險(xiǎn)識(shí)別，通過(guò)白盒能力，構(gòu)建質(zhì)量風(fēng)險(xiǎn)識(shí)別體系，應(yīng)用于準(zhǔn)入、準(zhǔn)出、灰度等場(chǎng)景。
5.?作者介紹
烏拉，在百度愛(ài)番番主要負(fù)責(zé)團(tuán)隊(duì)持續(xù)交付建設(shè)。
— 本文結(jié)束 —
●?漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐
關(guān)注我，回復(fù) 「加群」 加入各種主題討論群。
對(duì)「服務(wù)端思維」有期待，請(qǐng)?jiān)谖哪c(diǎn)個(gè)在看
喜歡這篇文章，歡迎轉(zhuǎn)發(fā)、分享朋友圈
