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

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

一、業(yè)務背景

愛番番是典型的toB型業(yè)務，具有以下特點：

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

團隊以業(yè)務領域劃分的多個scrumTeam，如下圖:

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

2.1 服務爆炸導致的基礎設施成本劇增

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

2.2 復雜拓撲導致的問題定位困難和回歸范圍難以評估

服務間拓撲復雜，如上圖，復雜拓撲帶來下列問題：
1、升級影響難評估，回歸漏測多；
2、線上問題定位困難；
3、環(huán)境規(guī)模龐大，聯(lián)調(diào)測試成本高；

2.3 越來越高頻的發(fā)布需求和隨拓撲復雜度提升的發(fā)布成本的矛盾

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

三、整體的效能改進思路

流程機制層面： 用戶價值，流動效率提升為核心的敏捷體系建設，包含以下幾個方面

• 敏捷迭代機制：以用戶價值流動效率為核心理念，保障團隊目標一致，信息透明；
• 需求拆分管理：標準化、可視化、自動化的管理機制，在成本可控的前提下達成小批量需求加速流動，快速驗證價值；
• 分支模式和環(huán)境管理：基于云原生強大的流量管控能力，實現(xiàn)基于istio的全鏈路灰度環(huán)境能力，實現(xiàn)簡潔、靈活、低風險的分支模式；
• 全流程的數(shù)據(jù)度量體系：通過目標指標度量了解現(xiàn)狀，過程指標度量挖掘問題，問題自動創(chuàng)建任務，協(xié)同 peer推動問題閉環(huán)；

技術層面：全流程環(huán)節(jié)自動化智能化提升，包含以下幾個方面：

• 基礎設施：建設與業(yè)務解耦的基礎設施服務；
• 自動化：微服務下合理分層自動化體系，可控投入下保障有效質(zhì)量召回；
• 發(fā)布能力：一鍵操作高效執(zhí)行、過程可視、可感知、可控的極致發(fā)布體驗；
• 工具賦能：豐富的工具能力賦能研發(fā)測試各效能痛點環(huán)節(jié)，為人員賦能（建設中，本文暫不詳細介紹）；

下面主要從技術層面的4個方向逐一進行方案說明：

四、與業(yè)務解耦的Devops基礎設施服務

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

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

4.1 基礎設施標準化

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

4.2 聲明式基礎設施

與業(yè)務解耦的第二步，是基于標準化的基礎上，建立聲明式的基礎設施能力。這里的聲明式是指給業(yè)務團隊聲明式的基礎設施體驗。業(yè)務團隊只需要在標準配置中聲明一些基礎屬性，即可自動完成所有基礎設施的接入，且后續(xù)維護上業(yè)務0成本。主要分為兩個環(huán)節(jié)的建設：
接入時：分鐘級的一鍵接入
我們的做法是通過腳手架為抓手來構建基礎設施的一鍵接入能力。如下圖所示：腳手架是我們這邊新模塊創(chuàng)建的入口。所有新代碼庫都是通過腳手架創(chuàng)建，他會幫助開發(fā)自動生成一整套集成了標準組件的代碼框架。
在腳手架創(chuàng)建新模塊的時候，根據(jù)業(yè)務聲明的模塊屬性，如是否接入apm、模塊代碼類型、模塊服務類型等等自動完流水線創(chuàng)建、基礎組件接入、集群環(huán)境申請、配置文件生成等操作。一個新的服務，從創(chuàng)建代碼庫到服務全套基礎設施接入完成，服務可直接部署到測試集群的時間<10分鐘。

• 腳手架：自動生成框架代碼，包含基礎apm組件、api管理平臺等的接入；
• configMap:自動生成應用標準配置并基于配置新增/變更主動觸發(fā)接入服務；
• 接入服務：拉取configMap配置并解析，根據(jù)配置內(nèi)容調(diào)度不同的基礎設施服務完成接入初始化；

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

4.3 智能化基礎設施

因為服務化之后，基礎設施作為獨立運維的服務，所有的問題都需要設施團隊獨立維護排查，所以與業(yè)務解耦的第三步就是建立高穩(wěn)定高效低運維成本的基礎設施能力。我們的思路是通過智能化的策略，來保障高效和穩(wěn)定。在流水線運行的前中后通過策略給流水線增加一個”監(jiān)工”，模擬人工判斷任務是否應該執(zhí)行，模擬人工分析跟進、修復問題等。
分析常見的流水線穩(wěn)定和效率問題比如環(huán)境不穩(wěn)定、底層資源不穩(wěn)定、網(wǎng)絡異常等等，大體可分為 偶發(fā)問題重試可恢復、問題相對復雜需人工排查、阻塞問題需人工修復三類。而效率方面大量重復、無效任務比如只加了個log也要跑全套測試流程，導致了資源浪費，也導致了執(zhí)行效率低下。如下圖左側所示：

針對這些場景，我們在流水線運行前后都添加了可配置的策略判斷過程，判斷任務是否需要跳過、排隊、重試等等，從而提升穩(wěn)定性和效率。

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

排隊策略：在自動化等任務執(zhí)行之前，自動檢測依賴環(huán)境是否正常，從而降低運行失敗導致的紅燈。

五、分層自動化體系

要想實現(xiàn)持續(xù)的交付，自動化是一個繞不開的話題，在云原生微服務的背景下，自動化層級會發(fā)生怎樣的變化呢？
和傳統(tǒng)3層金字塔自動化不一樣，云原生架構下的自動化，由于服務內(nèi)部相對簡單，而服務拓撲復雜，所以測試的重點是在系統(tǒng)端到端測試，實際的分層測試的比重更像一個倒過來的金字塔。

