夜色av无码av,中国老年人A毛片视频,中文字幕在线观看免费,国产探花视频网站,天天躁日日躁狠狠很躁,三级片99,日本乱伦中文字幕,乌克兰一级操逼片

點擊上方“服務(wù)端思維”，選擇“設(shè)為星標(biāo)”

回復(fù)”669“獲取獨家整理的精選資料集

回復(fù)”加群“加入全國服務(wù)端高端社群「后端圈」

作者 | 烏拉

出品?| 愛番番技術(shù)

全文約6100字，預(yù)計閱讀時間15分鐘

導(dǎo)讀

隨著虛擬化技術(shù)的成熟和分布式框架的普及，在容器技術(shù)、可持續(xù)交付、編排系統(tǒng)等開源社區(qū)的推動下，以及微服務(wù)等開發(fā)理念的帶動下，應(yīng)用上云已經(jīng)是不可逆轉(zhuǎn)的趨勢。

微服務(wù)架構(gòu)下服務(wù)數(shù)量爆炸式增長，對應(yīng)的交付基建工作量暴增，且服務(wù)間拓?fù)鋸?fù)雜，又導(dǎo)致了升級影響難評估、問題定位困難、單獨測試環(huán)境成本極高等問題給高效能交付帶來了極大挑戰(zhàn)。另一方面，云原生帶來了標(biāo)準(zhǔn)化、松耦合、易觀測、易擴展的特性，為交付基建與業(yè)務(wù)解耦、更靈活的環(huán)境管理和、無損發(fā)布帶來新機遇。

愛番番產(chǎn)品從 20 年 4 月全面云化，在云化時代，我們?nèi)绾慰朔鲜鲂芴魬?zhàn)，同時利用云原生的技術(shù)紅利實現(xiàn)產(chǎn)品的高效能交付呢？

1. 微服務(wù)架構(gòu)下效能體系面臨的挑戰(zhàn)

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

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

團隊以業(yè)務(wù)領(lǐng)域劃分的多個?scrumTeam，如下圖：

團隊持續(xù)交付面臨的挑戰(zhàn)：

服務(wù)爆炸導(dǎo)致的基礎(chǔ)設(shè)施成本劇增。活躍模塊數(shù) 200+，月均新增模塊 8個，每個模塊需要接入的基礎(chǔ)設(shè)施如下圖，導(dǎo)致需要大量人力進行流水線、監(jiān)控等基礎(chǔ)設(shè)施接入管理維護。
復(fù)雜拓?fù)鋵?dǎo)致的問題定位困難和回歸范圍難以評估。服務(wù)間拓?fù)鋸?fù)雜，導(dǎo)致升級影響難評估、回歸漏測多、線上問題定位困難、環(huán)境規(guī)模龐大，聯(lián)調(diào)測試成本高等問題。
越來越高頻的發(fā)布需求和隨拓?fù)鋸?fù)雜度提升的發(fā)布成本的矛盾。模塊眾多且復(fù)雜拓?fù)洌夷K間上線有依賴關(guān)系，每次上線 100+ 模塊，人工控制流程，風(fēng)險高而且效率越發(fā)低下，但業(yè)務(wù)上發(fā)布的需求愈發(fā)頻繁，在高頻次的發(fā)布下，如何保障發(fā)布過程的高效、安全也是一項極大的挑戰(zhàn)。

2. 云原生架構(gòu)下的持續(xù)交付實踐

為實現(xiàn)團隊高效的價值交付，我們從敏捷機制改進和全流程持續(xù)交付能力提升兩方面開展了建設(shè)：

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

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

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

基礎(chǔ)設(shè)施：建設(shè)與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施服務(wù)，解決服務(wù)爆炸帶來的成本問題。
自動化：微服務(wù)下合理分層自動化體系，可控投入下保障有效質(zhì)量召回，解決復(fù)雜拓?fù)鋷淼幕貧w漏測問題。
發(fā)布能力：一鍵操作高效執(zhí)行、過程可視、可感知、可控的極致發(fā)布體驗，解決高頻發(fā)布需求下的發(fā)布成本問題。
工具賦能：豐富的工具能力賦能研發(fā)測試各效能痛點環(huán)節(jié)，為人員賦能（建設(shè)中，本文暫不詳細(xì)介紹）。

