你的分佈式應用真的須要那麼多同步調用麼？

時間 2019-11-10

原文原文鏈接

摘要： 在5月17日舉辦的2016雲棲大會·武漢峯會上阿里中間件產品專家馬雷（阿仁）就阿里中間件MQ作了精彩的演講，告訴你們：阿里中間件團隊的目標是讓消息「傳」無邊界。本文也就爲何使用消息中間件，消息中間件的核心場景進行了分享。相信阿仁的分享會讓你們對分佈式應用的異步調用有更加深入的瞭解。精彩不要錯過！git

對整個分佈式應用系統而言，一共分爲兩種調用，一種是同步調用，一種是異步調用。同步調用就是基於RPC，基於鏈路監控等等的一套東西，而今天分享的主題是則基於異步調用的。

你們仔細思考一下，咱們所作的整個分佈式系統中有多少鏈路是同步調用的，又有多少鏈路又應該是異步調用的呢？好比在一個下單流程中，有多少核心鏈路是使用同步調用的，有多少須要異步調用？

消息中間件的使命是讓消息傳遞無邊界,傳遞無邊界有兩個概念，第一個就是你能夠把包括應用之間的通訊等各類字節流這樣的消息傳到各個端，包括手機端，物聯網，智能電燈，汽車以及雲上應用服務等。第二個就是消息能夠傳遞任何東西，從最小的幾個字節到最大的幾百兆的文件。github

1、爲何使用消息中間件

1.雲是地基

先問一個問題：爲何要使用消息中間件？如今開發分佈式應用系統，不多有人從頭開始寫代碼，由於如今已經不是一我的憋在酒店裏寫一個軟件就能夠成功的年代了，如今每每須要團隊做戰，並且還有可能從更大的角度來說，是一個生態在做戰，而且你所在的生態有可能和其餘的生態存在競爭的關係。那什麼是中間件呢？

用現實生活類比來說，如今房價賣的很高，之前賣房子該怎麼去賣？開發商須要先買塊地基，而後在地基上搭建個框架，最終將其裝修完了之後賣給客戶。如今賣房子怎麼賣呢？能夠直接用現成的框架，不管最終客戶想要裝修成寫字間也好，別墅也好，公寓也好，均可以快速地賣給客戶，快速實現資金回籠。因此這裏有一個理念是：雲實際上就是一個地基，用戶不須要去搞本身的IDC。數據庫

二、中間件是框架

而中間件至關於框架，有了雲的地基，有了中間件的框架，就能夠在上面快速地搭建業務，實現將業務的快速變現，這纔是業務的基石。中間件是應用快速落地的加速器，它可讓團隊擁有快速試錯的技術能力。apache

2、消息場景核心問題-解耦

在整個的分佈式應用中，須要將應用拆分紅不少個WAR包，那麼有多少鏈路須要同步調用，多少能使用異步調用？以經驗來講約70%~80%的鏈路均可以使用異步調用。阿里消息中間件的延遲是在1ms~5ms之間的這樣的一個粒度，實際上相似於準實時的概念，甚至在秒殺的某類場景當中減庫存也能夠是異步的，通知以及實時監控這些鏈路所有均可以異步實現。設想若是所有都使用同步調用進行設計，如今淘寶的一個下單流程須要幾百個調用，若是全是同步的話，實現這樣的下單須要大概幾十s量級的時間，那麼淘寶爲何能作到下單以後當即就能成交，實際上是由於其後面所有鏈路都使用的是異步調用，而且只有在核心鏈路中某些最核心的交易環節中的幾個環節纔會使用同步調用。

在這裏分享一個可能給你們一些啓示的泰國電影，這個電影一共有三個主人公，父親，女兒和女兒的男友，當時女兒不顧家族和父親的反對必定要和男友交往，父親實在是拗不過女兒就贊成了，可是這個父親卻採起了一個很是殘酷的措施，把女兒和她的男友用手銬拴在一塊兒，因而天天不管吃飯仍是睡覺，天天任何行動女兒和男友都在一塊兒。最後的結果相信你們都猜到了，開始很是快樂，最後女孩的男友瘋了，在瘋以前將女孩殺死了，而父親也由於這個事情今後一蹶不振。這是一個真正的悲劇，人生是這樣，若是兩個事物太過於耦合在一塊兒的話就將是個悲劇。

