作者 | 王悅凱

導讀

從事B端業(yè)務系統(tǒng)研發(fā)多年，不免會有這樣的思考：B端系統(tǒng)的技術挑戰(zhàn)是什么？什么樣的業(yè)務架構算好架構？本文結合百度合約廣告業(yè)務的發(fā)展歷程，介紹廣告投放平臺從單體架構到微服務架構演進過程中碰到的問題和思考。希望通過本文的介紹，讓大家更全面的理解B端系統(tǒng)的技術挑戰(zhàn)。

全文11653字，預計閱讀時間30分鐘。

一、背景

1.1 合約廣告概念

合約廣告相比競價廣告，最大的特點是預先約定好廣告價格，即價格是預先確定的。基于這樣的特點，合約廣告的投放流程大致可以概括為四個步驟：詢價 -> 下單 -> 投放 -> 結算。

1. 詢價，銷售根據(jù)客戶的營銷目標選擇合適的營銷產(chǎn)品，并提交具體的投放定向和時長，系統(tǒng)結合銷售政策，自動計算產(chǎn)出各資源價格

2. 下單，客戶按照 1 中的報價結果，確認需要購買的資源和具體的付款方式，完成下單后生成訂單，每個訂單的金額是確認的

3. 投放，2 中的訂單完成審批后，系統(tǒng)按照事先約定的價格進行廣告投放，客戶在投中可通過系統(tǒng)進行投放和創(chuàng)意的管理，并可以實時獲取投放數(shù)據(jù)

4. 結算，合約廣告按照投放模式分為按時間計費和展現(xiàn)量計費，兩種計費方式的頻次都是天，最終實現(xiàn)在投放周期內逐步地扣除訂單全部金額。按天結算是對已產(chǎn)生投放部分的權益保障，畢竟合約廣告存在更改甚至退款的場景。

通常來說，合約廣告這種廣告采買方式更適合品牌展示類廣告，效果類廣告更多會采用實時競價。相比競價廣告，合約廣告在業(yè)務流程上更重投前。下面結合品牌廣告業(yè)務發(fā)展的三個階段，介紹下投放平臺的變化歷程。

1.2 業(yè)務發(fā)展

第一階段，品牌廣告業(yè)務高速發(fā)展期

2011年，品牌專區(qū)產(chǎn)品開始平臺化售賣，并逐步建立品牌投放平臺：錦囊。在2013-2018 6年間，品牌業(yè)務高速發(fā)展，誕生了Ax、Bx、Cx等10+條產(chǎn)品線，雖然錦囊平臺做為投放的統(tǒng)一入口，但各產(chǎn)品線的投放能力仍舊是獨立建設，擁有各自的獨立投放平臺。在這種模式下，快速靈活地應對了市場的變化和需求，但同時也造成了投放平臺多，業(yè)務流程割裂的問題。

第二階段，尋求產(chǎn)品整合和流程統(tǒng)一

2019年開始嘗試對合約類平臺進行整合，統(tǒng)一各產(chǎn)品售賣流程，包括產(chǎn)品線關停并轉、投放平臺融合、賬戶統(tǒng)一、資金池統(tǒng)一、標準化下單等項目。逐步落地合約廣告一站式平臺的建設 - 天啟平臺，真正實現(xiàn)合約廣告的標準化投放流程，提升規(guī)模化投放效率，支撐業(yè)務發(fā)展。在這個階段，各廣告的投放平臺入口逐步收斂，實現(xiàn)了操作入口的統(tǒng)一。

第三階段，滿足復雜營銷場景，整合營銷

隨著合約整合售賣（根據(jù)營銷場景選擇不同廣告產(chǎn)品的組合售賣方案，即同一個合同下可下單多類廣告，并享有對應的優(yōu)惠政策）整體趨勢的加速增長，原本非標斷點式的支持方式已經(jīng)無法滿足業(yè)務的增長，平臺化的解決方案是整合售賣規(guī)?；谋匾獥l件。從2021年Q3起正式啟動，天啟平臺正式定位：統(tǒng)一的合約產(chǎn)品整合售賣平臺，滿足從簡單場景到復雜營銷場景的全投放鏈路服務能力。從技術視角看，旨在通過一個平臺（天啟），實現(xiàn)多資源廣告售賣場景下的統(tǒng)一，包括一個流程、一套賬戶、一套資金體系、一套投放表達。

1.3 架構演進

對應上述業(yè)務發(fā)展的三個階段，合約平臺的技術架構也經(jīng)歷了多個版本的演進，濃縮后，可以概括為2大類，2019年前的單體架構和之后的微服務架構。

單體架構