下面主要從技術(shù)層面的 3個方向逐一進行方案說明。

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

什么是與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施？

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

上文已經(jīng)提到，基礎(chǔ)設(shè)施面臨的最大問題是，由于爆炸的服務(wù)個數(shù)帶來的暴增的 Devops 基礎(chǔ)設(shè)施接入和維護成本問題。如果能打造服務(wù)化的基礎(chǔ)設(shè)施，就可以實現(xiàn)基礎(chǔ)設(shè)施的 0 成本接入和運維。那么如何打造與業(yè)務(wù)解耦，服務(wù)化的基礎(chǔ)設(shè)施呢？

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

與業(yè)務(wù)解耦的第一步是基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)化，只有標(biāo)準(zhǔn)化的過程才有可能規(guī)模化，從而實現(xiàn)技術(shù)設(shè)施服務(wù)化。我們主要針對以下幾部分內(nèi)容進行了標(biāo)準(zhǔn)化改造：

模塊標(biāo)準(zhǔn)化：代碼結(jié)構(gòu)、打包流程、標(biāo)準(zhǔn)容器、鏡像管理、部署過程。

標(biāo)準(zhǔn)流水線

標(biāo)準(zhǔn)的基礎(chǔ)服務(wù)：APM組件、配置中心、發(fā)布平臺、資源管理。

研發(fā)模式：

2.1.2 聲明式基礎(chǔ)設(shè)施

與業(yè)務(wù)解耦的第二步，是基于標(biāo)準(zhǔn)化的基礎(chǔ)上，建立聲明式的基礎(chǔ)設(shè)施能力。這里的聲明式是指給業(yè)務(wù)團隊聲明式的基礎(chǔ)設(shè)施體驗。業(yè)務(wù)團隊只需要在標(biāo)準(zhǔn)配置中聲明一些基礎(chǔ)屬性，即可自動完成所有基礎(chǔ)設(shè)施的接入，且后續(xù)維護上業(yè)務(wù) 0 成本。主要分為兩個環(huán)節(jié)的建設(shè)：

接入時：分鐘級的一鍵接入

我們的做法是通過腳手架為抓手來構(gòu)建基礎(chǔ)設(shè)施的一鍵接入能力。如下圖所示：

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

腳手架是我們這邊新模塊創(chuàng)建的入口。所有新代碼庫都是通過腳手架創(chuàng)建，他會幫助開發(fā)自動生成一整套集成了標(biāo)準(zhǔn)組件的代碼框架。

在腳手架創(chuàng)建新模塊的時候，根據(jù)業(yè)務(wù)聲明的模塊屬性，如是否接入 apm、模塊代碼類型、模塊服務(wù)類型等等自動完流水線創(chuàng)建、基礎(chǔ)組件接入、集群環(huán)境申請、配置文件生成等操作。一個新的服務(wù)，從創(chuàng)建代碼庫到服務(wù)全套基礎(chǔ)設(shè)施接入完成，服務(wù)可直接部署到測試集群的時間< 10 分鐘。

運行時：根據(jù)服務(wù)聲明內(nèi)容動態(tài)運行，實現(xiàn)業(yè)務(wù)升級維護0成本

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

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

與業(yè)務(wù)解耦的第三步，通過智能化的策略能力，實現(xiàn)高穩(wěn)定的基礎(chǔ)設(shè)施服務(wù)。

