開發訊息方案不是輕鬆的事，在正式環境維運這樣一套方案同樣充滿挑戰：一套訊息式整合方案一天可能產生、路由與轉換成千上萬、甚至數百萬則訊息。我們得應付例外、效能瓶頸與參與系統的變動；更棘手的是，元件分散在許多平台與機器上，還可能位於多個地點。

架構師的美夢，開發者的惡夢#

除了整合分散式套裝與自製應用程式本身的複雜度與規模之外，鬆散耦合這個架構優點，其實讓測試與除錯更難了。

Martin Fowler 稱之為「架構師的美夢、開發者的惡夢」症候群：鬆散耦合與間接這些架構原則減少了系統對彼此的假設、因而帶來彈性；但要測試一個「訊息生產者不知道消費者是誰」的系統，是很有挑戰的。

再加上訊息的非同步與時間面向，事情更複雜：

• 訊息方案可能根本沒設計成讓生產者收到接收端的回覆訊息
• 訊息基礎設施通常保證送達，卻不保證送達時間

這讓「依賴訊息送達結果」的測試案例很難寫。

兩種監控層次#

監控訊息方案時，我們可以在兩個抽象層次追蹤訊息：

• 系統管理——監控「送了多少則訊息」「一則訊息花多久被處理」。這類方案除了表頭中的訊息識別碼或 Message History 等欄位之外，不檢視訊息資料。
• 商業活動監控（Business Activity Monitoring, BAM）——聚焦於訊息中的酬載資料，例如「過去一小時所有訂單的金額總和」。

本章許多模式通用到兩種用途都能用。但因為商業活動監控本身就是一個全新領域，且與資料倉儲有許多共通的複雜度（本書完全沒觸及），作者決定在系統管理的脈絡下討論這些模式。

本章的三個部分#

監控與控制#

• Control Bus（控制匯流排）——為分散式方案提供單一控制點。它把多個元件連到一個中央管理主控台，主控台能顯示各元件狀態、監控流經元件的訊息流量，也能向元件送出控制命令（例如改變訊息流）。
• Detour（繞道）——我們可能想讓訊息多走幾個步驟（驗證或記錄），但這些步驟會帶來效能開銷。Detour 讓我們能透過控制匯流排把它們開開關關。

觀察與分析訊息流量#

• Wire Tap（竊聽器）——在不影響主要訊息流的前提下檢視訊息內容。
• Message History（訊息歷程）——除錯訊息式系統時，知道某則訊息去過哪裡幫助極大；訊息歷程提供這項能力，卻不在元件之間引入相依。
• Message Store（訊息儲存庫）——Message History 綁在個別訊息上，而中央的訊息儲存庫能提供**「每一則穿越系統的訊息」的完整帳目**。兩者結合，就能分析訊息在系統中所有可能的路徑。
• Smart Proxy（智慧代理）——Wire Tap、Message History 與 Message Store 幫我們分析訊息的非同步流動；但要追蹤送往請求－回覆服務的訊息，就得在訊息串流中插入一個 Smart Proxy。

測試與除錯#

• Test Message（測試訊息）——上線前測試訊息系統是好主意，但測試不該就此打住。你應該主動驗證運行中的系統是否正常運作——作法是定期把測試訊息注入系統並驗證結果。
• Channel Purger（通道清除器）——元件故障或行為異常時，通道上很容易留下不想要的訊息。測試時把通道上殘留的訊息清乾淨非常有用，以免受測元件收到「上一輪剩下的」訊息。