阿里媽媽廣告應用團隊在平臺化支撐業務發展的思路下，啟動了對應用系統架構、研發模式、組織陣型各個維度的改革和升級，以期通過打造全新的“廣告業務平臺”來提升應用系統的工程建設能力、沉淀廣告業務資產、建設專業的人才梯隊、賦能營銷業務的創新發展。

其中，業務中心化是推進應用平臺化建設最重要的工作之一，我們將廣告業務按照領域進行抽象劃分，建成了多個業務中心組成的業務平臺，每個中心負責該領域的相關業務，多個中心互相配合橫向支撐各業務線的需求。業務中心化后，之前單體的推廣服務系統變成了微服務架構下的多個業務中心，之前系統內部的調用變成了系統和系統之間的調用，如何管理好由此帶來的大量復雜異構系統間的異步調用和通信，是我們亟需抽象和解決問題。

?? 1. 問題分析

在微服務架構下，中心之間為了配合完成復雜的業務，系統和系統之間的“耦合”變的不可避免。系統間的調用方式大體分為同步和異步兩類，由于中心對外以HSF（RPC）服務的方式暴漏，故同步調用問題已經很好的由HSF（RPC）中間件解決，因此我們需要重點關注異步交互方式。

應用間使用的異步交互方式一般有兩種：一種是采用基于消息隊列的異步消息處理（如: Metaq，Notify）；另一種是基于數據庫的DRC消息變更。舉一個異步交互的例子：廣告主應用系統和審核系統屬于兩個不同的領域，團隊和人員也是分開的，在系統交互方式上為了避免耦合，大多會采用消息交互這樣的方式。比如：一個商品被處罰，審核系統發送處罰消息出來，廣告應用系統在接到這個處罰消息之后，需將該商品對應的廣告進行下架。

以基于消息隊列的方式來搭建異步交互鏈路為例，我們來看一下發送端和接收端要做的事情：

1） A系統開發消息發送邏輯?

2） B系統引入A系統的數據對象定義（系統之間耦合度增加）?

3） B系統開發消息訂閱、消費邏輯、重試機制、流控機制等

通過這種方式搭建異步鏈路存在以下幾方面問題：

研發效率低： 為了搭建異步鏈路，B系統的研發人員不得不寫消息訂閱邏輯、異常重試邏輯、流控邏輯，而這些邏輯與核心業務處理并無太多關系，屬于“無效代碼”的范疇（既無業務價值又無技術含量的代碼）。且聯調過程中需要異步鏈路上下游多個系統的人員進行配合，研發和聯調的效率都比較低。

鏈路運維難： 由于異步鏈路的代碼散落在各個系統中，沒有一個集中的平臺來進行管理和運維，整體異步鏈路處于不可見不可管不可控的狀態；也沒有一個人清楚系統間共有多少條異步鏈路，每條異步鏈路流轉的情況，尤其是在大促節點，需要排查、限流的時候就會很無助；另外異步鏈路交接也是個問題，通常只有當時負責開發的同學清楚整個鏈路，一旦有人員變動，原有鏈路幾乎就會處于無人維護的狀態，這無疑給業務的穩定性帶來了很大隱患。

問題排查難： 一旦出現問題，排查人員需要把異步鏈路中涉及到的各個節點從頭到尾熟悉一遍，且由于各個系統日志記錄的方式、格式、詳細程度各不相同，存儲的位置分散，這大大影響了問題排查效率。

上述異步鏈路存在的問題，最根本原因還是鏈路處于不可見不可管不可控的狀態。那么，如何做到可見可管可控呢？我們應該都了解ESB（企業服務總線）的思想，ESB采用了“總線”這樣一種模式來管理和簡化應用之間的集成拓撲結構，以廣為接受的開放標準為基礎來支持應用之間在消息、事件和服務級別上動態的互連互通，是一種在松散耦合的服務和應用之間標準的集成方式。我們的異步鏈路正是缺少了這樣一個集中的點來進行配置、管理和問題排查，借鑒ESB的思想，我們希望整個異步鏈路的交互應該由網狀結構調整成更便于管理的總線型結構。

?

? ?2. 方案設計

本著這個目標，我們打造了工具平臺：AMB應用消息總線（以下簡稱AMB)，來解決應用內部、應用之間基于消息的異步處理請求，由AMB完成消息轉換、路由、處理等功能，并提供統一的監控、報警、重試、流控等機制。

AMB的系統架構如下圖，主要分為控制臺和后端。

控制臺主要面向異步鏈路的開發運維同學，包含“創建任務”和“任務管理”兩塊。“創建任務”模塊可以在上面進行鏈路的可視化、拖拽式配置，我們抽象了一組標準組件，基于這些組件可以完成流程的配置；

