導(dǎo)讀：隨著虛擬化技術(shù)的成熟和分布式框架的普及，在容器技術(shù)、可持續(xù)交付、編排系統(tǒng)等開(kāi)源社區(qū)的推動(dòng)下，以及微服務(wù)等開(kāi)發(fā)理念的帶動(dòng)下，應(yīng)用上云已經(jīng)是不可逆轉(zhuǎn)的趨勢(shì)。
云原生帶來(lái)了標(biāo)準(zhǔn)化、松耦合、易觀測(cè)、易擴(kuò)展的特性，為交付基建與業(yè)務(wù)解耦、更靈活的環(huán)境管理和無(wú)損發(fā)布帶來(lái)新機(jī)遇。同時(shí)，微服務(wù)架構(gòu)下服務(wù)數(shù)量爆炸式增長(zhǎng)，對(duì)應(yīng)的交付基建工作量暴增，且服務(wù)間拓?fù)鋸?fù)雜，又導(dǎo)致了升級(jí)影響難評(píng)估、問(wèn)題定位困難、單獨(dú)測(cè)試環(huán)境成本極高等問(wèn)題給高效能交付帶來(lái)了極大挑戰(zhàn)。

愛(ài)番番產(chǎn)品從20年4月全面云化，在云化時(shí)代，通過(guò)與業(yè)務(wù)解耦的DevOps基建，讓業(yè)務(wù)團(tuán)隊(duì)專(zhuān)注與業(yè)務(wù)開(kāi)發(fā)本身，大幅度提升業(yè)務(wù)效能，通過(guò)智能生成契約測(cè)試 case保障服務(wù)間調(diào)用的可靠性，通過(guò)全鏈路灰度能力為線(xiàn)下測(cè)試和無(wú)損發(fā)布賦能，實(shí)現(xiàn)產(chǎn)品的高效能交付。

一、業(yè)務(wù)背景

愛(ài)番番是典型的toB型業(yè)務(wù)，具有以下特點(diǎn)：

• 從產(chǎn)品形態(tài)上，產(chǎn)品戰(zhàn)線(xiàn)長(zhǎng)，涵蓋(拓、聊、追、洞察)等核心產(chǎn)品能力；
• 從市場(chǎng)環(huán)境上，市場(chǎng)環(huán)境競(jìng)爭(zhēng)異常激烈，對(duì)產(chǎn)研的效率與質(zhì)量提出更高的要求；
• 從研發(fā)模式上，產(chǎn)品與研發(fā)采用敏捷思維研發(fā)，需要不斷的創(chuàng)新與試錯(cuò)，快速完成PoC及MVP產(chǎn)品的研發(fā)上線(xiàn)；
• 從部署形態(tài)上，除了提供SaaS服務(wù)外，同時(shí)具有多樣化售賣(mài)的訴求；

團(tuán)隊(duì)以業(yè)務(wù)領(lǐng)域劃分的多個(gè)scrumTeam，如下圖:

二、效能體系面臨的挑戰(zhàn)

2.1 服務(wù)爆炸導(dǎo)致的基礎(chǔ)設(shè)施成本劇增

活躍模塊數(shù)200+，月均新增模塊8個(gè)，流水線(xiàn)、監(jiān)控等基礎(chǔ)設(shè)施接入管理維護(hù)成本劇增。每個(gè)模塊需要接入的基礎(chǔ)設(shè)施如下：

2.2 復(fù)雜拓?fù)鋵?dǎo)致的問(wèn)題定位困難和回歸范圍難以評(píng)估

服務(wù)間拓?fù)鋸?fù)雜，如上圖，復(fù)雜拓?fù)鋷?lái)下列問(wèn)題：
1、升級(jí)影響難評(píng)估，回歸漏測(cè)多；
2、線(xiàn)上問(wèn)題定位困難；
3、環(huán)境規(guī)模龐大，聯(lián)調(diào)測(cè)試成本高；

2.3 越來(lái)越高頻的發(fā)布需求和隨拓?fù)鋸?fù)雜度提升的發(fā)布成本的矛盾