設計程序架構也相似，若是你將全部程序都緊耦合的設計在一塊兒，對於這樣高度耦合的架構，相信在不久的將來隨着業務的發展，你所設計的系統也會成爲一個悲劇。真正的場景是在分佈式應用中，好比說應用中A和B兩個功能模塊，既但願他們解耦開，可是又但願他們互聯達到目標狀態。咱們不但願B不可用時候，A也不可用，這是目標。那麼爲了這個目標能採起什麼策略呢？編程

第一步，須要增長不少A和B的實例，可是這樣帶來的問題是鏈路也會增長，調用也會增長。由於A的配置或者B的配置要更改，那麼第二步就須要在A和B中間加一個負載均衡器，這是最傳統的作法，你增長多少，我就增長多少，你們互不關心對方的配置。緩存

第三點，當有一天作大促銷的時候，或者當你的客戶大量增多的時候，大量的流量到來，A的流量須要直接傳導到B。因此阿里在整個消息領域引出了一個很是重要的概念，叫作Topic或者Queue（隊列）。Topic其實也是基於隊列的，這個東西的做用是：第一負載均衡，第二點它能夠充當一個大的緩衝，這樣能夠把全部的流量緩存到Topic裏面。安全

舉個例子說明Topic的概念：這張圖有三部分，生產者，Topic和消費者。生產者生產的消息放到對應的Topic裏面，誰取了這個消息或者誰訂閱了這個消息就把消息拿走。實際上Topic的概念就像是變壓器，變壓器是220V的出來的也是這個流量，接入其餘的也是這個流量。這給最終設計系統帶來一個好處就是首先對於後面的這些應用而言，它們不會由於前面像洪水同樣的流量而被壓垮。第二個更爲重要的就是在設計整個系統的時候就不會有更多的成本浪費在這些旁枝末節的服務上。

再舉個例子，作秒殺業務時下單應用很是重要，對這個應用擴展了100臺機器，下面的通知好比發郵件的應用，需不須要也擴展100臺機器呢？實際上是不須要的，雖然仍是須要發郵件，可是能夠保證郵件以平穩的流量發送，只須要擴展5臺或者10臺來知足基本需求就能夠。這是兩個最大的好處，中間的這個Topic，也就是消息中間件就像一個萬能的變壓器同樣，即使大洪流來了通過它也變成比較順暢的流量。

接下來舉幾個現實中的例子探討一下到底哪些鏈路須要異步。

流程推動：就是作工做流或者審批流，再有就是訂單的流轉，下訂單，減庫存，使用優惠券結算，最終通知用戶或者訂單超時等等。這是第一點，流程推動是以前用的最多的。

定時消息：消息中間件MQ支持一個定時或者延時的消息，在電商裏面主要有兩種應用場景，一個是客戶下單30分鐘以後，訂單可能會斷定爲超時，因此在客戶下單以後須要異步發一條消息；而且在30分鐘以後，若是訂單尚未支付，就被斷定爲超時並將其關掉。另一個就是支付提醒，用戶下單以後10分鐘尚未支付，那麼會對其發送一個支付的提醒。這樣帶來的最大好處就是也能夠本身寫輪詢條件或定時程序，首先對訂單或這張表或者其餘的多個表進行輪詢，可是這些東西其實不須要去作，只須要發一個定時的消息就能夠了，觸發條件就會發送那個消息。

日誌監控：若是系統足夠大而且對實時性要求比較高，日誌所有要異步地放到實時計算的引擎裏面。

社交互動：如今Facebook用MQTT協議作社交，對於其餘相似微信的社交以及如今比較火的視頻直播聊天室，點贊送花買禮物等這種對於消息來講的巨大挑戰：首先要求實時性，好比在聊天室直播的過程當中送花的等待時間不能過長；其次是併發，芒果TV在超女100強比賽的時候也是用了視頻直播，包括熊貓TV在選熊貓女郎的時候也是，當聊天室裏忽然衝進去幾百萬人的時候，訂閱的關係就變得很是複雜，就是說我和你是好友，我發的東西，你應該能看見，可是我跟她不是好友，沒有訂閱關係，我又和某一個興趣組有訂閱關係，這樣就造成了多級的訂閱關係，這時候再發消息誰可見誰不可見就取決於訂閱關係是什麼樣的。若是我發的消息以後，一百萬人要同時都能接受到這個消息，這是對消息領域一個很是大的挑戰。微信