2019年前的單體架構（簡稱『1.0架構』）圖如下所示，整體上分三層，1）統(tǒng)一入口層，提供用戶權限管理功能；2）各類廣告投放平臺獨立建設，服務獨立部署；3）抽象并沉淀基礎工具庫，避免各投放平臺的重復開發(fā)。

△1.0 煙囪式架構

品牌 1.0 架構本質是一個煙囪式架構，各產(chǎn)品線通過獨立平臺進行投放，開發(fā)、測試、上線互不影響，都能做到產(chǎn)品線維度的隔離，包括開發(fā)規(guī)范和迭代周期。這種架構配合當時品牌團隊的組織架構，在品牌產(chǎn)品野蠻式生長的初期起到了很重要的作用，成功孵化了一些創(chuàng)新產(chǎn)品。但是煙囪式架構一個很大的弊端就是『信息孤島』，隨著業(yè)務的發(fā)展，各投放平臺發(fā)散式迭代，逐步形成了一個一個的孤島。從技術視角看，各平臺大流程相似，但在實現(xiàn)細節(jié)上都不同，更嚴重的是，存在大量的重復性建設工作，從維護成本和人效上都有很大的優(yōu)化空間。從業(yè)務視角看，各產(chǎn)品的打法也是各自為陣，橫向缺少聯(lián)動，沒有形成1+1>2的局面，缺少整體視角的規(guī)劃。

微服務架構

業(yè)務方面，合約廣告場景化營銷和精細化服務的需求顯著；團隊方面，各合約類廣告平臺深度融合，孤島邊界逐步打破。原本煙囪式架構無論在業(yè)務復雜度的應對，還是服務穩(wěn)定性及質量的保障，亦或是研發(fā)效能的提升，都已經(jīng)遇到了瓶頸?；谲浖O計的最大目標：『設計符合業(yè)務的構造定律的演進方式，一種可以以最小的開發(fā)維護成本， 使業(yè)務更快更好的流動發(fā)展的方式』，19年后，合約平臺架構逐步向微服務架構演進，以領域驅動設計為準則，按照合約廣告的領域模型劃分微服務，構建了業(yè)務前臺、業(yè)務中臺、技術組件、基礎設施的四層業(yè)務架構。另外，基于消息機制解耦各服務，輔以組裝式業(yè)務流程的理念，拆解各種繁雜的業(yè)務流程，抽象并沉淀系統(tǒng)的 meta feature，靈活構造多種差異化的業(yè)務解決方案，提升系統(tǒng)的『可玩性』，從架構層面管理了系統(tǒng)風險和業(yè)務復雜度（百級別不同類型的售賣和投放場景）。

說到這，有些人會有疑問，對于品牌業(yè)務，微服務架構演進是否是必須的呢？是否存在過度設計？

當然，假如不考慮性能、健壯性、可移植性、可修改性、開發(fā)成本、時間約束等因素，用任何的架構、任何的方法，系統(tǒng)的功能總是可以實現(xiàn)的，項目總是能開發(fā)完成的，只是開發(fā)時間、以后的維護成本、功能擴展的容易程度不同。從后驗來看（包括系統(tǒng)可用性、擴展性、靈活性三方面），采用微服務架構的決策是正確的，或者說利遠大于弊。

在架構的演進過程中遇到了很多技術挑戰(zhàn)，后面的內容重點挑了幾個方面進行詳細闡述。

二、技術實現(xiàn)

2.1 服務架構

首先，整體看下合約廣告平臺的微服務架構，如下圖：

△合約廣告平臺微服務架構

總共分為四層，業(yè)務前臺、業(yè)務中臺、技術組件（PAAS）、基礎設施（IAAS）。

1. 業(yè)務前臺，總共分三個模塊，天啟平臺、運營平臺、業(yè)務前臺。

• 天啟平臺：面向廣告主，提供合約廣告詢價、資源預訂、資源下單、投放設置、物料制作等核心能力，支持品專矩陣、展示矩陣、品牌全景3大類產(chǎn)品矩陣，多達300+廣告資源的售賣。

• 運營平臺：面向銷售和內部運營，幫助他們精細化運營廣告售賣各階段，目前售中的投放干預和運營管控能力建設相對完善，在開屏大促和品牌廣告日常運營工作中大幅提升操作的效率和安全性，讓原本一些『非標』操作通過平臺能力讓運營實現(xiàn)自助化。

• 業(yè)務前臺：主要兩個作用，1）對天啟平臺和運營平臺的公共部分進行抽象并下沉，避免重復的業(yè)務邏輯和流程散布在兩個模塊，減少開發(fā)和運維成本；2) 對各業(yè)務中臺的公共部分進行上抽，統(tǒng)一沉淀至此模塊，比如批量處理，讓各業(yè)務中臺的職責更加純粹，關注自己領域的建模。另外，針對跨多中臺的讀寫邏輯也統(tǒng)一在這一層實現(xiàn)，起到業(yè)務流程編排的作用。

2. 業(yè)務中臺，按照合約廣告的業(yè)務流程和領域知識，劃分各業(yè)務服務，總共分為9個業(yè)務中心和2個技術中心，每個業(yè)務中心都圍繞特定的業(yè)務領域展開，業(yè)務邊界非常明確。需要注意的是，9大業(yè)務中心僅僅是從業(yè)務視角進行定義和劃分，并不代表每個中心就只有一個服務。基于技術架構和業(yè)務職責，每個業(yè)務中心可以繼續(xù)劃分為多個模塊，例如投放中心又被劃分為 檢索適配服務、物料審核服務、實驗投放服務等。另外，服務之間嚴格劃定上下游關系（按照響應數(shù)據(jù)流向定義上下游概念），下游服務可以調用上游服務，上游服務嚴禁調用下游服務，上游服務的變更對下游服務產(chǎn)生影響必須通過領域事件（異步）的方式來實現(xiàn)，避免服務循環(huán)依賴（在服務治理章節(jié)中會展開介紹）。因此在整體系統(tǒng)中大量采用異步消息的方式，將業(yè)務實體的狀態(tài)變更視為事件，驅動上游服務，雖然增加了測試階段的復雜度，但是有效保障了服務間關系的有序性。

3. 技術組件，微服務架構后，各模塊的代碼庫也是獨立的，對于一些公共能力，如何能夠讓各服務低成本、無門檻的接入，從而達到統(tǒng)一各模塊業(yè)務解決方案的目標，減緩業(yè)務架構的腐化和熵增。鑒于此，通過 springboot starter 的方式構建了品牌團隊的業(yè)務中間件 brand-starters，成功收斂了30+模塊的實現(xiàn)細節(jié)，在系統(tǒng)穩(wěn)定性和架構健康度方面做出巨大貢獻，包括消息發(fā)送和消費、異步事件處理、異常報警、分布式鎖、分級緩存、常用工具及輔助類等。

4. 基礎設施，主要指部門級別的基礎設施和中臺，比如微服務解決方案 ，包括RPC框架、注冊中心、全鏈路追蹤、服務網(wǎng)關、虛擬化容器部署、FAAS。

2.2 模塊結構

上一節(jié)從整體視角介紹了合約廣告平臺的業(yè)務架構，這節(jié)從微觀視角介紹每個中臺的業(yè)務架構。各業(yè)務中臺采用多模塊的代碼結構，具體模塊劃分如下：

各模塊的依賴關系如下：

△模塊結構

值得注意的是：

1. 各模塊間的依賴關系，demo-web、demo-task、demo-consumer 做為頂層模塊，非常薄，這一層的主要作用是獨立發(fā)布及部署，實現(xiàn)應用級別的隔離。頂層模塊調用 demo-app，app模塊作為服務的實現(xiàn)，存放了各個業(yè)務的實現(xiàn)類，主要分command和query（CQRS 理念）。demo-app 可以調用 demo-domain，也可以調用基礎設施層 demo-infrastructure，domain做為領域層主要分3塊，model 領域實體，可以是充血模型（DDD的概念）；ability 領域能力，是領域對外暴露的服務能力；gateway 領域網(wǎng)關，主要是接口定義，這里的接口可以粗略的理解成一種SPI，也就是交給infrastructure層去實現(xiàn)的接口。

2. demo-client 是服務對外透出的 API，API 的實現(xiàn)存放于 demo-app 模塊。出于運維考慮，或者讀寫分離的設計，可以方便的將需要獨立部署的 API 從 app 模塊上抽至頂層，做為獨立模塊進行流水線發(fā)布和部署。實現(xiàn)服務的隔離部署，同時又能獲得共享同一個代碼庫的好處。

3. 前面提到的domain和infrastructure層的依賴倒置，是一個非常有用的設計，進一步解耦了取數(shù)邏輯的實現(xiàn)。domain層依賴接口，不感知具體實現(xiàn)，例如 CustomerGateway 里定義了接口 getByById，要求 infrastructure 的實現(xiàn)類必須定義如何通過消費者Id獲取消費者實體信息，而 infrastructure 層可以實現(xiàn)任何數(shù)據(jù)源邏輯，比如，從 MySQL 獲取，從 Redis 獲取，還是從外部 API 獲取等等。