服務(wù)化之后，基礎(chǔ)設(shè)施作為獨立運維的服務(wù)，所有的問題都需要設(shè)施團隊獨立維護排查，所以與業(yè)務(wù)解耦的第三步就是建立高穩(wěn)定高效低運維成本的基礎(chǔ)設(shè)施能力。我們的思路是通過智能化的策略，來保障高效和穩(wěn)定。在流水線運行的前中后通過策略給流水線增加一個”監(jiān)工”，模擬人工判斷任務(wù)是否應(yīng)該執(zhí)行，模擬人工分析跟進、修復(fù)問題等。

分析常見的流水線穩(wěn)定和效率問題比如環(huán)境不穩(wěn)定、底層資源不穩(wěn)定、網(wǎng)絡(luò)異常等等，大體可分為偶發(fā)問題重試可恢復(fù)、問題相對復(fù)雜需人工排查、阻塞問題需人工修復(fù)三類。而效率方面大量重復(fù)、無效任務(wù)比如只加了個 log 也要跑全套測試流程，導(dǎo)致了資源浪費，也導(dǎo)致了執(zhí)行效率低下。如下圖左側(cè)所示：

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

典型場景：

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

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

2.1.4?與業(yè)務(wù)解耦的基礎(chǔ)設(shè)施帶來的收益

成本：模版創(chuàng)建&維護流水線 1000+，降低創(chuàng)建和維護成本 90%。

穩(wěn)定：流水線整體穩(wěn)定性從 85% 提升到 95%，工具鏈穩(wěn)定性從 95% 提升到 99%。

效率：代碼提交到部署完成 80 分位時間從 30+ 分鐘降低到 10 分鐘。

2.2 自動化：分層自動化體系

解決了服務(wù)暴增的問題，下面我們來看復(fù)雜拓?fù)湎碌幕貧w漏測問題。通常情況下解決回歸的質(zhì)量和效率問題，都會想到自動化測試。但是云原生微服務(wù)架構(gòu)下，什么樣的分層自動化體系，可以既保障召回，又不引入過多的自動化建設(shè)和維護成本呢？和傳統(tǒng) 3 層金字塔自動化不一樣，云原生架構(gòu)下的自動化，由于服務(wù)內(nèi)部相對簡單，而服務(wù)拓?fù)鋸?fù)雜，所以測試的重點是在系統(tǒng)端到端測試，實際的分層測試的比重更像一個倒過來的金字塔。

而由于端到端成本過高,考慮到投入產(chǎn)出比，愛番番的分層自動化是按照右下角這個結(jié)構(gòu)來建設(shè)的，其中接口 DIFF 測試、契約測試、純前端 DIFF 測試是無人工介入，最核心的三個部分。下面會就接口 DIFF 自動化測試和契約測試方案進行說明。

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

2.2.1.1?全鏈路灰度方案

我們接口的 DIFF 測試是基于強大的全鏈路灰度環(huán)境能力來建設(shè)的，這是云原生架構(gòu)給我們帶來的紅利。先介紹下我們的全鏈路灰度方案。

我們是基于 istio 的靈活的路由能力，通過同構(gòu)底層「分組多維路由」的架構(gòu)設(shè)計，自研 CRD Operator 構(gòu)建愛番番的「全鏈路灰度發(fā)布」平臺。該方案支持了我們的線下多路復(fù)用環(huán)境、線上安全的容量評估以及金絲雀發(fā)布等多個場景。

2.2.1.2?測試環(huán)境多路復(fù)用

測試環(huán)境多路復(fù)用是指，使用有限的資源，在一套基礎(chǔ)環(huán)境上邏輯隔離出多套環(huán)境，支持并行開發(fā)、聯(lián)調(diào)的需求。

如下圖所示，不同的分支對應(yīng)著不同的 feature，通過流量染色 + 流量規(guī)則路由的方式，使得不同分支擁有邏輯上隔離的環(huán)境，支持并行開發(fā)。在前端給流量打上橘色標(biāo)記之后，全鏈路的請求會走橘色的鏈路進行訪問。

2.2.1.3?基于多路復(fù)用的 DIFF 測試

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

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

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

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

2.2.2.1?什么是契約測試

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

