阿里中间件性能挑战赛启动,“开源”赛题独家剖析!
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ù)哪芰Α5?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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 阿里妈妈基于TensorFlow做了哪些
- 下一篇: 技术与商业到底啥关系?我们从业务角度聊一