模塊眾多且復(fù)雜拓?fù)?#xff0c;而且模塊間上線(xiàn)有依賴(lài)關(guān)系，每次上線(xiàn)100+模塊，人工控制流程，風(fēng)險(xiǎn)高而且效率越發(fā)低下。但是業(yè)務(wù)上發(fā)布的需求愈發(fā)頻繁，在高頻次的發(fā)布下，如何保障發(fā)布過(guò)程的高效、安全也是一項(xiàng)極大的挑戰(zhàn)。

三、整體的效能改進(jìn)思路

流程機(jī)制層面： 用戶(hù)價(jià)值，流動(dòng)效率提升為核心的敏捷體系建設(shè)，包含以下幾個(gè)方面

• 敏捷迭代機(jī)制：以用戶(hù)價(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ù)；
• 自動(dòng)化：微服務(wù)下合理分層自動(dòng)化體系，可控投入下保障有效質(zhì)量召回；
• 發(fā)布能力：一鍵操作高效執(zhí)行、過(guò)程可視、可感知、可控的極致發(fā)布體驗(yàn)；
• 工具賦能：豐富的工具能力賦能研發(fā)測(cè)試各效能痛點(diǎn)環(huán)節(jié)，為人員賦能（建設(shè)中，本文暫不詳細(xì)介紹）；

下面主要從技術(shù)層面的4個(gè)方向逐一進(jìn)行方案說(shuō)明：

四、與業(yè)務(wù)解耦的Devops基礎(chǔ)設(shè)施服務(wù)

上文已經(jīng)提到，基礎(chǔ)設(shè)施面臨的最大問(wèn)題是，由于爆炸的服務(wù)個(gè)數(shù)帶來(lái)的暴增的DEVOPS基礎(chǔ)設(shè)施接入和維護(hù)成本問(wèn)題。在這個(gè)問(wèn)題的處理上，我們借鑒了 serverless 的思路，把基礎(chǔ)設(shè)施服務(wù)化，與業(yè)務(wù)解耦，獨(dú)立運(yùn)維。以前，我們的業(yè)務(wù)團(tuán)隊(duì)研發(fā)和QA，除了需要進(jìn)行業(yè)務(wù)的開(kāi)發(fā)和測(cè)試工作之外，有大量的時(shí)間都花費(fèi)在了新應(yīng)用、日志、配置的接入以及環(huán)境、流水線(xiàn)、監(jiān)控維護(hù)等等和核心業(yè)務(wù)無(wú)關(guān)的事項(xiàng)上，就像下面這個(gè)圖的左邊，而且，任意基礎(chǔ)設(shè)施服務(wù)要升級(jí)，比如日志平臺(tái)SDK升級(jí)、流水線(xiàn)需要統(tǒng)一增加一項(xiàng)安全檢測(cè)環(huán)節(jié)等等，都需要各個(gè)業(yè)務(wù)團(tuán)隊(duì)配合升級(jí)，落地推廣困難。
如果我們把這些基建內(nèi)容通過(guò)服務(wù)化的形式提供給業(yè)務(wù)團(tuán)隊(duì)使用，就能讓業(yè)務(wù)研發(fā)和QA聚焦于業(yè)務(wù)的關(guān)鍵事項(xiàng)，從而大幅度提升團(tuán)隊(duì)效能。就像下面的右邊這個(gè)圖。同時(shí)基礎(chǔ)設(shè)施的升級(jí)業(yè)務(wù)無(wú)感知，再也不會(huì)有基礎(chǔ)設(shè)施能力落地推廣困難的問(wèn)題。

如何打造與業(yè)務(wù)解耦，服務(wù)化的基礎(chǔ)設(shè)施？

4.1 基礎(chǔ)設(shè)施標(biāo)準(zhǔn)化

與業(yè)務(wù)解耦的第一步是基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)化，只有標(biāo)準(zhǔn)化的過(guò)程才有可能規(guī)模化，從而實(shí)現(xiàn)技術(shù)設(shè)施服務(wù)化。我們主要針對(duì)以下幾部分內(nèi)容進(jìn)行了標(biāo)準(zhǔn)化改造：
1.模塊標(biāo)準(zhǔn)化：代碼結(jié)構(gòu)、打包流程、標(biāo)準(zhǔn)容器、鏡像管理、部署過(guò)程
2.標(biāo)準(zhǔn)流水線(xiàn)
3.標(biāo)準(zhǔn)的基礎(chǔ)服務(wù)：APM組件、配置中心、發(fā)布平臺(tái)、資源管理
4.研發(fā)模式：

