如何利用qpid建構分布式總線

和所有基于Broker總線一樣，qpid本身架構是聯邦制的總線叢集，這意味着，一份資料需要在多個broker之間互相備份。這個架構是AMQP定義的，本身并沒有什麼問題，因為AMQP是為交易而生的，對資料準确可靠的要求遠遠超過對性能的要求。

    我們看到在很多公有雲中，也經常使用AMQP的另外一個實作RabbitMQ。和qpid一樣，這兩者之間基本可視為等價，知識每個供應商有所偏好，但各項名額不會有太大差别。我比較傾向于使用qpid，就像我現在要改造qpid，就沒有什麼難度。而RabbitMQ是Erlang實作的，開發者比較少，想定制的難度還是比較大。

    qpid是叢集，中心模式的總線，利用他建構分布式總線是否可行，在判斷這個解決方案之前，我們來一一讨論下分布式總線的幾個關鍵要素。

    1、分布式總線必須在各個節點上，有能夠獨立運作的總線執行個體。毫無疑問，qpid沒有問題。

    2、執行個體之間必須能夠互相通訊，這一點qpid是有缺陷的。首先qpid是client和broker分離的，而broker和broker之間是通過AMQP定義的聯邦協定建構叢集。當節點數量不斷增加時，叢集的資料同步複制機制，在性能上顯然就要拖後腿，是以在這個方向上，需要做改變。

    3、提供一緻性服務的協調器，這個不在AMQP的定義範圍内，qpid顯然也不具備。那麼就必須額外引入這塊。

    4、消息隊列。分布式架構并不必然要求消息隊列，但作為總線而言，基本都要基于消息隊列。而qpid本身就是AMQP的一個實作，是以消息隊列，以及其複雜的管理功能都具備。

    5、服務注冊，尋址。這塊qpid已經具備大部分功能，Exchange、Queue的名字，可以等同于服務注冊和執行個體的内部尋址功能。但跨執行個體之間，還必須借助于格外的伺服器。幸運的是，qpid提供了一套管理機制，非AMQP協定，可以實時得到執行個體中Exchange和Queue名字和其他屬性的變化。

    綜上所述，qpid作為總線的一種實作，已經具備了完整的功能。但要擴充到分布式架構，顯然還不夠，主要還要加入一緻性協調器，跨執行個體尋址，消息隊列拷貝三個關鍵特性。除了一緻性協調器外，其他在項目本身就可以找到合适的代碼複用。而一緻性協調器可以簡單地基于zookeeper或者etcd等開源項目，稍加改造就可以了。

    換句話說，将叢集模式的qpid改造成分布式架構的總線沒有想象中的那麼難。工作量比較大的還是如何分解qpid，在《qpid-lite，一個清晰版的qpid-amqp》一文中，也給大家展示過qpid代碼結構中的問題，不過這個問題已經得到了解決，在此基礎上重構qpid為分布式架構，還是要簡單了許多。