分布式開發－－分布式訊息中介軟體__訊息中介軟體

當前各種 RPC 中介軟體技術已經廣泛應用於各個領域。其中，伺服器之間訊息通訊這種功能廣泛應用於這些中介軟體中，於是，將這種面向訊息的中介軟體（ Message Oriented Middleware ， MOM ）抽象出來，形成通用的訊息中介軟體，成為業內主流。目前訊息中介軟體的標準主要有： JMS 和 AMQP 。實現則是百花齊放。

訊息中介軟體從功能上需要解決以下問題：

 

1． 同步或非同步訊息傳輸，尤其是非同步訊息傳輸

同步發送訊息是發送訊息後，阻塞等待訊息是否發送成功的回饋，如果設定有逾時時間，則逾時後跳出阻塞狀態。

非同步發送訊息是發送訊息後，不阻塞立即執行其他動作。如果關心訊息是否發送成功，則可以通過回呼函數（Java 中的 Listener ）處理訊息是否成功。

 

2． 訊息的安全性，訊息中介軟體對持久的支援

在分布式系統中，訊息從發送到接收，環節非常多，沒有任何一個環節是安全的，而任何環節出了問題，都會導致丟訊息。當有需求是，我們必須保證在不是絕對安全的多環節裡，完成訊息安全的傳輸。這其中，訊息中間的持久是非常重要的。

 

3． 訊息的重發性

如果使用的系統保證了等冪性，則對此沒有要求。否則，有些情境需要保證訊息不重發。在既要保證訊息安全，又要保證訊息不重發，是非常困難的。目前業內還沒有人能解決此問題。

目前，在有訊息重發的情況下，使用的系統都是使用狀態機器保證了系統對訊息的等冪性。

 

4． 訊息的順序性

如果使用的系統有要求，則有可能需要保證訊息的順序。在大規模分布式不可靠環境下，在保證訊息傳輸高效和訊息安全的情況下，要解決此問題，也是非常困難的。

如果只是小規模的系統，對效能要求不高，可以以伺服器時間為準，使用排隊隊列即可解決。

如果以發送端時間為準，並且保持順序的訊息由此一個發送端發送，則使用訊息序號即可解決。

另外，有些系統只需要滿足局部的訊息順序性，在排序訊息數量不大的情況下，可以使用多條排序訊息一次性發送解決。

 

5． 訊息傳輸模型：點對點的傳輸訊息（ PTP ），訂閱 / 發布模型（ Pub/Sub ）

PTP ，就是你在訊息方設定訊息接收者的唯一識別碼，然後，訊息發送方和訊息接受方建立一一對應的關係。訊息發送方發送所有的訊息都被訊息接收方接收。

 

Pub/Sub ，就是訊息發送方和訊息接收方都確定自己的發送和接收訊息的標籤（或者你可以理解為組 GroupID），所有有這個標籤的訊息，訂閱了這個標籤的訊息接收方一定能接收到。

 

 

JMS （ Java Message Service， Java Message Service ）是專用於 J2EE 的一種訊息中介軟體規範。它主要做了介面上的規範，訊息傳輸模型和訊息類型的規範，並沒有給予實現。同樣，它也完全沒有給出伺服器端的架構，你甚至可以不使用伺服器直接在用戶端之間傳輸訊息（雖然可能最終結果只是一個玩具）。http://java.sun.com/products/jms/docs.html 。 JMS 也沒有規定訊息的順序，安全，重發等特性。

 

AMQP （進階訊息佇列協議， The Advanced Message Queuing Protocol ）是一種和語言無關的，在金融行業使用的新興訊息中介軟體，目前成為訊息中介軟體圈內關注的焦點。與 JMS 規範了 API 不同，它是一個非同步訊息傳遞所使用的應用程式層協議規範。 AMQP 的原始用途只是為金融界提供一個可以彼此協作的訊息協議，而現在的目標則是為通用訊息佇列架構提供通用構建工具。 http://www.amqp.org/

目前開源的訊息佇列有：kafka一般用於日誌採集，RocketMQ，rabbitMq， 淘寶開源分布式訊息中介軟體Metamorphosis， 訊息中介軟體分為推模式和拉模數式，推模式：推送給消費者就ok，拉模式：消費者主動輪訓訊息佇列，微服務系統開發訊息非同步處理是不可缺少的環節