公司做的監控系統是基於 open-falcon 去開發的。open-falcon 裡用來讓 agent 這個 micro services 可以同時對數個資料庫送出「訊息」的模組叫 transfer 。而由於一些討論 micro services 的文章建議，如果 micro service 之間是做一對一的溝通適合用 RPC(remote procedure call) ，如果是 micro services 之間做一對多的溝通，則建議使用 message queue 。
於是，當我上回安裝過 rabbitMQ 之後，我就不自覺地去想，能不能用 rabbitMQ 來取代 transfer ？ 如果用 rabbitMQ 來取代 transfer 之後，可以有什麼好處？ 我在除錯 agent 的時候，常常需要做的一件事是，用 tcpdump 去看 RPC 裡傳輸的資料，透過這個動作才容易把錯誤的點加以定位。如果用了 rabbitMQ 的話，就可以有一個 web UI 介面，可以輕易地看到正在傳遞的「訊息」，而不需要 tcpdump 了。
常常嗆主管是資淺工程師的M大大聽完我的想法之後，終於按捺不住地來指導我了。他的指導主要有兩件事：
(1) 上述的需求是除錯(diagnostics)的問題。
既然如此，應該考慮從 log 的改進、或是自行設計更合用的 run time debug tool。引入一個有複雜功能 rabbitMQ 並不是用來解決「除錯」問題的好解法，更不是一種透過「改進系統的架構」來解決問題的解法。好的系統設計，確實可以減少錯誤。但是那個原因是在於「概念完整性」conceptual integrity 。
註：Conceptual integrity is the quality of a system where all the concepts and their relationships with each other are applied in a consistent way throughout the system.
(2) 抽象化可以解決問題，例如修改的彈性、或是程式的簡潔，但是抽象化也要付出代價。
M大大說著就提到了他找工作時，被考官質問的許多問題。「我在找求職時，有時候會被一些考官問一些莫名其妙的問題。例如，『你的前公司為什麼不用XX技術？XX技術不是OO大公司在用嗎？』這是什麼鳥問題？問這類問題的面試官一整個很像外行人。」
流行的技術或是工具背後，總是有力推的廠商或是社群，這些推廣技術的人，永遠只會講技術有多好，功能有多強。然而，從系統設計者的角度，要考慮的問題則是 trade off 。工具的功能再強不是重點，重點是適不適合解決手上的問題，還有解決問題需要付出什麼代價。
