你的分布式應用真的需要那么多同步調用么?-轉自阿里中間件


摘要: 在5月17日舉辦的2016雲棲大會·武漢峰會上阿里中間件產品專家馬雷(阿仁)就阿里中間件MQ做了精彩的演講,告訴大家:阿里中間件團隊的目標是讓消息“傳”無邊界。本文也就為什么使用消息中間件,消息中間件的核心場景進行了分享。相信阿仁的分享會讓大家對分布式應用的異步調用有更加深刻的了解。精彩不要錯過!

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

大家仔細思考一下,我們所做的整個分布式系統中有多少鏈路是同步調用的,又有多少鏈路又應該是異步調用的呢?比如在一個下單流程中,有多少核心鏈路是使用同步調用的,有多少需要異步調用?

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

一、為什么使用消息中間件

1.雲是地基

先問一個問題:為什么要使用消息中間件?現在開發分布式應用系統,很少有人從頭開始寫代碼,因為現在已經不是一個人憋在酒店里寫一個軟件就可以成功的年代了,現在往往需要團隊作戰,而且還有可能從更大的角度來講,是一個生態在作戰,並且你所在的生態有可能和其他的生態存在競爭的關系。那什么是中間件呢?

用現實生活類比來講,現在房價賣的很高,以前賣房子該怎么去賣?開發商需要先買塊地基,然后在地基上搭建個框架,最終將其裝修完了以后賣給客戶。現在賣房子怎么賣呢?可以直接用現成的框架,無論最終客戶想要裝修成寫字間也好,別墅也好,公寓也好,都可以快速地賣給客戶,快速實現資金回籠。所以這里有一個理念是:雲實際上就是一個地基,用戶不需要去搞自己的IDC。

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在選熊貓女郎的時候也是,當聊天室里突然沖進去幾百萬人的時候,訂閱的關系就變得非常復雜,就是說我和你是好友,我發的東西,你應該能看見,但是我跟她不是好友,沒有訂閱關系,我又和某一個興趣組有訂閱關系,這樣就形成了多級的訂閱關系,這時候再發消息誰可見誰不可見就取決於訂閱關系是什么樣的。如果我發的消息之后,一百萬人要同時都能接受到這個消息,這是對消息領域一個非常大的挑戰。

三、什么是阿里雲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,之后被那個訂閱組消費了,之后訂閱組下面有掛載了多少台機器,哪一台機器接入成功了,哪一台接入失敗了,實現真正地監控消息軌跡,而不是讓用戶去查看日志。

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM