ESB架構(gòu)，從支撐幾千到百萬訂單的優(yōu)化過程

背景說明

2016年左右是SAAS快速發(fā)展的階段，公司轉(zhuǎn)型SAAS業(yè)務(wù)，變成了風(fēng)口的豬，業(yè)務(wù)快速發(fā)展，同時也避免不了互聯(lián)網(wǎng)公司的發(fā)展初期的痛點，技術(shù)嚴(yán)重拖了業(yè)務(wù)發(fā)展的后腿，幾千的訂單數(shù)已經(jīng)讓系統(tǒng)不堪重負(fù)，三天一個小故障，五天一個大故障，系統(tǒng)基本處于不可用的狀態(tài)。沒有監(jiān)控系統(tǒng)，基本都是客戶發(fā)現(xiàn)問題電話打過來了，才知道系統(tǒng)出問題了。

公司的技術(shù)棧是JAVA，基于一個國外比較流行，國內(nèi)比較冷門的開源ESB框架"Mule"來開發(fā)，當(dāng)時公司決定做技術(shù)轉(zhuǎn)型，將ESB往微服務(wù)轉(zhuǎn)，同時選擇GRPC作為微服務(wù)的開發(fā)框架。

當(dāng)時面臨的問題是該領(lǐng)域的SAAS服務(wù)業(yè)務(wù)邏輯非常復(fù)雜，整個老的代碼已經(jīng)沉淀了一段時間，往新的框架遷移的時間周期比較長，所以老的代碼還需要繼續(xù)支撐一段很長的時間，但是業(yè)務(wù)量又高速發(fā)展，所以需要針對老的代碼做性能優(yōu)化，能夠支撐到新的框架能夠上線

架構(gòu)介紹

What is Mule ESB?

Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. It enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMS, Web services, JDBC, HTTP, and more. The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.

what-mule-esb.png

框架數(shù)據(jù)流轉(zhuǎn)

數(shù)據(jù)流轉(zhuǎn).png

• xxx-api是api層的服務(wù)；xxx-service是service層的服務(wù)，ActiveMQ數(shù)據(jù)總線
• routeQ：服務(wù)注冊topic(service層服務(wù)注冊具體的能力-方法)，此處實現(xiàn)了一個服務(wù)注冊發(fā)現(xiàn)的能力
• API接收到請求：1、api從routeQ中獲取請求具體實現(xiàn)的service層對應(yīng)的隊列名(xxx-service-{host1});2-api將消息(json格式)發(fā)送到對應(yīng)的隊列中；3-service層服務(wù)監(jiān)聽到隊列的消息，進(jìn)行業(yè)務(wù)處理；4、service層服務(wù)獲取監(jiān)聽的消息中的target地址(xxx-api-{host})，將結(jié)果消息寫會target地址；5、api服務(wù)監(jiān)聽到resp消息然后將結(jié)果返回給請求終端
• api的處理是一個同步過程

服務(wù)部署架構(gòu)圖

服務(wù)的部署主要是按照粗粒度的系統(tǒng)功能做了集群的劃分：定時任務(wù)主要是

mule.png

• 對外服務(wù)

主要是面向?qū)ν獾姆?wù)，流量較大，SLA要求比較高，出問題概率也比較高，系統(tǒng)故障的容忍度低

• 內(nèi)部管理服務(wù)內(nèi)部運營和管理人員使用的，服務(wù)的SLA要求不高，系統(tǒng)故障容忍度高，允許一定時間的服務(wù)異常
• 定時任務(wù)任務(wù)類的介于對外和對內(nèi)的服務(wù)之間的SLA要求，由于也是服務(wù)于在線業(yè)務(wù)類的服務(wù)，部分服務(wù)實時性要求比較高，類似于準(zhǔn)實時，比如延時的要求是秒級別的，所以這類的服務(wù)也需要有一定的可用性控制，系統(tǒng)故障榮任務(wù)略低

優(yōu)化過程

監(jiān)控報警

最開始沒有監(jiān)控報警，服務(wù)掛掉全是靠客戶的電話才能知道，那么首先就是構(gòu)建監(jiān)控報警系統(tǒng)，基于小米開源的Open-Falcon構(gòu)建了最早的監(jiān)控報警系統(tǒng)，然后開始分析整個Mule開發(fā)框架的問題，通過分析部署圖和Mule的框架可以得出，出問題最直接的表象，隊列阻塞和隊列的consumer數(shù)量異常，那么就是基于這個來實現(xiàn)一個報警。

Mule基于ActiveMQ來作為自己的數(shù)據(jù)總線，ActiveMQ是一個典型的AMQ，類似于RabbitMQ、RocketMQ，都有自己的admin管理頁面或者api接口，那么就是基于admin-api來操作，由于ActiveMQ產(chǎn)品比較老，很多的協(xié)議還是基于XML，那么就是通過接口獲取隊列的stat信息，然后分析隊列的消息數(shù)量和consumer數(shù)量來觸發(fā)報警，Open-Falcon的開放性非常強(qiáng)，只需要寫一個plugin就可以實現(xiàn)自己需要定制化報警

ActiveMQ.png

其中queues/queue/stats/size隊列為消費的堆積消息數(shù)；queues/queue/stats/consumerCount是消費者的數(shù)量。消費者消息規(guī)定的數(shù)報警、消息對接數(shù)量過多報警；

故障分析

通過流量分析和故障檢測，發(fā)現(xiàn)兩個點是主要的瓶頸點

• 業(yè)務(wù)消息：由于業(yè)務(wù)需要，終端跟云端通過消息進(jìn)行業(yè)務(wù)通信(有些業(yè)務(wù)場景需要云端主動給消息到終端)，但是消息的通信采用了輪訓(xùn)拉取的方式，通過分析有85%的流量都來自于消息的輪訓(xùn)，但是由于業(yè)務(wù)量還不夠大，這85%的消息輪訓(xùn)里邊又80%以上的都是無效的空查詢，絕大部分都是沒有消息，這個時候就是空輪訓(xùn)，但是整個業(yè)務(wù)請求還需要過一遍ActiveMQ。同時消息的查詢后端service直接查詢MySQL，這樣對于MySQL的壓力也非常大
• 業(yè)務(wù)賬單數(shù)據(jù)的處理：此業(yè)務(wù)出故障的次數(shù)也比較多，我來公司第一次碰到故障就是賬單的隊列堵了，這個的原因主要是賬單的數(shù)據(jù)會引發(fā)一連串的數(shù)據(jù)計算，邏輯非常復(fù)雜，同步計算，嚴(yán)重依賴MySQL，consumer消費能力非常容易遇到瓶頸
• ActiveMQ集群：集群使用的是5.13.0，比較老的一個版本，對于cluster的支持不太友好，只能支持雙主模式，雙主模式經(jīng)常出故障

處理措施