4. 領域與功能的分包策略，每個模塊的分包策略都遵循準則：先按照領域分包，再按照功能分包，這樣做的其中一點好處是能將腐爛控制在該業(yè)務域內。比如消費者 customer 和訂單 order兩個領域，在 domain 模塊下先分成 customer 和 order 兩個包，然后再按照 model、ability、gateway 進行功能劃分。假設 customer 和 order 是兩個后端開發(fā)并行開發(fā)，兩個人對于 dto，util 這些文件夾的命名習慣都不同，那么只會腐爛在各自的業(yè)務包下面，而不會將 dto，util，config 等文件夾放在一起，極容易引發(fā)文件沖突。

通過上面的應用架構劃分，統(tǒng)一了各業(yè)務中臺的分模塊和分包策略，成功降低了各模塊的學習和上手成本，較好控制了業(yè)務架構和模塊代碼的腐化程度。同時通過頂層模塊的劃分，靈活實現(xiàn)了同一代碼庫多應用部署的能力，從物理層面隔離web服務、定時任務、消息消費、rpc服務，使服務具備靈活按需擴展的能力，進一步提升服務的穩(wěn)定性。

2.3 服務治理

微服務架構后，服務之間的交互通過網(wǎng)絡進行而非單體時代的內存方式，所以整體來說系統(tǒng)會變得更加脆弱，服務治理就是為了解決此類問題。常規(guī)的服務治理有四板斧：第一，一定要設置服務調用的超時時間；第二，要考慮重試的邏輯；第三，考慮熔斷的邏輯，不要被下游拖死；第四，一定要有限流的邏輯，不要被上游打死。即超時、重試、熔斷和限流。沒錯，這四板斧的確是服務治理中的常規(guī)手段，但在我看來，服務治理并不局限于此。我們以終為始，看看服務治理的終極目標是什么？我認為主要3個方面：服務可用性、系統(tǒng)可觀測、架構防腐化。

可用性

服務可用性的建設包括系統(tǒng)性能優(yōu)化、服務自愈和自檢能力建設。

服務性能

1.微服務框架升級

服務 RPC 框架整體遷移至部門最新的云原生解決方案 gravity+starlight，取代了原先的 zookeeper+stargate。在服務性能和治理方面有了大幅提升：

• 通信性能提升：starlight采用新版的網(wǎng)絡通信庫與更靈活的線程池模型。提升2倍通信交互性能

• 穩(wěn)定性增強：starlight基于gravity做更高效穩(wěn)定的注冊中心，定制無損升級、異常實例摘除等能力。輕松賦能達標99.99%+穩(wěn)定性。

• 跨語言能力：starlight采用設計更合理的brpc協(xié)議作為主協(xié)議，可跨語言與C++ Go等brpc服務通信。降低跨語言通信學習成本。

• 云原生治理：starlight+gravity支持更云原生的治理能力，接入統(tǒng)一控制中心增強可控性、實現(xiàn)灰度發(fā)布。

• 日志規(guī)范排查提速：規(guī)范化的日志。秒級定位超時問題、序列化失敗問題

遷移過程中，gravity 與 zk 雙向同步服務注冊信息，實現(xiàn)業(yè)務的平滑無感遷移。

2.系統(tǒng)性能深度優(yōu)化

對合約廣告系統(tǒng)進行了全面的性能盤點和優(yōu)化，性能整體提升2倍，總結為如下7個優(yōu)化點：

• 單元化，對單個服務進行拆分瘦身（模塊結構章節(jié)中提到的頂層模塊，將定時任務、消息消費與web服務剝離），實現(xiàn)資源隔離，降低等待獲取連接的耗時

• 網(wǎng)絡傳輸，統(tǒng)一團隊服務部署至北方機房，平響降低60%

• 循環(huán)IO，IO 包括遠程服務調用和數(shù)據(jù)庫操作，通過批量化改造、多線程并發(fā)的手段大幅縮短耗時

• 多級緩存，通過本地 + redis 構建二級緩存，大幅降低讀接口耗時

• 異步化，對于耗時的寫操作，采用eventlog組件實現(xiàn)異步化 + 自動重試（后面一節(jié)會詳細展開），例如物料送審、批量創(chuàng)建投放等

• 慢SQL，基于業(yè)務查詢場景，優(yōu)化數(shù)據(jù)表索引定義

• 接口拆分，聯(lián)合前端，對于非主干流程的耗時數(shù)據(jù)進行接口拆分，實現(xiàn)非阻塞請求

服務自愈和自檢

為了更好的保障系統(tǒng)的可用性，服務需要具備自愈和自檢能力。服務自愈能力主要通過冪等處理 + 事件持久化 + 邏輯重試來實現(xiàn)，通過自愈能力的建設，可以大幅降低微服務架構升級后帶來的 IO 通信不穩(wěn)定問題，同時讓系統(tǒng)對性能和穩(wěn)定性較差的外部服務有更好的容忍性，有效提升系統(tǒng)的整體可用性。系統(tǒng)的自愈能力主要解決的是『偶發(fā)性』技術問題，比如網(wǎng)絡抖動導致的遠程調用失敗、事務并發(fā)導致的樂觀鎖沖突等，對于代碼bug、業(yè)務邏輯錯誤、數(shù)據(jù)不一致等問題無能為力。所以除了自愈能力，服務還需要具備自檢能力，能夠將錯誤自動檢測出來，并及時通知到對應人員進行處理。

服務的冪等處理這里簡單提一下，不做過多展開，主要有幾種方案：

1. 數(shù)據(jù)庫唯一鍵，通過數(shù)據(jù)庫的約束實現(xiàn)新增和刪除操作的冪等。

2. 數(shù)據(jù)庫樂觀鎖，通過增加額外字段（版本號）實現(xiàn)更新操作的冪等。

3. 防重token令牌，調用方在調用接口的時候先向后端請求一個全局ID做為token，后續(xù)請求的時候都帶有此token（建議放到 Headers 中），可以解決客戶端連續(xù)點擊或者調用方超時重試等情況，適用于新增、更新和刪除操作

4. 下游傳遞唯一序列號，與3不同的是，這個唯一序列號由調用方生成，生成方式可以是無業(yè)務含義的全局ID，也可以是帶有業(yè)務含義的ID，比如訂單行ID。服務方通過此ID記錄進行存在和不存在的操作（結合redis實現(xiàn)操作的記錄），適用于新增、更新和刪除操作

自愈能力 - eventlog 基礎組件

利用 springboot-starter 機制沉淀 eventlog 基礎組件，讓業(yè)務方低成本接入，使服務具備自愈能力。組件整體架構圖如下：

△eventlog 基礎組件

步驟1是同步持久化事件，由業(yè)務方引入組件后調用現(xiàn)成方法實現(xiàn)；步驟2是異步消費處理事件，整體處理流程采用模板模式+ 策略模式，通過模板模式實現(xiàn)處理流程的業(yè)務編排，對事件處理前、中、后都設置擴展點，兼顧業(yè)務模塊的接入成本和擴展靈活度。事件處理采用策略模式，將事件類型做為策略路由，實現(xiàn)各類事件處理的互相隔離和高擴展性。另外通過可視化配置（amis配置，即愛速搭，低代碼前端頁面搭建平臺），統(tǒng)一監(jiān)控事件日志表，對超時處理的事件進行報警、清理等操作。

事件日志實體模型采用 event_type + biz_code 的二級模型，event_type 唯一標識了一類事件，是事件處理時的策略路由key，biz_code 由業(yè)務方自定義，用來唯一標識某類實體。attach是擴展字段，供業(yè)務方自定義，attach不宜過大，如果過大，建議通過biz_code后反查業(yè)務數(shù)據(jù)。

自檢能力 - 核檢中心

服務的自檢能力主要通過核檢中心來實現(xiàn)，核檢中心功能上分兩部分，核檢任務 + 消息中心。核檢任務按業(yè)務場景對數(shù)據(jù)進行核對校驗，解決微服務架構后分布式事務造成的數(shù)據(jù)不一致，同時，端到端的核檢也可以做為在線監(jiān)控，第一時間感知系統(tǒng)bug；然后通過消息中心將異常通知到對應人員。同時，面對大量的報警信息（系統(tǒng)錯誤、數(shù)據(jù)一致性、業(yè)務正確性等），消息中心做為統(tǒng)一的管理端，提供了按場景分組報警、歷史報警信息查詢、報警優(yōu)先級設定、誤報熱屏蔽、報警群進組熱修改等功能，提升監(jiān)控的有效性和處理效率。

核檢中心整體模塊圖如下：

△核檢中心模塊圖

• 應用層，兩塊主要功能，客戶端接入和可視化管理。

• 客戶端接入，對于 springboot 應用，和 eventlog 組件相同，通過引入starter，低成本實現(xiàn)報警消息的通知（聲明式注解和命令式sdk兩種方式）。

• 可視化管理，通過消息中心控制臺，將散布的核檢任務進行收攏，大幅提升日程維護效率。同時對于歷史消息，可以進行查詢，做到消息的可回溯和追蹤。

• 能力層，對應核檢中心服務端，整體模塊結構遵循上述提到的 COLA，并使用CQRS和事件驅動的設計理念，提升模塊的可用性。在消息發(fā)送事件的處理模塊中，采用策略模式實現(xiàn)多種類型的消息發(fā)送，大幅提升模塊擴展性，遵循開閉原則。

