在线乱码卡一卡二卡新HD,最近韩国免费观看视频,国产色无码精品视频国产,亚洲男人的天堂久久香蕉

作者 | 葛賢亮，單位：中國移動智慧家庭運(yùn)營中心

(資料圖片)

?Labs 導(dǎo)讀

近年來，互聯(lián)網(wǎng)技術(shù)發(fā)展迅猛，各行各業(yè)的信息量急劇膨脹。隨著云計(jì)算和算力網(wǎng)絡(luò)時(shí)代的到來，消息中間件在國內(nèi)許多行業(yè)的關(guān)鍵應(yīng)用中越來越受到重視。在高并發(fā)分布式場景下，合理地利用消息中間件往往能起到突破性能瓶頸與化繁為簡的效果。

1 面向消息的中間件

在現(xiàn)代架構(gòu)設(shè)計(jì)領(lǐng)域內(nèi)，基于目的和實(shí)現(xiàn)機(jī)制，中間件可分為兩類：

基于遠(yuǎn)程過程調(diào)用(Remote Procedure Call, RPC)的中間件，允許一個(gè)應(yīng)用程序中的過程調(diào)用遠(yuǎn)程應(yīng)用程序中的過程，就好像它們是本地調(diào)用一樣。面向消息的中間件(Message-Oriented Middleware，MOM)，使分布式應(yīng)用程序可以通過發(fā)送和接收消息來進(jìn)行通信和交換數(shù)據(jù)。

這兩類模型都可以使一個(gè)本地組件通過網(wǎng)絡(luò)協(xié)議訪問（影響）另一個(gè)遠(yuǎn)程組件。區(qū)別在于RPC中間件調(diào)用遠(yuǎn)程組件時(shí)是同步操作，必須等待調(diào)用過程返回才能往下執(zhí)行。而MOM中間件則通過高效可靠的消息傳遞機(jī)制進(jìn)行異步數(shù)據(jù)傳輸。

同步與異步的差別導(dǎo)致了RPC模型中，本地組件（調(diào)用方）與遠(yuǎn)程組件（被調(diào)用方）必須同時(shí)處于運(yùn)行狀態(tài)，如果遠(yuǎn)程組件當(dāng)前處于升級或故障狀態(tài)，則RPC調(diào)用會失敗，此時(shí)需要本地組件實(shí)現(xiàn)數(shù)據(jù)緩存及重試機(jī)制以確保最終調(diào)用成功（也可以根據(jù)產(chǎn)品需求特性直接向用戶返回失敗提示）。而在MOM模型中，幾乎所有的消息中間件都實(shí)現(xiàn)了消息持久化功能，在本地組件發(fā)送消息至遠(yuǎn)程組件時(shí)，消息首先會被打包發(fā)送至通信服務(wù)器（Broker），通信服務(wù)器收到消息后會將消息進(jìn)行持久化，之后通過底層網(wǎng)絡(luò)將消息發(fā)送至遠(yuǎn)程組件，遠(yuǎn)程組件從消息隊(duì)列接口中讀取消息。

圖1 RPC調(diào)用

圖2 MOM調(diào)用

如上所述，基于MOM的系統(tǒng)實(shí)現(xiàn)了一種持久異步通信模式，允許組件進(jìn)行更松散的耦合，可在分布式場景下擴(kuò)展服務(wù)（進(jìn)程）間的通信，并支持異構(gòu)系統(tǒng)與多開發(fā)及時(shí)下流行的微服務(wù)架構(gòu)相輔相成，使業(yè)務(wù)系統(tǒng)具有良好的動態(tài)負(fù)載伸縮能力。

2 消息中間件作用

實(shí)際應(yīng)用場景中，消息中間件作為事件驅(qū)動架構(gòu)模式的一種實(shí)現(xiàn)，通過提供消息隊(duì)列模型和消息傳遞機(jī)制，也可以在分布式環(huán)境下提供應(yīng)用解耦、異步通信、流量削峰、彈性伸縮、冗余存儲、數(shù)據(jù)同步、最終一致性等功能。

