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.
框架數(shù)據(jù)流轉(zhuǎn)
- 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ù)主要是
- 對(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)警
其中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)警肾扰；
故障分析
通過流量分析和故障檢測(cè)，發(fā)現(xiàn)兩個(gè)點(diǎn)是主要的瓶頸點(diǎn)
- 業(yè)務(wù)消息：由于業(yè)務(wù)需要蛋逾，終端跟云端通過消息進(jìn)行業(yè)務(wù)通信(有些業(yè)務(wù)場(chǎng)景需要云端主動(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ù)場(chǎng)景和依賴的三方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ù)的走下去。