• 實體層，按照十億級別數(shù)據(jù)量進行模型設計和數(shù)據(jù)庫選型。在實體設計中，抽象消息場景的業(yè)務概念，較好的聚合了一類共同特征的消息，『共同特征』完全交由業(yè)務方定義，很好的平衡了業(yè)務靈活性和消息可管理。在數(shù)據(jù)庫選型方面，采用部門開源解決方案BaikalDB（一個分布式可擴展的HTAP存儲系統(tǒng)，采用類spanner的架構，支持PB級結構化數(shù)據(jù)的隨機實時讀寫）。

可觀測

系統(tǒng)的可觀測程度也是服務治理的一個非常重要目標。提到服務的可觀測性，大家容易想到的一般都是：微服務調用關系（拓撲圖呈現(xiàn)）、接口性能（各種分位值指標，性能優(yōu)化利器）、系統(tǒng)異常（各種監(jiān)控配置）、資源利用率、日志鏈路追蹤（線上排查必不可少）等，這部分主要依托于部門的微服務解決方案 Jarvis平臺實現(xiàn)，所以在這里不做過多介紹，這里主要想介紹的服務可觀測主要是指上層業(yè)務應用。

企業(yè)級微服務解決方案Jarvis是商業(yè)平臺部基礎技術團隊研發(fā)的面向復雜業(yè)務系統(tǒng)的應用托管平臺，為商業(yè)應用提供高可用和分布式的微服務架構解決方案。Jarvis提供了一系列強大的功能，充分利用百度資源虛擬化能力，提供分布式服務框架、服務治理、統(tǒng)一配置管理、分布式鏈路跟蹤、容量規(guī)劃、高可用及數(shù)據(jù)化運營等功能。

前面其實已經(jīng)提到過，合約廣告的整體業(yè)務鏈路比較長，經(jīng)歷了售前詢價 -> 下單 -> 合同審批 -> 物料制作 -> 投放 -> 計費，每個環(huán)節(jié)都可能成為廣告投放的卡點，如果出現(xiàn)問題，比如流程阻塞，如何能夠快速定位問題，甚至提前感知問題，做到整個流程的透明化、可觀測呢？

整體思路是以業(yè)務實體為中心，記錄實體全生命周期的變化，當某個階段（實體狀態(tài)）停留時間超出預期，就有可能存在潛在的異常，通過服務看板和消息中心，及時通知對應的運營進行處理跟進。通過追蹤業(yè)務實體的生命周期，實現(xiàn)系統(tǒng)業(yè)務流程的可觀測性，為后續(xù)流程優(yōu)化、業(yè)務提效提供數(shù)據(jù)分析基礎。

業(yè)務實體生命周期的追蹤實現(xiàn)方案主要如下圖：

△業(yè)務實體生命周期追蹤

總結來說就是三種方案：

1. 通過訂閱 mysql binlong，監(jiān)控業(yè)務實體的核心狀態(tài)字段（對應部門已有解決方案 WATT），一旦字段變更就會觸發(fā)增量消息，服務端消費后持久化，再以服務看板的形式對外呈現(xiàn)。這種方式的優(yōu)勢是對業(yè)務模塊無侵入，劣勢是依賴業(yè)務模塊的數(shù)據(jù)庫設計，另外有些實體的生命周期并不一定體現(xiàn)在數(shù)據(jù)表的字段變更，無法通過訂閱 binglog 的方式感知

2. 通過日志打印 -> 采集 -> 解析的方式實現(xiàn)實體全生命周期的追蹤。這個方式的優(yōu)勢是百度已有一整套現(xiàn)成的解決方案，可以直接復用；劣勢是需要侵入業(yè)務代碼，按照規(guī)范打印日志，同時日志采集和解析的配置門檻較高，調試較困難，不容易上手

3. 提供用于追蹤實體生命周期的埋點 sdk，在需要監(jiān)控的地方埋點。這個方式的優(yōu)勢是靈活度非常高，可以實現(xiàn)任何追蹤需求；劣勢是侵入業(yè)務代碼，需要業(yè)務模塊顯式進行調用

最終我們采用了 1 和 3，業(yè)務實體的追蹤主要通過方案 3來實現(xiàn)埋點，一些額外輔助信息通過 方案 1 進行同步。

防腐化

很多科學家提到的熵增定律非常好的揭示了自然現(xiàn)象的本質：任何孤立系統(tǒng)，在沒有外力作用的情況下，其總混亂度（熵）會不斷增大。當然軟件系統(tǒng)也是如此，隨著軟件系統(tǒng)的功能不斷增加，系統(tǒng)的混亂度也在不斷增大。為了降低軟件系統(tǒng)混亂的速度，必須要對其施以外力。那么這里的『外力』可以從哪些角度入手呢？