2.1 應(yīng)用解耦/事件驅(qū)動

事件驅(qū)動架構(gòu)(Event Driven Architecture)是一種側(cè)重于以生產(chǎn)、消費(fèi)為基礎(chǔ)的分布式異步架構(gòu)模式?；谑录?qū)動架構(gòu)模式的應(yīng)用中，系統(tǒng)與系統(tǒng)之間可以通過消息傳遞的形式驅(qū)動業(yè)務(wù)，以流式的模型處理。其具有高并發(fā)、易擴(kuò)展、松耦合等特點(diǎn)。

相較于通過RPC直接調(diào)用（同步/異步），采用消息傳輸方式使生產(chǎn)者與消費(fèi)者依靠消息建立邏輯上的聯(lián)系，生產(chǎn)者與消費(fèi)者可歸屬于不同的系統(tǒng)。對于非核心流程，能夠?qū)⑵洳鸱种敛煌南M(fèi)者中，且支持后續(xù)的動態(tài)擴(kuò)展。消費(fèi)者對消息的消費(fèi)與否也不會影響生產(chǎn)者中的核心流程。

?示例：如在用戶注冊流程中，當(dāng)注冊成功后，系統(tǒng)需要發(fā)送郵件通知與短信通知。發(fā)送短信與發(fā)送郵件的調(diào)用邏輯都是寫在注冊方法中。用戶注冊模塊與短信模塊、郵件模塊強(qiáng)耦合。如果后續(xù)又有發(fā)送微信公眾號通知等需求時(shí)，只能去修改用戶注冊流程，與更多的模塊產(chǎn)生依賴關(guān)系。

圖3 應(yīng)用解耦-用戶注冊-消息隊(duì)列

但其實(shí)，在用戶注冊流程中，核心流程是用戶信息寫入，發(fā)送短信、發(fā)送郵件等操作都是由用戶注冊成功后觸發(fā)而來，若采用事件驅(qū)動風(fēng)格（消息/事件通知），用戶模塊作為生產(chǎn)者在用戶注冊成功后產(chǎn)生“注冊成功”事件消息，其他模塊作為消費(fèi)者訂閱該事件消息，則可以實(shí)現(xiàn)用戶模塊與其他模塊（短信、郵件）的解耦。由于生產(chǎn)者不關(guān)心事件的后續(xù)處理結(jié)果，消費(fèi)者模塊可根據(jù)實(shí)際情況選擇不同的調(diào)度策略，如并發(fā)處理、異步處理或按照閑時(shí)、忙時(shí)等狀態(tài)處理。

2.2 異步通信

將非核心流程異步化，可以減少系統(tǒng)響應(yīng)時(shí)間，提升吞吐量，從而提升用戶體驗(yàn)。例如：短信通知、APP推送等。

在消息中間件場景中，用戶通過前端頁面點(diǎn)擊注冊按鈕，平臺接收到請求后，在用戶模塊中執(zhí)行用戶注冊流程，注冊成功后，發(fā)送“注冊成功”事件消息至消息服務(wù)器(Broker)，短信模塊接收到事件消息后發(fā)送短信至用戶手機(jī)。

以上流程中，我們忽略掉部分細(xì)節(jié)，取主要步驟做以下假設(shè)，前端頁面到用戶模塊需耗時(shí)100毫秒，來回共200毫秒，用戶模塊執(zhí)行注冊流程需要耗時(shí)50毫秒，短信模塊執(zhí)行需要耗時(shí)100毫秒。此時(shí)短信發(fā)送流程由事件消息觸發(fā)，不會堵塞用戶注冊主流程，對于用戶來說，用戶注冊流程僅耗時(shí)250毫秒。而如果采用傳統(tǒng)調(diào)用方式，則需要耗時(shí)350毫秒。

圖4 異步通信

