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

背景說明

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

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

當(dāng)時(shí)面臨的問題是該領(lǐng)域的SAAS服務(wù)業(yè)務(wù)邏輯非常復(fù)雜，整個(gè)老的代碼已經(jīng)沉淀了一段時(shí)間，往新的框架遷移的時(shí)間周期比較長，所以老的代碼還需要繼續(xù)支撐一段很長的時(shí)間，但是業(yè)務(wù)量又高速發(fā)展，所以需要針對(duì)老的代碼做性能優(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ù)注冊(cè)topic(service層服務(wù)注冊(cè)具體的能力-方法)，此處實(shí)現(xiàn)了一個(gè)服務(wù)注冊(cè)發(fā)現(xiàn)的能力
• API接收到請(qǐng)求：1、api從routeQ中獲取請(qǐng)求具體實(shí)現(xiàn)的service層對(duì)應(yīng)的隊(duì)列名(xxx-service-{host1});2-api將消息(json格式)發(fā)送到對(duì)應(yīng)的隊(duì)列中；3-service層服務(wù)監(jiān)聽到隊(duì)列的消息，進(jìn)行業(yè)務(wù)處理；4、service層服務(wù)獲取監(jiān)聽的消息中的target地址(xxx-api-{host})，將結(jié)果消息寫會(huì)target地址；5、api服務(wù)監(jiān)聽到resp消息然后將結(jié)果返回給請(qǐng)求終端
• api的處理是一個(gè)同步過程

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

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

mule.png

• 對(duì)外服務(wù)

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

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

優(yōu)化過程

監(jiān)控報(bào)警

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

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

ActiveMQ.png

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

故障分析

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

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

處理措施

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

總結(jié)

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

題外話

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

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

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

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