3、什麼是阿里雲MQ

阿里雲是如何解決這個問題的MQ這個產品已經有7年的歷史，而且MQ是通過雙十一幾千億條消息流量檢驗的。第二個就是這個產品在開源社區進行了部分的開源，由於第二階段須要擴展影響力，因此就將產品一部分進行開源，而開源版本的MQ也有不少電商在用。這就是MQ產品的歷史。

從商用的結果來看，阿里的消息隊列MQ應該是全球性價比最高的，由於它的計費很簡單，就只有API和Topic調用這兩塊費用。客戶建一個Topic就有一個資源佔用費，並且計費是階梯的，其餘的消息產品包括亞馬遜，微軟以，因爲收的消息有多種形成很難計算費用，好比要經過調用次數收費，網絡流量也須要收費，出口的費用，存儲的費用甚至積壓的費用都會收取，而阿里雲的MQ只收取API的調用費用和Topic的資源佔用費用，因此很清楚。

下圖是MQ的入口，整個產品都是在這個叫作阿里雲互聯網中間件裏面。互聯網中間件包括了企業級分佈式應用服務EDAS，消息隊列MQ和分佈式關係型數據庫服務DRDS。咱們的團隊是服務於整個阿里巴巴集團的，阿里系中大多數應用都在用咱們的中間件。網絡

再一張圖是主要控制檯界面，在這裏能夠進行Topic管理，發佈管理以及訂閱管理。查詢方面能夠進行Topic查詢，Message Key查詢和按照Message ID查詢，而且還有後面的報表，從這裏能得到好比10分鐘內TPS是多少，生產了多少消息，失敗了多少這樣的數據。還有監控報警，整個消息領域內有兩個數據最爲關鍵，一個是RT的時間，也就是發送消息的延遲，咱們能將其控制在1ms~5ms，這個數據是很是準實時的；第二個是堆積，當大流量到來時會堆積不少消息，堆積對不少消息是很重要的，有的消息中間件堆積了一億條消息，再將其從新拉取的時候將會使性能降低很是多。若是訂單的業務堆積了1000條就須要報警了，須要看看應用是否是已經報錯了，因此監控是一個很是重要的功能。多線程

阿里雲消息中間件的特色：

雙11驗證：MQ是通過了雙十一驗證的，MQ不是阿里看到了將來雲計算領域消息是很重要的部分而去開發的，這個徹底是阿里的業務需求加上七八年的技術沉澱下來的結果。
體系完善：阿里雲MQ的體系比較完善，首先咱們在內部產品名叫作MetaQ和Notify，同時有一部分是開源的，叫作RocketMQ，企業今天能夠去IOE，將來真的強大到能夠專門研究中間件，能夠轉移到開源的產品上去，這裏沒有技術綁定的風險。
高可靠和高性能：MQ對消息是多份存儲的，可靠性很是高。而且是高性能的，對於單機TPS，在此領域不少人說Kafka性能很高，可是實際上阿里雲MQ比Kafka的性能還要高，如今單機性能已經達到10萬TPS以上，也就是一秒鐘發十萬條以上信息，而且這僅是對於單機不是集羣。
多協議：MQ還支持多協議，不只支持TCP還支持HTTP以及MQTT，另外MQ還能夠像之前的傳統軟件同樣獨立部署，若是想不在雲上使用，而在本身的IDC環境中使用MQ也可行。

TCP VS HTTP VS MQTT：專業 VS 簡單 VS 物聯

在整個消息領域裏面，大概有這三個協議，對於支持TCP協議的消息，TCP的協議定義長鏈接是最穩定的，玩法也是最多的。在TCP上能夠作到「推拉結合」的方式，在消息裏面也有兩種基本傳遞的方式，一種是「拉」一種是「推」，淘寶以前使用「推」的方式，這樣比較快，可是你們後來發現這種方式就像是喂金魚，若是下游消費能力很差很容易被撐宕機，因此後來改成了「拉」的方式，而且將其作成相似「推」的方式，這時候「拉」的方式已經和「推」的方式效率上差很少了。「拉」的方式最大優勢就是下游消費端能夠按照本身消費能力控制消費進度，即便下游處理能力沒有那麼強，消息依然會循序漸進處理，可是毫不會崩潰。「推」的方式則是所有推給下游，很容易形成崩潰。

