對于程序員來說，什么才最為重要

?一筆高達50萬的巨額獎金？

?一個和千萬程序員一同賽跑的游戲？

?一次挑戰雙11萬億級服務調用的機會？

場主認為，敲碼路上，我們所追求的是不斷進階的自我提升！

4月26號，2018云棲大會南京峰會上，阿里巴巴研究員林昊正式發布了第四屆阿里中間件性能挑戰賽。

這是首次把賽題設置在開源背景上，旨在讓更多技術開發者參與其中。

挑戰賽以開源項目為背景，核心技術為Dubbo和RocketMQ，目的是通過大賽向技術愛好者們傳達開源精神。

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

而且！此次大賽還收到了JimJagielski （Apache基金會聯合創始人）的祝福哦！！！

感興趣的同學可以直接長按以上二維碼或戳中以下鏈接進行報名了！

https://tianchi.aliyun.com/markets/tianchi/aliware2018contest?spm=5176.100065.5490641.1.31fe67b7UN1OQ0（若未能跳轉，煩請復制鏈接至瀏覽器打開）

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

2017年9月，RocketMQ在Apache畢業，成立了Apache頂級項目（TLP）。

10月份，OpenMessaging發布，分布式消息中間件、流處理領域的應用開發標準，目前已正式入駐Linux基金會，這也是國內首個在全球范圍內發起的分布式消息領域國際標準。

11月，社區突然熱鬧起來，Dubbo快速更新，引發了非常廣泛的關注。

今年，Dubbo進入了Apache，目前正在孵化期。

Apache基金會聯合創始人 Jim Jagielski?表示：“ Apache頂級項目RocketMQ是一個極其強大且具有變革性的軟件項目，眾多公司都是它的深度用戶。Dubbo目前正在Apache軟件基金會內孵化，具有巨大的潛力。”

賽題深度解析

賽題解析

了解 Dubbo 的朋友們都知道，Dubbo不僅僅是一款高性能的 RPC 通訊框架，更是一套完整的微服務解決方案——服務注冊與發現、負載均衡、服務治理等，這些都是我們耳熟能詳的能力。但是 Dubbo 也有著天然的不足，初賽的題目便由此而來。

初衷

Dubbo 一直致力于為 Java 應用提供高效、穩定和可用于生產環境的RPC通訊能力。在不使用 RESTful 接口的情況下，用戶很難將 Dubbo 與其它語言實現的系統對接起來。

因此本次比賽將打破語言的藩籬，參賽團隊可以盡情選取你最中意的技術，主流的也好，非主流的也罷——We don't care——讓 Dubbo 在多語言的方向上邁出第一步。

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

傳統的微服務向我們展現了服務化的未來藍圖，也提供了諸多方法論和最佳實踐指導我們完成架構的變革。但是顯然實施過微服務的朋友們都一定清楚，這是一個異常復雜且充滿了不確定性的改造過程。

將單體系統剝離、引入服務化組件（如果 Dubbo 不是你的第一選擇，你更有理由關注本次比賽了）、將內部調用轉化為遠程調用、解決因為調用遠程化和分布化而帶來的各種次生問題（網絡問題、安全問題、狀態管理問題、一致性問題等等）。

在擁有復雜系統的組織內部，這樣的改造不亞于夢魘。想想看要把各種不標準的 Java 應用、PHP 應用、Python 應用等全部打通且服務化，不是你在做夢，就是客戶在做夢。

可這樣的夢境就是我們要面對的現實，而Service Mesh 無疑是夢境架構師遞給你的一根救命稻草。簡言之，Service Mesh 另辟蹊徑，在不深入服務內部的情況下，以 Agent 的形式與服務共生，并由 Agent 提供一切微服務所需要的能力。

正如其名稱所揭示的那樣，Service Mesh 就如同一張網格，將各種服務網羅在其下。這次初賽的題目就是希望參賽選手編寫一個高性能的 Agent 實現，讓 Dubbo 融入 Service Mesh 這張大網。

場景

在本次比賽中，并不需要實現一套完整的Service Mesh 框架，因此我們對場景進行了限定。

得益于 Docker 提供的容器化能力，讓我們可以很方便的模擬出想要的場景。如圖所示，整個場景由 5 個 Docker 實例組成（藍色的方框），分別運行了 etcd、Consumer、Provider 服務（綠色的方框）和 Agent 代理（紅色的圓圈）。

