消息隊列為什么要使用消息隊列解耦擴展性異步通信……消息隊列要解決的其它問題送達保證流量控制/緩沖保證時序主要的使用舉例場景（概念圖）單模塊對單模塊Waybill推送訂單給區域模塊用來排線使用。主要的使用舉例場景（概念圖）單模塊對多模塊（多消息類型）三體需要發送線路任務和每日運力，同時用于時效監控和財務。多模塊對單模塊（多消息類型）問題和風險下游模塊之間相互影響（消費能力）。存在消息優先級問題。（優先級的定義？）需要同時接收多數據類型。rabbitmq的概念和特點用戶權限控制的粒度為VirtualHost（可以理解為命名空間）。所有的數據都只能發送給rabbit的exchange。Exchange分為三種模式：fanout，direct，topic。在發送和接收數據的時候要指定queuename。可以持久化數據。只有pull的方式。有ack的機制。rabbitmq的解決方案下游模塊之間相互影響每個模塊使用獨立的queue（name），模塊之間無干擾。沒有辦法接收多種數據類型。rabbitmq的解決方案同時接收多種數據類型單個隊列可以接收多種不同類型的數據。存在嚴重的優先級問題。封裝策略其他模塊在架構中對rabbitmq無感：將pull的方式修改成push的方式。pusher根據下游使用方式的要求，可以同時接一個或者多個queuequeuename由Pusher來自行決定，下游不關注。屏蔽了rabbitmq奇怪的noack機制解決多下游的競爭機制不完善的。（消息會亂序）增加了轉運功能，將單條1*N的數據拆分成N*1的數據，然后下發。隊列的接收方需要自行決定數據是繼續處理還是跳過。隊列的接收方需要保證自己的邏輯冪等+可重入。解決方案（PHP）未封裝的功能沒有主動數據回放的機制。不區分完全時序和相對時序。封裝之后的使用（PHP）21:8095/display/beeper/rabbitmqExchange：每個模塊獨立一個exchange，exchange按照模塊名稱命名，exchange不允許在代碼中自動創建。在Pusher新增Queue：命名方式exchange.功能.下游名稱，允許代碼自動創建。漫話架構絕對原創，一笑了之為什么大家都想做架構師掙錢多好跳槽讓別人覺得牛X可以對小弟呼來喝去更多……全宇宙中最常出現的架構web代碼Mysql架構（Architecture）框架（Framework）什么是軟件架構軟件架構不是軟件，而是關于軟件設計的一種決策。架構是問題的抽象解決方案，它主要關注大局。軟件架構定義系統的技術選型。軟件架構決策如何將軟件系統分解成不同的部分，以及各個部分之間的交互關系。軟件架構約束整個系統的數據流。經過完整的開發過程之后，這些架構決策將要體現在最終開發出的軟件系統中。架構師存在是為了什么做設計決策為設計決策失敗承擔責任為開發不到位引起的失敗承擔責任為測試不到位引起的失敗承擔責任為性能不滿足引起的失敗承擔責任為穩定性不滿足引起的失敗承擔責任為所有最終交付之前出現的任何技術錯誤導致的失敗承擔責任成功架構師需要具備的XX經驗權利能力前瞻性變通運氣TMS的架構設計原則優先業務功能：分析真實的業務需求。業務后續的可能演進方向。將業務需求轉變成通用的技術需求其他的考慮：盡量少依賴第三方和開源。和外部功能解耦。在需求的基礎上做少量的技術規劃。新建派車單和對外API接口（PM）政策需要新建立派車單和配送點。要求可以通過API接口和外部系統交互。要求可以根據派車單維度查詢司機的在途位置。對策需要承載派車單和訂單數據實體和邏輯。需要規劃新的模塊API接口對外，為了安全性，需要添加鑒權機制，為了擴展和部署。在代碼和邏輯上都獨立開派車單維度查詢位置。派車單的執行主體是司機，所以將數據維度轉換成按照司機+時間保存。語言/存儲和公司統一node.js+mongodb。功能之間對數據庫的訪問獨立。派車單模板、排線和地址查詢功能（PM）政策創建派車單太麻煩，需要只填寫一次，創建一堆。要求引入訂單的概念。要求支持排線功能。排線需要依賴坐標，需要地址和坐標轉換功能。對策公司語言限制放開，php+mysql。派車單模板生成派車單，放在一模塊（node.js+mongodb）。訂單，直接新模塊。新增區域，區域不是運單的屬性，也和司機無關，繼續新加模塊，單獨管理區域。有區域才能落點排線，排線和區域放一起。落點和訂單需要交互，但是不要求實時性，添加隊列，業務解耦。地址轉轉換涉及到很多人工的維護，直接獨立，方便后續獨立添加人工地址審核功能和地址檢索功能。Node.js+mongodb遷移php+mysql（架構）政策原有的Node.js模塊線上各種超時日志，搞不定，換之…跨數據庫查詢，獲取數據的時候想死的心都有了。對策平移Node.js+mongodb的所有功能。派車單和訂單一直綁定出現，放在一個模塊。司機位置，在關系數據庫中需要考慮數據量問題，按照天分表。保證開發速度，協議依舊選擇HTTP。時效+異常功能（開發+PM）政策時效產品派車單+訂單維度的異常監控和預警。對策時效，怎么看都和現在的東西不相關，也不在規劃范圍內，隨便找個地方丟吧…時效需要依賴運力，引入隊列。異常監控，這么重要的功能，又和