當(dāng)然RPC方式也可以實(shí)現(xiàn)異步模式，如本地組件A同步調(diào)用遠(yuǎn)程組件B，遠(yuǎn)程組件B收到請求后，將處理過程放置在異步線程池中處理，當(dāng)前線程則快速返回結(jié)果。這種方式下，一是要求遠(yuǎn)程組件B必須在線（否則會因超時(shí)返回調(diào)用失?。?，二是遠(yuǎn)程組件B中異步線程池執(zhí)行時(shí)可能因進(jìn)程重啟導(dǎo)致任務(wù)丟失（任務(wù)僅在內(nèi)存隊(duì)列中，未進(jìn)行持久化）。消息中間件的異步特性與消息持久化機(jī)制則不存在這兩個(gè)問題（此處指廣義上不存在，若消息中間件服務(wù)器故障也會出現(xiàn)生產(chǎn)者發(fā)送消息失敗的情況）。

2.3 流量削峰

在一些秒殺等互聯(lián)網(wǎng)電商場景中，當(dāng)上游系統(tǒng)的吞吐能力高于下游系統(tǒng)時(shí)，在流量洪峰時(shí)可能會沖垮下游系統(tǒng)。采用線程池方案時(shí)，雖然可以對用戶進(jìn)行快速返回，但任務(wù)都被堆積在線程池隊(duì)列中，造成內(nèi)存占用過大的及進(jìn)程重啟導(dǎo)致任務(wù)丟失問題。而消息中間件可以在峰值時(shí)堆積消息，而在峰值過去后下游系統(tǒng)慢慢消費(fèi)消息解決流量洪峰的問題。

?示例：用戶在支付系統(tǒng)成功結(jié)帳后，訂單系統(tǒng)會經(jīng)過短信系統(tǒng)向用戶推送扣費(fèi)通知。短信系統(tǒng)可能因?yàn)槎贪逍?yīng)，速度卡在網(wǎng)關(guān)上（每秒幾百次請求），跟前端的并發(fā)量不是一個(gè)數(shù)量級。因而，就形成支付系統(tǒng)和短信系統(tǒng)的處理能力出現(xiàn)差別化。此時(shí)可以把消息隊(duì)列當(dāng)成可靠的消息暫存地，進(jìn)行一定程度的消息堆積，下游系統(tǒng)可以根據(jù)自己的節(jié)奏獲取并處理消息。

2.4 最終一致性

一致性的概念來源于本地事務(wù)的ACID特性與分布式事務(wù)中的CAP理論，是指數(shù)據(jù)符合期望，相互關(guān)聯(lián)的數(shù)據(jù)之間不會產(chǎn)生矛盾。

CAP、ACID中討論的一致性稱為“強(qiáng)一致性”(Strong Consistency)，有時(shí)也稱為“線性一致性”（Linearizability，通常是在討論共識算法的場景中），而把犧牲了C的AP系統(tǒng)又要盡可能獲得正確的結(jié)果的行為稱為追求“弱一致性”。在弱一致性里，人們又總結(jié)出了一種稍微強(qiáng)一點(diǎn)的特例，被稱為“最終一致性”(Eventual Consistency)，它是指：如果數(shù)據(jù)在一段時(shí)間之內(nèi)沒有被另外的操作所更改，那它最終將會達(dá)到與強(qiáng)一致性過程相同的結(jié)果。

最終一致性不是消息隊(duì)列的必備特性，但確實(shí)可以依靠消息隊(duì)列來實(shí)現(xiàn)最終一致性。反之，如果需要強(qiáng)一致性，關(guān)注業(yè)務(wù)邏輯的處理結(jié)果，則使用RPC顯得更為合適。

使用消息中間件實(shí)現(xiàn)最終一致性可以有兩種方案：

方案一：本地消息表+補(bǔ)償機(jī)制。本地消息表用來確保任務(wù)不會丟失，補(bǔ)償機(jī)制通過不斷重試實(shí)現(xiàn)失敗消息最終被消費(fèi)成功。該方案需要注意消息重復(fù)與冪等設(shè)計(jì)。

方案二：使用RocketMQ自帶消息事務(wù)的消息中間件（消息事務(wù)并非銀彈，也同樣存在著其他分布式事務(wù)具有的缺陷）。

圖5 最終一致性-MQ 消息事務(wù)(RocketMQ)