“任務管理”模塊主要負責鏈路的啟停管理，鏈路運行狀態及日志的查看。

AMB的后端采用分層的思想進行設計（如下圖所示）:

• 最上面是Connector層，負責對接外部各種協議，如：Metaq, Notify, DRC, HSF等，這一層支持擴展，以便適應需要新增協議的場景。

• 再往下是鏈路組件層，包含我們抽象的一組用來搭建流程的標準組件，目前有：過濾器、轉換器、處理器、分流器、路由器等等，組件庫本身也是可擴展的，根據業務場景的需求可以不斷豐富組件庫的組件。

• 再往下是平臺服務層，是平臺本身提供的一些標準化的公共能力，如：日志、重試策略、監控報警、流控等。

• 最底層是我們的執行引擎，AMB的運行時是跑在我們另一個任務托管的工具平臺鵲橋上的。一條AMB流程占用一個Jstorm的拓撲，流程和流程之間做到了完全隔離。利用Jstorm的擴容縮容機制，我們可以快速響應流程壓力的變化。

? ?3. 技術亮點

從目前實際場景出發，AMB建設有以下幾方面亮點：

易用性：AMB的用戶是我們的研發同學，在日常研發場景中，用戶對于易用性和效率有很高的要求，需要讓用戶感知到配置流程比開發流程更快更方便。為此，我們研發了自助化的流程配置控制臺，基于我們預定義的標準組件，用戶通過拖拽式的所見即所得的方式就可以完成一條流程的配置。

豐富的流程組件：組件相當于搭建一條流程的原子積木，組件之間相互配合來完成一條流程的業務邏輯。目前平臺已經抽象了一系列的通用組件，基本能夠滿足大部分的研發需求，對于組件庫不能滿足的，我們還支持自定義組件，來擴展組件庫的能力。同時標準組件庫本身也在隨著業務需求的演進而不斷的豐富。

隔離性：對于業務方來說，流程的運行是從自己的應用內部轉到公共的AMB 上，如何保證自己的流程不受其他流程影響，如何獲得足夠的處理能力等是業務方非常關心的問題。AMB底層依賴Jstorm拓撲來運行流程，單個流程獨占一個拓撲，完全做到了流程間的物理隔離。同時借助Jstorm的動態擴縮容機制，流程處理能力能夠快速的擴張和收縮，做到實時響應業務處理壓力的變化。

運維監控：異步鏈路的監控和問題排查一直是令研發同學比較頭疼的點。AMB作為異步鏈路的集中化管理節點，擁有統一的監控報警機制、流控機制，另外其集中式標準化的日志，簡化了問題排查的路徑。

? ?4. 業務效果

AMB系統從16年年初上線至今已經五年半的時間，目前已覆蓋阿里媽媽應用系統絕大多數異步鏈路場景。AMB的出現改變了阿里媽媽廣告應用團隊異步鏈路的研發方式，實現了自助式、可視化、拖拽式的流程配置，極大的提高了鏈路的研發效率，從過去的日級開發變成了現在的小時級配置。同時，AMB優化了廣告應用系統的整體架構，做到了異步鏈路可視可管可控，對于消息重試、流控等公共能力做到了統一規劃統一建設，避免了重復和規范不統一的問題。在鏈路運維上，由于有了統一的可視化平臺，鏈路的運行狀態一目了然，規范而集中的日志呈現也使得問題排查變得簡單方便起來。

?? 5. 未來展望

AMB作為高效解決復雜異構系統間異步調用和通信問題的工具平臺，我們期望助力更多業務發展。同時，我們也將在資源利用率的提高上繼續發力，通過將底層流式計算框遷移到Blink，引入智能化資源調度等方式，降低業務支撐成本。

應用平臺化的落地雖然帶來并行迭代、沉淀復用、工具提效的優勢，但也有職能分散、架構復雜的犧牲，因此在大幅提升研發效能、提速業務支撐的同時，也面臨著“架構方案最優化抉擇難”、“涉及系統多易遺漏”、“信息壁壘使溝通成本高”等諸多問題。

為解決這些問題，建立“業務能力標準化”、“業務編排可視化”，以“機制”代替“人治”的“廣告應用中臺”的思路逐漸浮現，AMB也將積極參與和廣告應用中臺的集成，全力支持一站式廣告業務接入中臺的建設。

—— END ——

?

加入我們

阿里媽媽應用平臺團隊，負責阿里集團核心商業產品基礎技術設施建設，我們期望通過技術創新賦能業務發展。歡迎感興趣同學投遞簡歷至：alimama_tech@service.alibaba.com，或關注公眾號了解崗位詳情。

總結

以上是生活随笔為你收集整理的阿里妈妈应用系统大规模异步交互治理方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。