4.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è)施的一鍵接入能力。如下圖所示：腳手架是我們這邊新模塊創(chuàng)建的入口。所有新代碼庫(kù)都是通過(guò)腳手架創(chuàng)建，他會(huì)幫助開(kāi)發(fā)自動(dòng)生成一整套集成了標(biāo)準(zhǔn)組件的代碼框架。
在腳手架創(chuàng)建新模塊的時(shí)候，根據(jù)業(yè)務(wù)聲明的模塊屬性，如是否接入apm、模塊代碼類(lèi)型、模塊服務(wù)類(lèi)型等等自動(dòng)完流水線(xiàn)創(chuàng)建、基礎(chǔ)組件接入、集群環(huán)境申請(qǐng)、配置文件生成等操作。一個(gè)新的服務(wù)，從創(chuàng)建代碼庫(kù)到服務(wù)全套基礎(chǔ)設(shè)施接入完成，服務(wù)可直接部署到測(cè)試集群的時(shí)間<10分鐘。

• 腳手架：自動(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ù)完成接入初始化；

運(yùn)行時(shí)：根據(jù)服務(wù)聲明內(nèi)容動(dòng)態(tài)運(yùn)行，實(shí)現(xiàn)業(yè)務(wù)升級(jí)維護(hù)0成本
基礎(chǔ)組件部分，因?yàn)槎际且詓idecar模式提供服務(wù)，所以運(yùn)行時(shí)天然與業(yè)務(wù)解耦，因此重點(diǎn)在于如何實(shí)現(xiàn)流水線(xiàn)在運(yùn)行時(shí)與業(yè)務(wù)解耦。我們針對(duì)流水線(xiàn)進(jìn)行了模板化、參數(shù)化改造，并和業(yè)務(wù)的聲明屬性結(jié)合。就像下面這張圖，流水線(xiàn)每次都是動(dòng)態(tài)運(yùn)行的，運(yùn)行的內(nèi)容是依賴(lài)左側(cè)5部分聲明數(shù)據(jù)實(shí)時(shí)生成，包括cicd通用配置、流水線(xiàn)模板、任務(wù)腳本、任務(wù)策略、業(yè)務(wù)聲明屬性。除了業(yè)務(wù)自己的聲明文件，其余部分都是基礎(chǔ)設(shè)施組獨(dú)立運(yùn)維，故對(duì)應(yīng)任務(wù)優(yōu)化、添加、統(tǒng)一配置修改等均對(duì)業(yè)務(wù)透明。就像右圖，如果要針對(duì)流水線(xiàn)上的某個(gè)環(huán)節(jié)進(jìn)行優(yōu)化，或者增加一些環(huán)節(jié)，僅需基礎(chǔ)設(shè)施組修改流水線(xiàn)模板或者任務(wù)腳本即可。

4.3 智能化基礎(chǔ)設(shè)施

因?yàn)榉?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)定。在流水線(xiàn)運(yùn)行的前中后通過(guò)策略給流水線(xiàn)增加一個(gè)”監(jiān)工”，模擬人工判斷任務(wù)是否應(yīng)該執(zhí)行，模擬人工分析跟進(jìn)、修復(fù)問(wèn)題等。
分析常見(jiàn)的流水線(xiàn)穩(wěn)定和效率問(wèn)題比如環(huán)境不穩(wěn)定、底層資源不穩(wěn)定、網(wǎng)絡(luò)異常等等，大體可分為 偶發(fā)問(wèn)題重試可恢復(fù)、問(wèn)題相對(duì)復(fù)雜需人工排查、阻塞問(wèn)題需人工修復(fù)三類(lèi)。而效率方面大量重復(fù)、無(wú)效任務(wù)比如只加了個(gè)log也要跑全套測(cè)試流程，導(dǎo)致了資源浪費(fèi)，也導(dǎo)致了執(zhí)行效率低下。如下圖左側(cè)所示：