1. 分析每個應用的修改頻次，哪些應用頻繁修改，哪些應用相對穩(wěn)定。對于頻繁修改的應用，是否引起修改的業(yè)務需求是相同的。那么這些大概率綁定在一起修改的服務被拆分在不同的應用，是否是不合理的，值得進一步商榷。如果一個應用，無論什么需求都需要升級，那么這個應用是否已經(jīng)足夠小，是否需要進一步拆分，剝離變與不變，將不變的部分進行抽離和沉淀？

2. 定期觀察每個服務的調用情況，包括次數(shù)、性能和拓撲。是否存在一些冗余服務可以清理？是否存在一些服務性能呈現(xiàn)惡化趨勢，需要及時介入優(yōu)化？是否存在某些業(yè)務流程中存在重復調用的情況？如果有，需要制定計劃進行治理，否則就會成立歷史債務，讓業(yè)務架構逐步腐化。

3. 需要定期去掃描檢查應用代碼，包括重復邏輯是否散布于多個應用、是否存在不規(guī)范的代碼邏輯（每個團隊根據(jù)實踐總結沉淀，比如 枚舉類的使用、IO 循環(huán)調用等）、是否存在冗余代碼需要清理、模塊結構和分包策略是否符合規(guī)范

4. 定期的CR各應用代碼，是否存在跨領域的邏輯，比如報價中心處理了訂單中心的邏輯（非報價域的邏輯），導致微服務的劃分邊界模糊

防腐化這塊工作其實很重要，目前也還處于初級的摸索階段，需要進一步結合業(yè)務實際，沉淀最佳實踐。這里先以微服務循環(huán)依賴治理為例，做個簡單介紹。

當微服務中的循環(huán)依賴形成閉環(huán)后會造成2類主要危害：

1. 服務間強耦合導致各服務很難獨立部署，違反了微服務『自治與隔離』的設計初衷，最終微服務架構會逐步演變?yōu)椤悍植际酱髥误w』，失去了微服務架構演進的意義。

2. 循環(huán)依賴可能會導致一些循環(huán)調用或并發(fā)問題，造成一些復雜難以定位的問題，下面以用戶中心和訂單中心為例來說明

△循環(huán)依賴導致的并發(fā)問題

上述圖中有兩個服務，訂單和用戶中心，藍色箭頭表示訂單中心對外提供的服務 ，實現(xiàn)訂單狀態(tài)更新，其中會調用用戶服務更新客戶狀態(tài)，標記此客戶已有下單記錄。紅色箭頭表示用戶中心調用訂單中心，用戶服務在標記完客戶狀態(tài)后反過來會調用訂單服務，持久化訂單上客戶信息。上述調用形成了閉環(huán)，最終會引起訂單數(shù)據(jù)庫中的版本沖突，導致更新失敗。那么如何避免這種循環(huán)依賴呢？總結以下幾個準則：

1. 明確服務邊界和定位，劃分上下游服務，下游服務可以調用上游服務，但是上游服務不能依賴下游，如果要進行通信，采用領域事件的方式，比如消息通知。

2. 數(shù)據(jù)不要過多冗余，盡量通過數(shù)據(jù) id（能夠唯一代表數(shù)據(jù)且不變的屬性）來進行關聯(lián)，即只存引用。

3. 如果存在必須要通過上游服務同步調用下游服務才能完成的功能，得反思是否上游服務缺少了相應的業(yè)務域。如果不是，可以借業(yè)務前臺來實現(xiàn)各服務的調用編排，或者肯能存在微服務拆分不合理，這種場景需要重新規(guī)劃，拆分出一個更上游的服務供調用。

回到剛才的實際例子，治理方案是采用領域事件的改造方式，訂單服務是下游服務，用戶服務是上游服務，用戶服務更新訂單客戶信息從同步調用方式改為消息通知，不感知具體的訂閱方，實現(xiàn)解耦。

2.4 服務迭代

微服務架構改造后，原來單體架構的迭代方式已經(jīng)不再適用，我們看一個實際例子：

從上述例子中可以看到，微服務架構后，一個業(yè)務需求會涉及多個模塊，復雜度不盡相同，如果中臺服務的每個升級無法做到向前兼容，那么勢必會導致需求間的耦合，一旦并行開發(fā)的分支增多，因模塊間的耦合導致的整體回滾概率將會指數(shù)級增長。仍舊是上述這個例子，如果需求1中的中臺B有BUG，需要回滾，那么是否導致需求2中的所有模塊都要回滾，包括中臺D，即使它的改動點非常小。

總結以下，造成上述局面的2個主要原因：

1. 迭代升級的視角只有需求維度，中臺服務被割裂，缺少另一個以中臺為主的視角

2. 自動化測試能力不足，過度依賴黑盒測試會導致風險后置

針對這兩個問題，我們的解法主要有3個方向：

