qpid是一個偉大的軟件，apache社區的頂級項目絕非徒有虛名。從2012年開始使用至今，在線上從未發生過事故，一直穩定運行。但從一個20年職業老鳥的角度來看源碼的話，還是存在不少問題。一個直觀的判斷，qpid項目組應該是一羣寫java的程序員轉行寫c++代碼，我在qpid項目源碼中，看到太多java的編程技巧，或者他們是c++深度踐行者。
一、源碼結構問題
1、代碼複雜高。qpid的功能強大，各種輔助功能繁多。在覈心代碼之外，使用多種依賴組件，導致編譯難度增大。雖然qpid使用了cmake降低了編譯時，環境配置問題，但組件的編譯配置問題，同樣也會引起qpid的編譯困難。
2、模塊化不清晰。在整個qpid-cpp代碼中，源碼的目錄劃分得很清晰，有sys，types，framing、client，messaging、broker、qmf這幾塊。但項目引用源文件時，交叉情況卻很嚴重，這種情況可以從項目文件中可以看出來，這意味着模塊化編寫和測試時，會存在關聯影響。特別是qpidcommon項目，簡直是一個全家桶的項目。
3、嵌套層次過深。在面向對象的封裝上，qpid項目可謂應用到極致。有兩個技巧用得很頻繁，一個是殼對象和Impl的分離，一個是接口和實現的分離。理論上，這並沒有什麼可以指摘的，但應用得太多，就會適得其反，以至於調用鏈過長，造成性能損失嚴重。
4、多重繼承應用。和Java單根繼承不同的是，C++支持多重繼承。多重繼承優劣就不在這裏展開，在我的編程和項目管理實踐中，一般不允許使用多重繼續，即使是用空類接口也不允許，主要原因在於容易發生錯誤，而且不容易閱讀。確保繼承關係是樹狀單向，在邏輯上會簡單很多，減少錯誤。
5、內存拷貝次數多。客戶端的性能通常沒有那麼苛刻，但是對於總線來說，它的客戶端實際上就是服務，那麼對性能的要求就不一樣了。qpid客戶端在內存拷貝上，沒有做太多的優化，從message到content到frame，再到最後發往網絡，中間歷經多次內存拷貝。這些也導致在整體性能上有較大的損失。
二、項目結構調整
1、項目簡介。qpid-lite的項目地址：
https://github.com/QuarkCloud/qpid-lite.git ，這個項目目前只支持qpid的客戶端。qpid-lite在出發點上，並不是爲了優化性能，而是爲了更好地研究qpid的實現，所以將非關鍵代碼摒棄掉，緊緊圍繞調用鏈，釐清各個模塊、文件、類之間的關係。
2、項目結構。繼承qpid的調用邏輯，將全家桶式的common拆分，同時去掉messaging項目，將原先的代碼劃分爲，qpid-sys，qpid-types，qpid-framing，qpid-amqp，讓每個項目之間有清晰的調用關係。而qpid-amqp0_10和qpid-amqp1_0兩個項目，繼承自qpid-amqp，是AMQP0-10和AMQP 1.0的實現。
3、其他項目說明。qpid-driver是從qpid-client繼承而來，爲
qpid-amqp0_10服務，同時刪除不需要的文件。qpid-proton是來自於proton-core項目，因爲qpid使用proton支持AMQP 1.0，由qpid-amqp1_0調用。
4、改造方法說明。
（1）、整理原始項目文件vxproj，將包含關係整理清楚，根據調用耦合度，將文件歸類到自洽的項目中，特別是qpidcommon項目。
（2）、清理qpidmessaging和qpidclient，拆分成amqp0_10和amqp1_0兩個項目，支持不同的協議。通過協議註冊機制，由qpid-amqp管理。
（3）、通過上面兩步，清理了文件的依賴關係，讓他們分別耦合到各個項目中。在項目內部，跟蹤調用關係，刪除非關聯文件，特別是qpid-client項目，qpid對amqp0_10的支持，主要通過qpid-client項目。
（4）、qpid-framing項目比較獨立，基本沒有改動。它主要定義的是amqp0_10的命令。
（5）、qpid-proton項目式純c編寫，支持amqp1_0，比較獨立。沒有動，只清理關聯性不高的文件。