脈絡：如同 Message History 所述，鬆散耦合這個架構原則帶來方案的彈性，卻讓我們難以洞察整合方案的動態行為。

讓訊息強大的性質，也讓它難管理#

非同步訊息保證送達，卻不保證何時送達。但對許多實務應用而言，系統的回應時間可能極為關鍵；知道「某段時間內有多少訊息穿過系統」也可能很重要。

Message History 展示了「能說出訊息來源」的價值——從這些資料我們能推導出有趣的訊息吞吐量與運行時間統計。

要做有意義的報表，我們得把訊息資料持久化地、集中地儲存起來。

解法#

作法是善用訊息基礎設施的非同步本質：把訊息送到通道時，同時把一份副本送到一個特殊通道，由 Message Store 收集。這可以由元件自己做，也可以在通道中插入一個 Wire Tap。

我們可以把「承載訊息副本的次要通道」視為 Control Bus 的一部分。以「送出後就不管」的模式送第二則訊息，不會拖慢主要應用訊息的流動。

該存多少細節#

而且即使我們把所有訊息資料都存下來，報表能力仍可能受限：訊息通常共用相同的表頭結構，但訊息內容的結構各不相同，因此我們未必能輕易針對訊息中的資料元素做報表。

兩種儲存選項#

因為每種訊息的資料都不同，我們得考慮不同的儲存方式：

• 為每種訊息型別各建一套儲存結構（例如資料表），與該型別的資料結構相符——這樣就能加索引、對訊息內容做複雜搜尋。

但這假設我們為每種訊息型別都有獨立的儲存結構，可能成為維護負擔。

• 把訊息資料以 XML 格式當成非結構化資料存進一個長字元欄位——這給我們一套通用的儲存結構。

我們仍能查詢表頭欄位，但無法針對訊息內文中的欄位做報表；不過一旦找出了某則訊息，就能依儲存的 XML 文件重建訊息內容。

別忘了清除機制#