而由于端到端成本過高,考慮到投入產(chǎn)出比，愛番番的分層自動化是按照右下角這個結構來建設的，其中接口DIFF測試、契約測試、純前端DIFF測試是無人工介入，最核心的三個部分。

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

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

5.1.2 測試環(huán)境多路復用
測試環(huán)境多路復用是指，使用有限的資源，在一套基礎環(huán)境上邏輯隔離出多套環(huán)境，支持并行開發(fā)、聯(lián)調(diào)的需求。
如下圖所示，不同的分支對應著不同的feature，通過流量染色+流量規(guī)則路由的方式，使得不同分支擁有邏輯上隔離的環(huán)境，支持并行開發(fā)。在前端給流量打上橘色標記之后，全鏈路的請求會走橘色的鏈路進行訪問。

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

該方案具備如下幾個優(yōu)點：

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

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

5.2.1 什么是契約測試
微服務的架構，服務之間依賴復雜，而且通常每個服務都是獨立的團隊維護，服務和服務之間，前后端之間大多通過API調(diào)用。那么這種情況下可能就會出現(xiàn)如下場景：A 團隊開發(fā)的 API 同時服務于 B\C 團隊。最開始測試的時候都是通過的。但是后續(xù)迭代中，B 團隊對字段 A 有一些調(diào)整的需求，A 團隊根據(jù)需求改了，也測試通過了，但是上線后發(fā)現(xiàn) C 團隊功能異常了。

以上問題的本質(zhì)原因為：
服務提供方服務的消費者越來越多的情況下，服務的變更影響難以評估，服務的變更也不能及時同步到所有消費者，所以往往是消費方發(fā)現(xiàn)問題了反饋，導致?lián)p失。為了避免上述問題，我們引入了契約測試。
契約測試的核心思路是通過消費者驅動的方式，建立服務端和各個消費端之前的契約，在服務端有修改之后，通過測試和所有消費方之前的契約是否被毀壞來保障服務升級的安全性。同時，契約也可以作為雙方測試解耦的手段。通過契約測試，團隊能以一種離線的方式(不需要消費者、提供者同時在線)，通過契約作為中間的標準，驗證提供者提供的內(nèi)容是否滿足消費者的期望

5.2.2 常見的契約測試方案
常見的契約測試方案有真正實踐消費者驅動的如pact，契約由消費端生成并維護，提供方代碼更新之后，拉取所有消費方契約進行測試，即解決了集成測試解耦問題，又保障了服務方能滿足所有消費方需求。（下左圖）
也有非消費者驅動，提供方生產(chǎn)契約，并提供mock服務，消費方可以基于契約文件測試，如Spring Cloud Contract。只能解決集成測試解耦的問題（下右圖）

5.2.3 愛番番的契約測試方案
愛番番的方案則是取了折中。一方面由于團隊習慣，契約一直是服務提供方給出，另一方面又希望保留消費者驅動特性，從而保障服務方能滿足所有消費方需求。我們選擇了在提供方生成契約，但是通過線上日志和調(diào)用鏈解析的方式來補充模擬消費端契約case。且整個過程全自動化。

5.2.4 契約測試技術實現(xiàn)
第一步：引入swagger推動全接口接入，保障接口管理平臺的接口文檔信息與實際代碼達到準實時同步，詳細的實現(xiàn)步驟如下；

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

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

5.3 問題智能定位降低自動化維護成本

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

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

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

6.1 發(fā)布困境

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

如何解決以上問題？

6.2 多平臺部署引擎

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

6.3 發(fā)布劇本設計

有了統(tǒng)一的發(fā)布平臺之后，為了解決上線過程復雜低效的問題，我們希望實現(xiàn)完全自動化的發(fā)布過程。
分析發(fā)布前后需要進行的事項，如下做圖所示。基于這些事項，梳理了要自動完成整個發(fā)布過程需要收集的數(shù)據(jù)，如右圖所示，包含發(fā)布模塊封板信息、依賴信息、配置信息等等。基于這些數(shù)據(jù)，根據(jù)固定的編排邏輯，自動生成服務發(fā)布拓撲以及本次上線步驟。生成的上線拓撲和步驟信息經(jīng)人工確認之后，自動調(diào)用對應上線發(fā)布服務進行發(fā)布，并針對發(fā)布過程數(shù)據(jù)自動統(tǒng)計，生成發(fā)布過程總結。

6.4 過程可視、可感知、可控的一鍵發(fā)布

有了自動化分發(fā)布過程之后，為了能夠及時感知發(fā)布過程中的問題，降低發(fā)布風險，進行了發(fā)布過程可視化建設，并與APM、金絲雀發(fā)布等策略結合，保障發(fā)布的安全。
發(fā)布過程可視：服務粒度的依賴拓撲已經(jīng)實時上線進度展現(xiàn)、過程可視可感知；

金絲雀發(fā)布策略：發(fā)布無損、風險及時感知并召回

七、整體收益

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

八、未來展望

1、通過IDE本地插件工具，賦能開發(fā)編碼測試過程，提升研發(fā)環(huán)節(jié)效能；
2、通過白盒能力，構建質(zhì)量風險識別體系，應用于準入、準出、灰度等場景；

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

點擊進入了解更多技術資訊~~

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

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

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