本篇是故事五的「查證」篇。
本篇要回答：非同步命令的調查需要保存哪些證據？每一份證據能證明什麼、不能證明什麼？
Day 21 把「成功」拆成八層之後，下一個問題是：每一層拿得出什麼證據？整理下來發現，非同步系統其實是收據最多的系統——只是每張收據都只蓋自己那一段的章。
我曾把「Broker 回了確認」當成強證據。它確實是證據，但只證明「訊息進了訊息系統」，對「設備動了沒有」毫無發言權。誤把傳輸層收據當成執行層證明，是非同步事故調查最常見的偷換——跟 Day 14 把「語法合法」當「資料正確」是同一個錯誤的分散式版本。
非同步命令的證據保存清單，以及每張收據的效力範圍：
| 證據 | 能證明 | 不能證明 |
|---|---|---|
| 發布時間、Topic／Channel／Queue、Payload | 送了什麼、往哪送、何時送 | 有沒有人收 |
| QoS 或傳遞保證等級 | 傳輸層承諾的強度 | 應用層有沒有處理 |
| Message ID／Command ID | 這一件事的唯一身分，全鏈路對帳的鑰匙 | 本身不證明任何進度 |
| Broker／訊息系統確認 | 訊息進入了訊息系統 | Subscriber 收到與否 |
| Subscriber 接收紀錄 | 訊息到達了應用程式 | 處理成功與否 |
| 處理開始／結束時間 | 應用程式做了處理 | 設備接受與否 |
| 設備回應與狀態 | 設備的表態 | 外部效果是否真的發生 |
| 外部效果證據（狀態對帳、感測回讀） | 使用者要的結果發生了 | ——這是唯一能結案的一張 |
| 逾時、重試與取消紀錄 | 異常路徑走過哪些分支 | —— |
這張表同時回答了 Day 21 的介面之爭：publish() 當下手上只有前三、四行的收據，而需求方要的是倒數第二行。中間隔著的每一行，都需要時間與回路才能補齊。
區分證據等級。已確認事實：各層證據的效力邊界由架構性質決定，與具體協定無關。去識別化說明：當時各層實際的紀錄格式不列出，以通用欄位呈現。
本篇結論：
每一張收據只能證明它負責的那一段，不能拿傳輸確認代替遠端執行結果。
下一篇（Day 23）把收據串成一條命令生命週期：一個指令要走過多少層，才有資格說完成？
iThome鐵人賽
看影片追技術