• 消息的輪訓(xùn)拉取的方式改造成推的模式，通過websocket實現(xiàn)長連接推送消息
• 賬單數(shù)據(jù)的處理其實類似于一個離線業(yè)務(wù)，不算是在線業(yè)務(wù)，實時性要求不是很高，將賬單處理的部分從在線的集群剝離，獨立一個賬單處理的集群，同時賬單的堵塞經(jīng)常是因為計算復(fù)雜，數(shù)據(jù)庫瓶頸遇到隊列堵塞，所以做了讀寫分離，對于賬單報表的讀取和計算在同一個Mule集群里邊做了隊列的讀寫分離，避免互相的影響
• 同時將服務(wù)再次做了細(xì)粒度的劃分：在線/離線、讀/寫的服務(wù)的劃分，將集群重新的規(guī)劃，盡量保證實時在線業(yè)務(wù)的高可用
• 在線業(yè)務(wù)集群同時部署兩個集群，做數(shù)據(jù)隔離，但是同時承載業(yè)務(wù)流量，做到服務(wù)級別的HA
• 接入層通過nginx和openresty做了一些熔斷和降級的處理，最大限度保證服務(wù)的可用性
• 通過分析可以發(fā)現(xiàn)基本服務(wù)的瓶頸都會出現(xiàn)在MySQL數(shù)據(jù)層，那么針對這個瓶頸也做了調(diào)整，讀寫分離和分庫，讀寫分離比較好理解，分庫的邏輯主要是針對SAAS的特點，SAAS系統(tǒng)主要是以客戶為核心，每個客戶都有自己的客戶標(biāo)識，那么可以天然的通過客戶的標(biāo)識來進(jìn)行分庫的操作
• ActiveMQ遇到過幾次問題，首先是內(nèi)存過高觸發(fā)流控(AMQ都有類似的自我保護(hù)能力)、OOM這種主要是調(diào)整JVM的內(nèi)存設(shè)置以及流控的配置
• ActiveMQ的集群問題，雙主的模式經(jīng)常會出現(xiàn)consumer都落到一個節(jié)點，導(dǎo)致另外一個節(jié)點產(chǎn)生的消息無法消費堵塞，高版本的ActiveMQ支持多節(jié)點的集群模式也解決了類似的BUG，由于所有的RD都集中在GRPC微服務(wù)改造，不準(zhǔn)備提升版本支持高版本的開發(fā)，所以只能通過別的方案繞開，ActiveMQ不采用集群，只是用單點 haproxy來實現(xiàn)HA。

總結(jié)

• 通過上邊的優(yōu)化改造錯誤，Mule運行了一年多的時間，支撐了訂單到百萬的業(yè)務(wù)量，同時故障率非常的低，保證了SLA
• 一個完整的大型系統(tǒng)，在整個的生命周期內(nèi)，開發(fā)交付以后，運維、優(yōu)化、保證可用性階段的重要性也非常的大，需要不停的去學(xué)習(xí)改造
• 監(jiān)控報警系統(tǒng)需要首先部署好，避免系統(tǒng)的裸奔，只要好的監(jiān)控報警才能夠幫助我們更快速的定位問題、發(fā)現(xiàn)問題、優(yōu)化和改造系統(tǒng)
• 服務(wù)的等級劃分非常重要，需要最大粒度的去劃分，然后根據(jù)等級做不同的處理
• 服務(wù)的治理、讀寫分離在系統(tǒng)的很多方面都能用到，需要根據(jù)實際情況更好的應(yīng)用到特定的地方

題外話

MuleSoft公司成立于2006年，最初是實現(xiàn)一個ESB的開發(fā)框架并開源，框架的名字命名為"Mule"，由于單純通過框架和服務(wù)支持很難盈利；

2009年在新CEO加入以后，開始轉(zhuǎn)型，并構(gòu)建一個名為"Anypoint"的云平臺，平臺打通了數(shù)千個SAAS服務(wù)平臺，并將服務(wù)通過API接口的方式暴露給用戶，用戶可以在Anypoint上邊按照自己的業(yè)務(wù)場景和依賴的三方SAAS平臺，組裝自己的自定義業(yè)務(wù)，可以說Anypoint是對于ESB的上層抽象，將SAP、NetSuite、Salesforce等三方SAAS服務(wù)當(dāng)做企業(yè)的應(yīng)用，Anypoint就是連接SAAS服務(wù)的數(shù)據(jù)總線，同時用戶可以基于Anypoint的編排能力用最低的代價實現(xiàn)自己的業(yè)務(wù)，大量的減少了IT的投入成本。用當(dāng)前比較流行的概念來說，Anypoint就是一個通用的業(yè)務(wù)中臺，也是一個有業(yè)務(wù)編排能力的低代碼平臺。

也正是得益于MuleSoft的轉(zhuǎn)型和在云服務(wù)的優(yōu)秀表現(xiàn)，2018年被Salesforce用65億美元的價格收購，徹底逆襲。

從MuleSoft的成功我們也能看到，對于計算機(jī)和軟件體系，任何概念和理論都是互通的，都是可以借鑒并發(fā)展的，同時需要有一個明確的可以落地的方向，沿著方向持續(xù)的走下去。