Provider 是服務提供者，Consumer是服務消費者，Consumer 消費 Provider 提供的服務。Agent 是 Consumer 和 Provider 服務的代理，每個 Consumer 或 Provider 都會伴隨一個共生的 Agent。etcd 是注冊表服務，用來記錄服務注冊信息。

從圖中可以看出，Consumer 與 Provider 之間的通訊并不是直接進行的，而是經過了 Agent 的中轉。這看似多余的一環，卻在 Service Mesh 的架構中扮演著舉足輕重的角色。

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

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

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

作為 Service Mesh Agent， 其實還有很多可以實現的功能，如流量控制、服務降級或熔斷、安全認證等等，但以上三點是本次比賽必須做到的能力，其他能力不做要求。

另外我們還要考慮 Agent 的通用性，一個不具有通用性的 Agent 是沒有商業價值的。除此之外，?Agent 占用的系統資源應該盡量小，而且不和共生的服務爭搶資源，否則“皮之不存，毛將焉附”。如果服務失去了響應，那么 Agent 的性能再好也沒有存在的意義了。

跑分

跑分環境是由一臺 4 核 8G 的施壓機和一臺 8 核 16G 的被壓機組成。所有 5 個 Docker 實例均運行在被壓機上。每個項目的每一次跑分會獨占一臺被壓機。流程大致如下：

1.準備跑分環境，創建并鎖定工作區

2.根據提交的地址，從鏡像倉庫中拉取鏡像

3.驗證 Provider、Consumer 及啟動腳本文件的簽名，以妨被篡改

4.啟動 etcd 實例，并驗證服務可用性

5.啟動三個 Provider 實例，并驗證服務可用性

6.啟動 Consumer 實例，并驗證服務可用性

7.以最高并發數對系統進行預熱

8.分若干次不同的壓力水平，對系統進行壓力測試，并記錄 QPS 值

9.取最優的 QPS 作為最終的跑分結果，并上報給天池系統

10.按順序依次停止 Consumer 實例、三個 Provider 實例和 etcd 實例

11.清理 Docker 實例及鏡像

12.收集日志并上傳到 OSS

13.解鎖工作區，清理環境

因為本屆比賽不限語言、不限技術，因此需要一種手段對選手的運行環境進行隔離。借助 Docker 鏡像，參賽選手可以隨意安裝運行時環境、添加組件庫、并定制 Agent 的啟動腳本。

但需要注意的是：

“ 因為 Provider 和 Consumer 服務與 Agent 是共生的，因此他們都是被打到同一個 Docker 鏡像中的。”

我們在賽題設計的時候已經對代碼進行了充分的隔離，以保證選手只需要關注賽題允許修改的部分——與 Agent 有關的內容。

但不管怎樣，由于構建 Docker 鏡像的主動權在大家手里，就勢必會有篡改 Provider 和 Consumer 及其啟動腳本的可能性存在。

所以，本著公平的原則，在跑分流程中增加了對相關文件驗證簽名的過程，如果簽名不通過，將失去本次評測機會。

優化

因為優化過程是本次比賽關注的重點，因此不能做過多的展開，僅僅提供幾個參考的方向。

1.使用協程。協程可以理解為輕量級的線程，可以節約因為線程切換而造成的性能損失。

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

3.使用緩存。合理緩存響應結果，當相同的請求再次到來的時候，調用鏈可以不必經過系統中的每一個節點，從而盡快返回。

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

注：阿里中間件性能挑戰賽是由阿里巴巴集團發起，阿里巴巴中間件、阿里云天池聯合承辦的工程視角品牌賽事。自2015年開始已經成功舉辦了三屆。

賽事的初衷是為熱愛技術的年輕人提供一個挑戰世界級技術問題的舞臺，希望選手在追求性能極致的同時，能深刻體會技術人的匠心精神，用技術為全社會創造更大價值。

大賽報名通道，點擊即可進入，是時候展現真正的技術了！

https://tianchi.aliyun.com/markets/tianchi/aliware2018contest?spm=5176.100065.5490641.1.31fe67b7UN1OQ0（若未能跳轉，煩請復制鏈接至瀏覽器打開）