本文整理自馮嘉在開發者生態峯會的分享，通過此文，希望幫助大家瞭解：
-
對於分佈式消息系統，傳統的消息系統以及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如何解決分佈式事務難題。
歡迎關注“阿里巴巴中間件”，加入中間件開發者羣，與技術同行。