在物聯網和移動端就徹底不同了，由於終端不一樣，它的消息很小，因此採用真正「推」的方式，其次這樣的消息不會存很長時間，不少消息會被丟棄，不少場景應用「推」的方式。

HTTP相比TCP要慢不少，可是HTTP有好處，不少小衆語言包括GOLang，Python和PHP等都支持，你們對HTTP的接受程度很高，因此也會提供HTTP接入。

另外在整個消息領域有不少商業的也有不少開源的，有不少成熟的也有不少不成熟的，甚至幾我的用數月時間也能寫出一個消息中間件，可是這個就像學日語同樣，入門很簡單可是要想真正把消息中間件作到透沒那麼簡單，須要研究CPU,磁盤等等很深的東西。

MQ VS Kafka VS ActiveMQ

對比一下，MQ與以前提到的 Kafka，Kafka 基於日誌的場景，可是若是須要傳輸訂單的消息，好比金融報文，甚至對汽車遙控的消息，如要使用 Kafka 有效性就會低一些。另一個就是ActiveMQ，若是用ActiveMQ就會很簡單，但流量出現洪峯的時候，性能就會降低很是多。另外MQ在支持事務方面是其餘消息中間件所不具有的。MQ提供事務消息，應用與應用之間有服務的分佈式事務，數據庫之間也有多個分佈式事務，好比同時查50個庫，這種叫分佈式數據庫的事務。在消息領域也有分佈式消息，也叫做事務消息。就是在作本地事務和提交消息之間，把這兩階段聯動成一個事務，以前若是本身寫的話，須要判斷它的提交狀態，全部事物的回滾都須要本身作。MQ使用事務消息能保證操做的原子性，要麼全成功，要麼全失敗。

Kafka存儲侷限性：連接

MQ和Kafka 18項差別對比：連接

另外在阿里雲上面有兩個消息服務，MQ消息隊列和MNS消息服務，MQ是阿里雲專業的消息中間件，是阿里雙11使用的消息中間件，支持TCP、HTTP、MQTT三種協議。產品首頁：連接

應用場景解析：物聯網通用消息協議MQTT

消息隊列Message Queue可應用在多個領域，包括異步通訊解耦、企業解決方案、金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通訊、移動應用、手遊、視頻、物聯網、車聯網等。

而基於物聯網的應用是自然的基於消息的分佈式應用。消息是構建物聯網應用的基礎，每一個傳感器將成爲系統中的節點，節點之間依靠消息異步通訊。

物聯網消息解決方案=MQ+MQTT

物聯網消息解決方案的大體過程是這樣的，物聯網消息從終端上傳到雲上來，首先通過雲盾安全監測和SLB負載均衡，再到MQTT的網關進而進入核心服務，最終短信以及E-mail網關將這些數據發出去。

其中最重要的一點就是鏈路監控的功能。MQ消息中間件使用了鷹眼監控，能夠監控消息從哪一臺機器發出來，其RT時間爲多少秒，發到哪一個Topic，以後被那個訂閱組消費了，以後訂閱組下面有掛載了多少臺機器，哪一臺機器接入成功了，哪一臺接入失敗了，實現真正地監控消息軌跡，而不是讓用戶去查看日誌。

最後想說一點關於創業方面的，創業公司最重要的是試錯的能力和商業模式的驗證，使用中間件，使用異步解耦的消息可讓創業團隊，擁有快速試錯、快速創新的技術能力，可讓技術團隊專一業務應用開發，從而實現整個團隊的業務快速發展。

文章做者：馬雷（花名：阿仁）

編輯：賈子甲 (漫步~雲端) 、 Sheeta

用雲棲社區APP，舒服~

【雲棲快訊】紅軸機械鍵盤、無線鼠標等753個大獎，先到先得，雲棲社區首屆博主招募大賽9月21日-11月20日限時開啓，爲你再添一個高端技術交流場所詳情請點擊

評論文章 (2) (5) (5)

分享到: