和所有基於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爲分佈式架構，還是要簡單了許多。