阿里巴巴馮嘉：分佈式消息系統的現狀、挑戰與將來

本文整理自馮嘉在開發者生態峯會的分享，經過此文，但願幫助你們瞭解：

• 對於分佈式消息系統，傳統的消息系統以及Messaging生態面臨的挑戰；
• 結合阿里巴巴自身的開源實踐，提供如何應對以上挑戰的參考答案；
• OpenMessaging生態現狀和將來的發展方向。

馮嘉：Apache RocketMQ 創始人，Linux OpenMessaging 創始人，阿里巴巴 Messaging 技術負責人。

消息系統的業界挑戰

第一，開源軟件給傳統閉源軟件帶來的衝擊。早期的消息系統是閉源的，但隨着開源生態的發展，出現愈來愈多的的開源消息系統，使得用戶在面臨消息系統選型的時候有了更多的選擇，這對傳統的Messaging廠商來講是個很是大的挑戰。

第二，互操做性成本愈來愈高。消息系統正面臨愈來愈多的上下游生態。例如，部門和部門之間選擇了不一樣的技術棧，這個部門選擇了這個消息，那個部門產生了那個消息，當二者之間進行流通的時候必然帶來了互操做性的問題，因此，這對消息系統提出了很高的互操做性要求。

第三，消息自然就是異構的，它是爲解決數據間的流轉問題而生。每一個部門在擁有本身技術棧的同時產生了不一樣的開發語言，每門語言都有本身所擅長的技術領域，一門語言並沒有法通吃全部需求場景。這樣的場景下，若是用了Messaging，都會但願消息系統能在不一樣的語言之間進行互通，但目前，業界不多有多語言的消息系統而且能夠cover的得很好的，由於缺乏穩定的多語言類庫。

第四，券商和電商領域須要微秒級的延遲，微秒級的延遲在軟件和硬件上沒有達到很好的配合，因此第四個挑戰就是因爲嵌入式和新型硬件設備能力較弱所致使的。

第五，物聯網有不少的端，端到端之間到後臺都有數據採集和數據上報，規模化的部署能力也是全部消息系統所面臨的挑戰。

阿里巴巴是如何應對這類挑戰的

第一，咱們但願在開源基礎框架的基礎上，可以針對某些垂直領域或者針對高性能低延時場景分別推出企業版本和雲上版本。雲上版本重點關注部署流暢度，下降部署時間，提升擴展性，甚至可以加速雲基礎設施的遷移。由於不少MMQ的廠商已經作了商業化的場景，而咱們作了企業版本，在FQ領域研發了IOT網關，在金融領域應用分佈式的消息，經過這種方式讓用戶使用起來，而云上咱們有更強的兜底能力。你們使用雲上版本以後會發現：成本降下來了，部署速度快了，企業只須要專一業務，不須要關注底層基礎設施的變化所帶來的影響。

第二，互操做性在任何技術領域都是一個須要面對的問題。而在消息領域，業界已經有三個比較出名的消息標準，但都沒法很好的解決互操做性問題：JMS是一個Java 平臺中關於面向消息中間件的API；MQTT是對物聯網行業具備低功耗特色的通信協議；AMQP則主要應用於電信和金融行業。

在評估了全部可用的替代品後，咱們決定選擇建立一個新的面向Cloud Native的消息分發標準 OpenMessaging，這是一個供應商中立，且和語言無關的標準，併爲金融、電子商務、物聯網和大數據等領域提供了行業指南。

第三，咱們開放了OpenMessaging內核，並經過sidercar的方式提供瞭解決多語言需求的方案，據此，咱們只須要在Java的基礎上，打造C語言的內核，而後把Java和C語言的內核開放出來，在此之上創建Python、Go等其餘語言的sdk，實現和社區共建生態。

第四，在券商和電商領域，咱們提出一個解決方案：你們都很清楚就是如今慢慢在使用NVMI存儲去替代之前的SSD硬盤。若是咱們採用這類硬件設備，是能夠繞過內核的。經過對比發現，MQ的硬件設備，在硬件層經過SSD存儲層，延遲會大大下降，全部的延遲都集中在APP層或者集中在硬件驅動層。這樣的話，可以保證應用在100毫秒甚至十幾微秒的狀況下達到很是少的延遲。而傳統的軟件要適配在這類硬件上是頗有挑戰的，由於這類硬件不兼容傳統軟件的API。

第五，對於規模化的部署，存儲計算分離和事件驅動架構是很好的解決方案。例如，IoT領域，存儲端和計算端是能夠分開的，這樣極大地的提高了端的計算能力。

OpenMessaging的將來發展方向

如今，咱們都看到了基礎設施很是open，就像公路和橋樑同樣，有不少的操做系統，像Open Office辦公軟件等不少技術已經轉向開放，咱們但願將OpenMessaging打形成數據層面很是好的基石。

就像這幅圖描述的那樣：數據維度，咱們能夠涵蓋日誌數據和業務數據；行業維度，遊戲行業、電商行業的交易數據均可以經過OpenMessaging往下拓展，對於IOT，則能夠經過OpenMessaging把數據的上游和下游以標準化的方式串起來。廠商維度，包括Apache Kafka，Apache RocketMQ，RabbitMQ，Apache ActiveMQ均可以基於這個標準構建下一代的消息解決方案。

如今，OpenMessaging有四個工做組：第一個工做組主要是關注在span的制定上面；第二個工做組是解決API；第三個工做組是但願提供bench mark API；第四個工做組是解決存儲的工具化，由於將來的架構必定是存儲和計算分離，必定會面臨不少的存儲。

通過一年多的發展，整個OpenMessaging的技術發展委員會已經有7名成員，他們分別來自4家公司，有電商、廣告搜索、流計算，還有數據集成，你們共同的特色就是互操做。除了對產品和技術方向進行把握的技術委員會以外，還有11位來自6家不一樣企業組成的諮詢委員會，這11位同窗會幫助咱們提一些建設和產品發展規劃方面的建議。除此以外，還有接近二十多位來自社區的contributors，從而保證OpenMessaging是在往多元化、無廠商鎖定的健康的方向上發展。

線下分享預告：

王強（遼天）受邀參加 10月18-20日Qcon·上海站，並進行主題爲《Apache RocketMQ事務消息演進之路》的分享，歡迎來現場瞭解Messaging如何解決分佈式事務難題。

本文做者：中間件小哥

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。