針對(duì)這些場(chǎng)景，我們?cè)诹魉€(xiàn)運(yùn)行前后都添加了可配置的策略判斷過(guò)程，判斷任務(wù)是否需要跳過(guò)、排隊(duì)、重試等等，從而提升穩(wěn)定性和效率。

典型場(chǎng)景：
自動(dòng)紅燈分析：任務(wù)失敗后可自動(dòng)根據(jù)日志錯(cuò)誤碼分析問(wèn)題原因并給出標(biāo)注，方面后續(xù)根據(jù)統(tǒng)計(jì)數(shù)據(jù)更有效的優(yōu)化。

排隊(duì)策略：在自動(dòng)化等任務(wù)執(zhí)行之前，自動(dòng)檢測(cè)依賴(lài)環(huán)境是否正常，從而降低運(yùn)行失敗導(dǎo)致的紅燈。

五、分層自動(dòng)化體系

要想實(shí)現(xiàn)持續(xù)的交付，自動(dòng)化是一個(gè)繞不開(kāi)的話(huà)題，在云原生微服務(wù)的背景下，自動(dòng)化層級(jí)會(huì)發(fā)生怎樣的變化呢？
和傳統(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)的金字塔。

而由于端到端成本過(guò)高,考慮到投入產(chǎn)出比，愛(ài)番番的分層自動(dòng)化是按照右下角這個(gè)結(jié)構(gòu)來(lái)建設(shè)的，其中接口DIFF測(cè)試、契約測(cè)試、純前端DIFF測(cè)試是無(wú)人工介入，最核心的三個(gè)部分。

5.1 基于全鏈路灰度環(huán)境的接口DIFF自動(dòng)化

5.1.1 全鏈路灰度方案
我們接口的DIFF 測(cè)試是基于強(qiáng)大的全鏈路灰度環(huán)境能力來(lái)建設(shè)的，這是云原生架構(gòu)給我們帶來(lái)的紅利。先介紹下我們的全鏈路灰度方案。
我們是基于istio的靈活的路由能力，通過(guò)同構(gòu)底層「分組多維路由」的架構(gòu)設(shè)計(jì)， 自研CRD Operator 構(gòu)建愛(ài)番番的「全鏈路灰度發(fā)布」平臺(tái)。該方案支持了我們的線(xiàn)下多路復(fù)用環(huán)境、線(xiàn)上安全的容量評(píng)估以及金絲雀發(fā)布等多個(gè)場(chǎng)景。

5.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)行訪(fǎng)問(wèn)。

5.1.3 基于多路復(fù)用的DIFF測(cè)試
有了如上所述的多套邏輯隔離的測(cè)試環(huán)境之后，每當(dāng)有新的分支環(huán)境拉出并有代碼更新時(shí)，即可通過(guò)將流量在base環(huán)境（部署最后一次上線(xiàn)的代碼）和新分支環(huán)境進(jìn)行回放，并對(duì)比兩者的返回是否存在差異來(lái)進(jìn)行回歸測(cè)試。我們的diff方案如下：

該方案具備如下幾個(gè)優(yōu)點(diǎn)：

• 基于流量回放的接口diff，最大限度的覆蓋線(xiàn)上用戶(hù)真實(shí)場(chǎng)景；
• 全流程自動(dòng)化，無(wú)人工參與；
• 配置化的流量篩選策略和diff策略接入，便于擴(kuò)展優(yōu)化；
• 分布式任務(wù)運(yùn)行，支持大批量并發(fā)；

5.2 保障召回服務(wù)間調(diào)用問(wèn)題的契約測(cè)試

5.2.1 什么是契約測(cè)試
微服務(wù)的架構(gòu)，服務(wù)之間依賴(lài)復(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ò)了，但是上線(xiàn)后發(fā)現(xiàn) C 團(tuán)隊(duì)功能異常了。

以上問(wèn)題的本質(zhì)原因?yàn)?#xff1a;
服務(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ì)能以一種離線(xiàn)的方式(不需要消費(fèi)者、提供者同時(shí)在線(xiàn))，通過(guò)契約作為中間的標(biāo)準(zhǔn)，驗(yàn)證提供者提供的內(nèi)容是否滿(mǎn)足消費(fèi)者的期望