1. 規(guī)范需求迭代流程，強化以中臺為軸的虛擬團隊。

2. 從需求評審、技術詳設、開發(fā)、聯(lián)調、測試到上線，制定詳細的全流程規(guī)范，保障團隊有序運轉。同時，強調各中臺的自治，迭代升級必須做到向前兼容，依賴模塊的回滾不影響自身的上線計劃，反復強調容錯、兼容、演進式的設計理念。

3. 加強自動化測試能力，達到自動準出標準。自動化測試能力包括各模塊的單測和集成測試。模塊單測通過插件集成至流水線，對于沒有達到覆蓋率的代碼禁止合入，特殊情況下，可以說明理由，讓模塊負責人豁免。集成測試從業(yè)務前臺出發(fā)，按照業(yè)務場景優(yōu)先級逐步建設，觸發(fā)方式分為每日例行任務和回歸測試時的手動觸發(fā)。

4. 提供服務 mock 能力，在合適的場景下可以解耦對其他服務的依賴。落地聯(lián)調中心，實現(xiàn)服務級別的動態(tài) mock 能力，并通過 starter 方式讓業(yè)務模塊低成本接入。整體設計分為兩部分，client端和server端，如下圖：

△mock 中心

其中，服務端的可視化 mock 規(guī)則配置支持動態(tài)規(guī)則，對于一些無法用動態(tài)規(guī)則描述的需求也可以通過低成本的代碼開發(fā)實現(xiàn)定制化邏輯。

最終期望能夠讓每個中臺服務達到『自治與隔離』，從而解耦各需求點的上線，如下圖：

可以看到，上線粒度從需求維度細化到了中臺 fetaure，使整體交付風險指數(shù)級下降。當然，對于微服務架構系統(tǒng)，如何做到高效聯(lián)調和測試仍是一個正在不斷探索的方向。

三、總結

本文主要介紹了合約廣告微服務架構演進中的一些最佳實踐，做一個簡單的總結。

1. 服務拆分：從實際業(yè)務出發(fā)，基于領域驅動模型的理念，建立合適的業(yè)務模型。這部分一定要深入業(yè)務細節(jié)，理解業(yè)務運轉原理，抽象出業(yè)務本質。通過合理服務拆分，可以更高效地解決復雜業(yè)務問題，如果將7個業(yè)務中臺類比為正交的坐標軸，那么原來低維的復雜問題（單體架構）投射到高維后（微服務架構），大概率會變得沒那么復雜；另外，對于本質業(yè)務復雜度問題，通過服務拆分，可以很好的將復雜性隔離至對應領域服務，更好地管理復雜度，防止外溢。

2. 模塊結構：借鑒COLA架構，結合實際情況，制定規(guī)范，其中包含了多種設計理念：DDD、事件驅動模式、CQRS模式、依賴倒置。相比服務拆分，模塊結構是從微觀視角制定各微服務的代碼組織，減緩腐化速度。

3. 服務治理：總結了系統(tǒng)性能、業(yè)務可觀測性和防腐化三個方面的一些心得和最佳實踐，在我看來，一個好的業(yè)務架構，能夠很好的管控業(yè)務復雜度，甄別業(yè)務中的『變』和『不變』。所以，定期梳理分析各服務的升級頻率、調用關系等是非常重要的。

4. 服務迭代：服務及架構的迭代需要平滑有序，做到容錯、兼容、演進式，避免大量應用改造。同時各微服務要做到自治與隔離，降低相互之間的耦合，做到在架構演進過程中每個服務都能順利地『死去』與『重生』，就像生物進化一樣。（本文多次提到的領域事件方式是降低服務耦合的有效手段）

所以回到本文開頭的2個問題，B端系統(tǒng)最大的技術挑戰(zhàn)我認為是業(yè)務復雜度的治理，通過合適的技術選型在賦能業(yè)務的同時又能很好地管控技術和業(yè)務復雜度。我心目中好的業(yè)務架構標準就是提升效率，這里的效率包括交付效率、運維效率以及演進效率。

最后想說：沒有完美的業(yè)務架構，貼合業(yè)務實際的就是好架構，一個好的業(yè)務架構一定是結合業(yè)務實際演進而來的。

————END————

推薦閱讀：

AI技術在基于風險測試模式轉型中的應用

Go語言躲坑經(jīng)驗總結

PaddleBox：百度基于GPU的超大規(guī)模離散DNN模型訓練解決方案

聊聊機器如何"寫"好廣告文案?

百度工程師教你玩轉設計模式（適配器模式）

百度搜索業(yè)務交付無人值守實踐與探索文章來源地址http://www.zghlxwxcb.cn/news/detail-782400.html

到了這里，關于合約廣告平臺架構演進實踐的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！