3 消息中間件副作用

消息中間件帶來諸多好處的同時(shí)，也會引入很多的弊端：

系統(tǒng)可用性降低：系統(tǒng)可用性在某種程度上降低，比如要考慮消息丟失、消息中間件宕機(jī)等問題。系統(tǒng)復(fù)雜性提高：引入消息中間件之后，業(yè)務(wù)需要考慮消息被重復(fù)消費(fèi)、消息丟失、消息傳遞順序等問題。一致性問題：消息隊(duì)列的異步機(jī)制確實(shí)可以提高系統(tǒng)響應(yīng)速度，但消費(fèi)者沒有正確消費(fèi)可能會引入一致性問題。4 消息中間件組成

雖然各個(gè)消息中間件實(shí)現(xiàn)機(jī)制不一樣，但基本都會包含以下幾種角色：

Broker：消息服務(wù)器，提供消息核心服務(wù)，負(fù)責(zé)存儲/轉(zhuǎn)發(fā)消息（轉(zhuǎn)發(fā)模式分為 push 和 pull）；Producer：消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給 broker；Consumer：消息消費(fèi)者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理；Topic：主題，發(fā)布訂閱模式下的消息統(tǒng)一匯集地，不同生產(chǎn)者向topic發(fā)送消息，由MQ服務(wù)器分發(fā)到不同的訂閱者，實(shí)現(xiàn)消息的廣播；Queue：消息隊(duì)列，PTP（點(diǎn)對點(diǎn)）模式下，特定生產(chǎn)者向特定queue發(fā)送消息，消費(fèi)者訂閱特定的queue完成指定消息的接收；Message：消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)消息的傳輸。5 消息中間件協(xié)議5.1 JMS

JMS即Java消息服務(wù)(Java Message Service)應(yīng)用程序接口，是一個(gè)Java平臺中關(guān)于面向消息中間件(MOM)的API，用于在兩個(gè)應(yīng)用程序之間，或分布式系統(tǒng)中發(fā)送消息，進(jìn)行異步通信。它類似于 JDBC(Java Database Connectivity)。

? JMS由以下元素組成：

JMS提供者：連接面向消息中間件，JMS接口的實(shí)現(xiàn)。提供者可以是Java平臺的JMS實(shí)現(xiàn)，也可以是非Java平臺的面向消息中間件的適配器；JMS客戶：生產(chǎn)或消費(fèi)基于消息的Java的應(yīng)用程序或?qū)ο?；JMS生產(chǎn)者：創(chuàng)建并發(fā)送消息的JMS客戶；JMS消費(fèi)者：接收消息的JMS客戶；JMS消息：包括可以在JMS客戶之間傳遞的數(shù)據(jù)的對象；JMS隊(duì)列：一個(gè)容納那些被發(fā)送的等待閱讀的消息的區(qū)域。與隊(duì)列名字所暗示的意思不同，消息的接受順序并不一定要與消息的發(fā)送順序相同。一旦一個(gè)消息被閱讀，該消息將被從隊(duì)列中移走；JMS主題：一種支持發(fā)送消息給多個(gè)訂閱者的機(jī)制。

嚴(yán)格意義上來說，消息領(lǐng)域中的JMS更多的是一個(gè)規(guī)范而不是一個(gè)協(xié)議。ActiveMQ是該協(xié)議的典型實(shí)現(xiàn)。

5.2 AMQP

AMQP(Advanced Message Queuing Protocol)，一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級消息隊(duì)列協(xié)議，是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn)，為面向消息的中間件設(shè)計(jì)?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。

AMQP目前已經(jīng)推出協(xié)議1.0版本，實(shí)現(xiàn)此協(xié)議的比較知名的產(chǎn)品有 StormMQ、RabbitMQ、Apache Qpid等。RabbitMQ實(shí)現(xiàn)的AMQP版本是0.9.1，可通過plugin的方式支持1.0版本。

? 以下內(nèi)容摘自官網(wǎng)：

RabbitMQ implements version 0-9-1 of the AMQP specification in the core, with a number of extensions to the specification.