5.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ù)方能滿(mǎn)足所有消費(fèi)方需求。（下左圖）
也有非消費(fèi)者驅(qū)動(dòng)，提供方生產(chǎn)契約，并提供mock服務(wù)，消費(fèi)方可以基于契約文件測(cè)試，如Spring Cloud Contract。只能解決集成測(cè)試解耦的問(wèn)題（下右圖）

5.2.3 愛(ài)番番的契約測(cè)試方案
愛(ài)番番的方案則是取了折中。一方面由于團(tuán)隊(duì)習(xí)慣，契約一直是服務(wù)提供方給出，另一方面又希望保留消費(fèi)者驅(qū)動(dòng)特性，從而保障服務(wù)方能滿(mǎn)足所有消費(fèi)方需求。我們選擇了在提供方生成契約，但是通過(guò)線(xiàn)上日志和調(diào)用鏈解析的方式來(lái)補(bǔ)充模擬消費(fèi)端契約case。且整個(gè)過(guò)程全自動(dòng)化。

5.2.4 契約測(cè)試技術(shù)實(shí)現(xiàn)
第一步：引入swagger推動(dòng)全接口接入，保障接口管理平臺(tái)的接口文檔信息與實(shí)際代碼達(dá)到準(zhǔn)實(shí)時(shí)同步，詳細(xì)的實(shí)現(xiàn)步驟如下；

第二步： 根據(jù)接口文檔自動(dòng)生成契約case
有了和代碼同步的接口信息之后，則根據(jù)接口文檔信息自動(dòng)生成基礎(chǔ)的契約測(cè)試case。在每次接口信息上傳平臺(tái)的時(shí)候，會(huì)檢測(cè)本次上傳內(nèi)容，根據(jù)內(nèi)容自動(dòng)觸發(fā)新case的生成和老case的驗(yàn)證。驗(yàn)證會(huì)運(yùn)行修改了的接口之前關(guān)聯(lián)的契約測(cè)試case來(lái)檢測(cè)本次接口更新是否破壞原有契約，運(yùn)行結(jié)果通過(guò)報(bào)表記錄，并推送到對(duì)應(yīng)團(tuán)隊(duì)標(biāo)注，根據(jù)標(biāo)注結(jié)果判斷是否更新case。

第三步： 依賴(lài)調(diào)用鏈、日志信息智能分析消費(fèi)端特征，生成模擬消費(fèi)端的case
如下圖，通過(guò)調(diào)用鏈信息，提取出各個(gè)服務(wù)的消費(fèi)方有哪些，通過(guò)各消費(fèi)方的日志分析，獲取模擬各消費(fèi)方契約，并自動(dòng)生成case和接口進(jìn)行關(guān)聯(lián)；

5.3 問(wèn)題智能定位降低自動(dòng)化維護(hù)成本

自動(dòng)化雖然是效能提升的好手段，但是長(zhǎng)期以來(lái)，自動(dòng)化的穩(wěn)定性問(wèn)題、問(wèn)題跟進(jìn)排查成本的居高不下都是阻止大家開(kāi)展自動(dòng)化建設(shè)或者自動(dòng)化建設(shè)半途而廢的重要原因。針對(duì)自動(dòng)化的穩(wěn)定性提升和跟進(jìn)成本降低，我們建設(shè)了case失敗自動(dòng)定位和修復(fù)能力，讓智能化的小助手幫助大家輕輕松松維護(hù)case運(yùn)行。下面是我們自動(dòng)定位的一個(gè)效果實(shí)例：

我們會(huì)在自動(dòng)化case運(yùn)行失敗后，調(diào)用自動(dòng)定位服務(wù)，自動(dòng)對(duì)失敗的case進(jìn)行標(biāo)注，根據(jù)標(biāo)注結(jié)果會(huì)對(duì)失敗case進(jìn)行分類(lèi)處理。
比如，環(huán)境問(wèn)題會(huì)自動(dòng)重試，批量未知會(huì)發(fā)送到自動(dòng)化小組進(jìn)行排查，元素找不到會(huì)發(fā)送到業(yè)務(wù)QA排查。
以下是實(shí)現(xiàn)的方案。包含基礎(chǔ)定位能力和基礎(chǔ)數(shù)據(jù)獲取。在這些基礎(chǔ)能力之上，建設(shè)了配置層，實(shí)現(xiàn)配置解析和調(diào)度能力，讓我們可以通過(guò)配置的方式，靈活組合不同的定位策略快速支持不同場(chǎng)景的問(wèn)題定位。

六、高效安全的持續(xù)發(fā)布

6.1 發(fā)布困境

• 不同類(lèi)型模塊對(duì)接了不同的不發(fā)平臺(tái)和流程，統(tǒng)一發(fā)布困難，底層發(fā)布方式的變更需要各模塊升級(jí)，遷移成本高
• 由于模塊眾多且復(fù)雜拓?fù)?#xff0c;而且模塊間上線(xiàn)有依賴(lài)關(guān)系，每次上線(xiàn)100+模塊，人工控制流程，風(fēng)險(xiǎn)高而且效率低。上線(xiàn)過(guò)程的的記錄和分析人耗也很高。
• 整體上線(xiàn)過(guò)程不可見(jiàn)，風(fēng)險(xiǎn)感知滯后

如何解決以上問(wèn)題？

6.2 多平臺(tái)部署引擎

基于云原生構(gòu)建多平臺(tái)統(tǒng)一的部署與發(fā)布引擎，無(wú)縫集成CICD，實(shí)現(xiàn)發(fā)布過(guò)程的高度標(biāo)準(zhǔn)化，同時(shí)支持多種發(fā)布策略。如下圖：
通過(guò)CD發(fā)布平臺(tái)的統(tǒng)一，實(shí)現(xiàn)各類(lèi)型模塊統(tǒng)一發(fā)布，且底層部署遷移業(yè)務(wù)無(wú)感知。

6.3 發(fā)布劇本設(shè)計(jì)

有了統(tǒng)一的發(fā)布平臺(tái)之后，為了解決上線(xiàn)過(guò)程復(fù)雜低效的問(wèn)題，我們希望實(shí)現(xiàn)完全自動(dòng)化的發(fā)布過(guò)程。
分析發(fā)布前后需要進(jìn)行的事項(xiàng)，如下做圖所示。基于這些事項(xiàng)，梳理了要自動(dòng)完成整個(gè)發(fā)布過(guò)程需要收集的數(shù)據(jù)，如右圖所示，包含發(fā)布模塊封板信息、依賴(lài)信息、配置信息等等。基于這些數(shù)據(jù)，根據(jù)固定的編排邏輯，自動(dòng)生成服務(wù)發(fā)布拓?fù)湟约氨敬紊暇€(xiàn)步驟。生成的上線(xiàn)拓?fù)浜筒襟E信息經(jīng)人工確認(rèn)之后，自動(dòng)調(diào)用對(duì)應(yīng)上線(xiàn)發(fā)布服務(wù)進(jìn)行發(fā)布，并針對(duì)發(fā)布過(guò)程數(shù)據(jù)自動(dòng)統(tǒng)計(jì)，生成發(fā)布過(guò)程總結(jié)。

6.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ā)布過(guò)程可視：服務(wù)粒度的依賴(lài)拓?fù)湟呀?jīng)實(shí)時(shí)上線(xiàn)進(jìn)度展現(xiàn)、過(guò)程可視可感知；

金絲雀發(fā)布策略：發(fā)布無(wú)損、風(fēng)險(xiǎn)及時(shí)感知并召回

七、整體收益

迭代 story 量增長(zhǎng)85.8%，發(fā)布周期穩(wěn)定，研發(fā)測(cè)試周期下降30%，千行 bug 率從1.5降低到0.5。

八、未來(lái)展望

1、通過(guò)IDE本地插件工具，賦能開(kāi)發(fā)編碼測(cè)試過(guò)程，提升研發(fā)環(huán)節(jié)效能；
2、通過(guò)白盒能力，構(gòu)建質(zhì)量風(fēng)險(xiǎn)識(shí)別體系，應(yīng)用于準(zhǔn)入、準(zhǔn)出、灰度等場(chǎng)景；

---------- END ----------

點(diǎn)擊進(jìn)入了解更多技術(shù)資訊~~

與50位技術(shù)專(zhuān)家面對(duì)面20年技術(shù)見(jiàn)證，附贈(zèng)技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的云原生架构下的持续交付实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。