以上問題的本質(zhì)原因為：

服務(wù)提供方服務(wù)的消費者越來越多的情況下，服務(wù)的變更影響難以評估，服務(wù)的變更也不能及時同步到所有消費者，所以往往是消費方發(fā)現(xiàn)問題了反饋，導(dǎo)致?lián)p失。為了避免上述問題，我們引入了契約測試。

契約測試的核心思路是通過消費者驅(qū)動的方式，建立服務(wù)端和各個消費端之前的契約，在服務(wù)端有修改之后，通過測試和所有消費方之前的契約是否被毀壞來保障服務(wù)升級的安全性。同時，契約也可以作為雙方測試解耦的手段。通過契約測試，團隊能以一種離線的方式 ( 不需要消費者、提供者同時在線 )，通過契約作為中間的標(biāo)準(zhǔn)，驗證提供者提供的內(nèi)容是否滿足消費者的期望。

2.2.2.2?常見的契約測試方案

常見的契約測試方案有真正實踐消費者驅(qū)動的如 pact，契約由消費端生成并維護，提供方代碼更新之后，拉取所有消費方契約進行測試，即解決了集成測試解耦問題，又保障了服務(wù)方能滿足所有消費方需求。（下左圖）

也有非消費者驅(qū)動，提供方生產(chǎn)契約，并提供 mock 服務(wù)，消費方可以基于契約文件測試，如Spring Cloud Contract。只能解決集成測試解耦的問題。（下右圖）

2.2.2.3?愛番番的契約測試方案

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

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

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

我們會在自動化 case 運行失敗后，調(diào)用自動定位服務(wù)，自動對失敗的 case 進行標(biāo)注，根據(jù)標(biāo)注結(jié)果會對失敗 case 進行分類處理。

比如，環(huán)境問題會自動重試，批量未知會發(fā)送到自動化小組進行排查，元素找不到會發(fā)送到業(yè)務(wù) QA 排查。

以下是實現(xiàn)的方案。包含基礎(chǔ)定位能力和基礎(chǔ)數(shù)據(jù)獲取。在這些基礎(chǔ)能力之上，建設(shè)了配置層，實現(xiàn)配置解析和調(diào)度能力，讓我們可以通過配置的方式，靈活組合不同的定位策略快速支持不同場景的問題定位。

2.3 發(fā)布能力：高效安全的持續(xù)發(fā)布

2.3.1?發(fā)布困境

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

如何解決以上問題？

2.3.2?多平臺部署引擎

首先是基于云原生構(gòu)建多平臺統(tǒng)一的部署與發(fā)布引擎，無縫集成 CICD，實現(xiàn)發(fā)布過程的高度標(biāo)準(zhǔn)化，同時支持多種發(fā)布策略。如下圖：

通過 CD 發(fā)布平臺的統(tǒng)一，實現(xiàn)各類型模塊統(tǒng)一發(fā)布，且底層部署遷移業(yè)務(wù)無感知。

2.3.3?發(fā)布劇本設(shè)計

有了統(tǒng)一的發(fā)布平臺之后，為了解決上線過程復(fù)雜低效的問題，我們希望實現(xiàn)完全自動化的發(fā)布過程。

分析發(fā)布前后需要進行的事項，如下圖所示。基于這些事項，梳理了要自動完成整個發(fā)布過程需要收集的數(shù)據(jù)，如右圖所示，包含發(fā)布模塊封板信息、依賴信息、配置信息等等。基于這些數(shù)據(jù)，根據(jù)固定的編排邏輯，自動生成服務(wù)發(fā)布拓?fù)湟约氨敬紊暇€步驟。生成的上線拓?fù)浜筒襟E信息經(jīng)人工確認(rèn)之后，自動調(diào)用對應(yīng)上線發(fā)布服務(wù)進行發(fā)布，并針對發(fā)布過程數(shù)據(jù)自動統(tǒng)計，生成發(fā)布過程總結(jié)。