RabbitMQ implements AMQP 1.0 via a plugin. However, AMQP 1.0 is a completely different protocol than AMQP 0-9-1 and hence not a suitable replacement for the latter. RabbitMQ will therefore continue to support AMQP 0-9-1 indefinitely.

--來源：https://www.rabbitmq.com/specification.html

5.3 MQTT

MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸協(xié)議），是一種基于發(fā)布/訂閱(publish/subscribe)模式的“輕量級”通訊協(xié)議，該協(xié)議構(gòu)建于TCP/IP協(xié)議上，由IBM在1999年發(fā)布。

MQTT最大優(yōu)點(diǎn)在于，可以以極少的代碼和有限的帶寬，為連接遠(yuǎn)程設(shè)備提供實(shí)時(shí)可靠的消息服務(wù)。作為一種低開銷、低帶寬占用的即時(shí)通訊協(xié)議，使其在物聯(lián)網(wǎng)、小型設(shè)備、移動應(yīng)用等方面有較廣泛的應(yīng)用。

? RabbitMQ通過插件可以支持該協(xié)議。

圖6 MQTT應(yīng)用場景

5.4 STOMP協(xié)議

STOMP(Streaming Text Orientated Message Protocol)是流文本定向消息協(xié)議，是一種為MOM（Message Oriented Middleware，面向消息的中間件）設(shè)計(jì)的簡單文本協(xié)議。STOMP提供一個(gè)可互操作的連接格式，允許客戶端與任意STOMP消息代理(Broker)進(jìn)行交互。

STOMP協(xié)議的前身是TTMP協(xié)議（一個(gè)簡單的基于文本的協(xié)議），專為消息中間件設(shè)計(jì)。

STOMP是一個(gè)非常簡單和容易實(shí)現(xiàn)的協(xié)議，其設(shè)計(jì)靈感源自于HTTP的簡單性。盡管STOMP協(xié)議在服務(wù)器端的實(shí)現(xiàn)可能有一定的難度，但客戶端的實(shí)現(xiàn)卻很容易。例如，可以使用Telnet登錄到任何的STOMP代理，并與STOMP代理進(jìn)行交互。

5.5 XMPP

XMPP（可擴(kuò)展消息處理現(xiàn)場協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴(kuò)展標(biāo)記語言(XML)的協(xié)議，多用于即時(shí)消息(IM)以及在線現(xiàn)場探測。適用于服務(wù)器之間的準(zhǔn)即時(shí)操作。核心是基于XML流傳輸，這個(gè)協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時(shí)消息，即使其操作系統(tǒng)和瀏覽器不同。特點(diǎn)：通用公開、兼容性強(qiáng)、可擴(kuò)展、安全性高，但XML編碼格式占用帶寬大，是一種歷史悠久的協(xié)議。

5.6 自定義協(xié)議

有些特殊框架（如：Redis、Kafka、ZeroMq 等）根據(jù)自身需要未嚴(yán)格遵循MQ規(guī)范，而是基于TCP/IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進(jìn)行傳輸，實(shí)現(xiàn)了MQ的功能。

5.7 各協(xié)議簡單對比

圖7

6 總結(jié)

當(dāng)前，消息中間件技術(shù)已經(jīng)成為構(gòu)建分布式互聯(lián)網(wǎng)應(yīng)用的基礎(chǔ)設(shè)施。越來越多的系統(tǒng)使用消息中間件解決異步、解耦、削峰等難題。消息中間件不是一項(xiàng)新技術(shù)，但新的實(shí)現(xiàn)方案層出不窮，引入消息中間件時(shí)還需要根據(jù)自身的業(yè)務(wù)特性與需求選擇適合的方案。

參考文獻(xiàn)

[1]面向消息的中間件 (Message-Oriented Middleware, MOM)：https://docs.oracle.com/cd/E19148-01/820-0533/6nc927vst/index.html.

[2] 鳳凰架構(gòu)：http://icyfenix.cn/.?

關(guān)鍵詞： 用戶注冊 發(fā)送消息 異步通信 事件驅(qū)動