4月26日，在2018云棲大會南京峰會上，阿里巴巴研究員林昊正式發(fā)布了第四屆阿里中間件性能挑戰(zhàn)賽。挑戰(zhàn)賽以開源項(xiàng)目為背景，核心技術(shù)為Dubbo和RocketMQ，目的是通過大賽向技術(shù)愛好者們傳達(dá)開源精神。

林昊表示，“對于開發(fā)人員來講，很多工作都使用了開源的東西，開源對整個世界也產(chǎn)生了非常大的影響。對阿里來講也同樣，阿里巴巴也同樣使用了開源的軟件，在這個過程中，我們結(jié)合阿里的場景，對整個開源的產(chǎn)品進(jìn)行了很多改進(jìn)，也不斷回饋到社區(qū)。”

從2017年起，阿里巴巴開源的步伐正在加速。

2017年9月，RocketMQ在Apache畢業(yè)，成為了Apache頂級項(xiàng)目（TLP）。10月份，OpenMessaging發(fā)布，分布式消息中間件、流處理領(lǐng)域的應(yīng)用開發(fā)標(biāo)準(zhǔn)，目前已正式入駐Linux基金會，這也是國內(nèi)首個在全球范圍內(nèi)發(fā)起的分布式消息領(lǐng)域國際標(biāo)準(zhǔn)。11月，社區(qū)突然熱鬧起來，Dubbo快速更新，引發(fā)了非常廣泛的關(guān)注。今年，Dubbo進(jìn)入了Apache，目前正在孵化期。

Apache基金會聯(lián)合創(chuàng)始人Jim Jagielski表示，Apache頂級項(xiàng)目RocketMQ是一個極其強(qiáng)大且具有變革性的軟件項(xiàng)目，眾多公司都是它的深度用戶。Dubbo目前正在Apache軟件基金會內(nèi)孵化，具有巨大的潛力。

中間件性能挑戰(zhàn)賽至今已經(jīng)是第四屆，這是首次把賽題設(shè)置在開源背景上，讓更多技術(shù)開發(fā)者參與其中。

下面，我們針對本次賽題做個詳細(xì)的深度解析。

了解 Dubbo 的朋友們都知道，Dubbo不僅僅是一款高性能的 RPC 通訊框架，更是一套完整的微服務(wù)解決方案——服務(wù)注冊與發(fā)現(xiàn)、負(fù)載均衡、服務(wù)治理等，這些都是我們耳熟能詳?shù)哪芰Α５?Dubbo 也有著天然的不足，初賽的題目便由此而來。

一、初衷

Dubbo 一直致力于為 Java 應(yīng)用提供高效、穩(wěn)定和可用于生產(chǎn)環(huán)境的 RPC 通訊能力，但比起 gRPC 和 Spring Cloud，Dubbo 的跨語言能力是一大弱點(diǎn)。在不使用 RESTful 接口的情況下，用戶很難將 Dubbo 與其它語言實(shí)現(xiàn)的系統(tǒng)對接起來。因此本次比賽將打破語言的藩籬，參賽團(tuán)隊(duì)可以盡情選取你最中意的技術(shù)，主流的也好，非主流的也罷——We don't care——讓 Dubbo 在多語言的方向上邁出第一步。

提到 Dubbo 就不能不說微服務(wù)，而言及微服務(wù)就一定有 Service Mesh 的一席之地。

傳統(tǒng)的微服務(wù)向我們展現(xiàn)了服務(wù)化的未來藍(lán)圖，也提供了諸多方法論和最佳實(shí)踐指導(dǎo)我們完成架構(gòu)的變革。但是顯然實(shí)施過微服務(wù)的朋友們都一定清楚，這是一個異常復(fù)雜且充滿了不確定性的改造過程——將單體系統(tǒng)剝離、引入服務(wù)化組件（如果 Dubbo 不是你的第一選擇，你更有理由關(guān)注本次比賽了）、將內(nèi)部調(diào)用轉(zhuǎn)化為遠(yuǎn)程調(diào)用、解決因?yàn)檎{(diào)用遠(yuǎn)程化和分布化而帶來的各種次生問題（網(wǎng)絡(luò)問題、安全問題、狀態(tài)管理問題、一致性問題等等）。在擁有復(fù)雜系統(tǒng)的組織內(nèi)部，這樣的改造不亞于夢魘。想想看要把各種不標(biāo)準(zhǔn)的 Java 應(yīng)用、PHP 應(yīng)用、Python 應(yīng)用等全部打通且服務(wù)化，不是你在做夢，就是客戶在做夢。

可這樣的夢境就是我們要面對的現(xiàn)實(shí)，而Service Mesh 無疑是夢境架構(gòu)師遞給你的一根救命稻草。簡言之，Service Mesh 另辟蹊徑，在不深入服務(wù)內(nèi)部的情況下，以 Agent 的形式與服務(wù)共生，并由 Agent 提供一切微服務(wù)所需要的能力。正如其名稱所揭示的那樣，Service Mesh 就如同一張網(wǎng)格，將各種服務(wù)網(wǎng)羅在其下。這次初賽的題目就是希望參賽選手編寫一個高性能的 Agent 實(shí)現(xiàn)，讓 Dubbo 融入 Service Mesh 這張大網(wǎng)。

二、場景

在本次比賽中，并不需要實(shí)現(xiàn)一套完整的Service Mesh 框架，因此我們對場景進(jìn)行了限定。得益于 Docker 提供的容器化能力，讓我們可以很方便地模擬出想要的場景。如圖所示，整個場景由 5 個 Docker 實(shí)例組成（藍(lán)色的方框），分別運(yùn)行了 etcd、Consumer、Provider 服務(wù)（綠色的方框）和 Agent 代理（紅色的圓圈）。

Provider 是服務(wù)提供者，Consumer是服務(wù)消費(fèi)者，Consumer 消費(fèi) Provider 提供的服務(wù)。Agent 是 Consumer 和 Provider 服務(wù)的代理，每個 Consumer 或 Provider 都會伴隨一個共生的 Agent。etcd 是注冊表服務(wù)，用來記錄服務(wù)注冊信息。從圖中可以看出，Consumer 與 Provider 之間的通訊并不是直接進(jìn)行的，而是經(jīng)過了 Agent 的中轉(zhuǎn)。這看似多余的一環(huán)，卻在 Service Mesh 的架構(gòu)中扮演著舉足輕重的角色。

首先，Agent 需要實(shí)現(xiàn)負(fù)載均衡的能力。在圖中，藍(lán)色方框的大小代表了容器的性能。我們可以發(fā)現(xiàn)，一個 Consumer 實(shí)例的性能是三個 Provider 實(shí)例性能的總和，而且三個 Provider 的性能又是以 1:2:3 的比例分配的。假如整個系統(tǒng)性能是 60，則 Consumer 占 30，Provider(small) 占 5，Provider(medium) 占 10，Provider(large) 占 15。因此任何一個 Provider 服務(wù)的性能都比 Consumer 要小，Agent 必須做到負(fù)載均衡才能保證任意一個 Provider 服務(wù)不會被壓垮。

第二，Agent 需要實(shí)現(xiàn)服務(wù)注冊與發(fā)現(xiàn)的能力。服務(wù)注冊與發(fā)現(xiàn)是微服務(wù)的核心能力，Consumer Agent 具體要訪問哪一個 Provider Agent 不是在配置文件中寫死的，而是動態(tài)發(fā)現(xiàn)的。簡單來說，當(dāng)Agent 啟動的時候，需要將自己的信息寫入 etcd 注冊表，在服務(wù)調(diào)用發(fā)生的時候，再從 etcd 中讀取相關(guān)的注冊信息，這個過程就是最簡單的服務(wù)注冊與發(fā)現(xiàn)。

第三，Agent 需要實(shí)現(xiàn)協(xié)議轉(zhuǎn)換的能力。Service Mesh 的一大特色就是可以實(shí)現(xiàn)不同語言、不同框架、不同協(xié)議間服務(wù)的互聯(lián)互通，靠的就是其協(xié)議轉(zhuǎn)換的能力。在比賽設(shè)定的場景中，Consumer 使用 HTTP 協(xié)議，而 Provider 使用 Dubbo 協(xié)議，在沒有 Agent 幫助的情況下，他們之間是無法通信的。

?

作為 Service Mesh Agent， 其實(shí)還有很多可以實(shí)現(xiàn)的功能，如流量控制、服務(wù)降級或熔斷、安全認(rèn)證等等，但以上三點(diǎn)是本次比賽必須做到的能力，其他能力不做要求。另外我們還要考慮 Agent 的通用性，一個不具有通用性的 Agent 是沒有商業(yè)價值的。除此之外 Agent 占用的系統(tǒng)資源應(yīng)該盡量小，而且不和共生的服務(wù)爭搶資源，否則“皮之不存，毛將焉附”。如果服務(wù)失去了響應(yīng)，那么 Agent 的性能再好也沒有存在的意義了。

三、跑分

跑分環(huán)境是由一臺 4 核 8G 的施壓機(jī)和一臺 8 核 16G 的被壓機(jī)組成。所有 5 個 Docker 實(shí)例均運(yùn)行在被壓機(jī)上。每個項(xiàng)目的每一次跑分會獨(dú)占一臺被壓機(jī)。流程大致如下：

準(zhǔn)備跑分環(huán)境，創(chuàng)建并鎖定工作區(qū)

根據(jù)提交的地址，從鏡像倉庫中拉取鏡像

驗(yàn)證 Provider、Consumer 及啟動腳本文件的簽名，以妨被篡改

啟動 etcd 實(shí)例，并驗(yàn)證服務(wù)可用性

啟動三個 Provider 實(shí)例，并驗(yàn)證服務(wù)可用性

啟動 Consumer 實(shí)例，并驗(yàn)證服務(wù)可用性

使用最高并發(fā)數(shù)對系統(tǒng)進(jìn)行預(yù)熱

分若干次不同的壓力水平，對系統(tǒng)進(jìn)行壓力測試，并記錄 QPS 值

取最優(yōu)的 QPS 作為最終的跑分結(jié)果，并上報給天池系統(tǒng)

按順序依次停止 Consumer 實(shí)例、三個 Provider 實(shí)例和 etcd 實(shí)例

清理 Docker 實(shí)例及鏡像

收集日志并上傳到 OSS

?解鎖工作區(qū)，清理環(huán)境

因?yàn)楸緦帽荣惒幌拚Z言、不限技術(shù)，因此需要一種手段對選手的運(yùn)行環(huán)境進(jìn)行隔離。借助 Docker 鏡像，參賽選手可以隨意安裝運(yùn)行時環(huán)境、添加組件庫、并定制 Agent 的啟動腳本。

但需要注意的是，因?yàn)?Provider 和 Consumer 服務(wù)與 Agent 是共生的，因此他們都是被打到同一個 Docker 鏡像中的。我們在賽題設(shè)計的時候已經(jīng)對代碼進(jìn)行了充分的隔離，以保證選手只需要關(guān)注賽題允許修改的部分——與 Agent 有關(guān)的內(nèi)容。但不管怎樣，由于構(gòu)建 Docker 鏡像的主動權(quán)在大家手里，就勢必會有篡改 Provider 和 Consumer 及其啟動腳本的可能性存在。所以，本著公平的原則，在跑分流程中增加了對相關(guān)文件驗(yàn)證簽名的過程，如果簽名不通過，將失去本次評測機(jī)會。

四、優(yōu)化

因?yàn)閮?yōu)化過程是本次比賽關(guān)注的重點(diǎn)，因此不能做過多的展開，僅僅提供幾個參考的方向。

使用協(xié)程。協(xié)程可以理解為輕量級的線程，可以節(jié)約因?yàn)榫€程切換而造成的性能損失。

使用異步通訊。Agent 與 Agent 之間的通訊機(jī)制完全由選手自行控制，采用非阻塞的異步通訊機(jī)制可以有效提高系統(tǒng)性能。

使用緩存。合理緩存響應(yīng)結(jié)果，當(dāng)相同的請求再次到來的時候，調(diào)用鏈可以不必經(jīng)過系統(tǒng)中的每一個節(jié)點(diǎn)，從而盡快返回。

以上分別從賽題初衷、應(yīng)用場景、跑分環(huán)境與過程以及少許優(yōu)化方向的角度，對本屆比賽的題目進(jìn)行了簡單的剖析，希望對即將參加比賽的親們能有所幫助。在此預(yù)祝各位參賽選手能取得優(yōu)異的成績，進(jìn)軍復(fù)賽和總決賽。

阿里中間件性能挑戰(zhàn)賽由阿里巴巴集團(tuán)發(fā)起，自2015年開始已經(jīng)成功舉辦了三屆。我們的初衷是為熱愛技術(shù)的年輕人提供一個挑戰(zhàn)世界級技術(shù)問題的舞臺，希望選手在追求性能極致的同時，能深刻體會技術(shù)人的匠心精神，用技術(shù)為全社會創(chuàng)造更大價值。

點(diǎn)擊阿里中間件性能挑戰(zhàn)賽，可了解詳情、參加大賽。

總結(jié)

以上是生活随笔為你收集整理的阿里中间件性能挑战赛启动，“开源”赛题独家剖析！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。