上一篇提到訊息代理 Message Broker 的基本用途，而這篇我們進一步來看看 Message Broker 兩種不同的 Pattern。

在討論系統設計時，我們時常會聊到 Message Queue，我最初分不太清楚 Message Queue 和 Message Broker 有什麼差別，也不太懂一種叫做 Pub-Sub 的行爲和 Queue 是否有關聯。

更甚者，我還聽過類似 Pub-Sub 的名詞：Producer-Consumer，當時這又讓我更困惑了，究竟他們有什麼不同？因此，今天就來釐清這些不同的概念和名詞吧！

過去人們的溝通方式主要是透過口語及書信交流，遠距離的溝通效率低下，而且很容易受到環境的影響。但現代社會中，只要有網路覆蓋的地區，我們的資訊都能透過 TCP/IP 的架構所傳遞，效率相對於過去提高了非常多。

但是在此架構下，我們需要考慮的事情也多了許多。例如要思考傳送訊息時對方是否在線上？不在時該怎麼處理；如果傳送的訊息一下太多，系統負荷不了該怎麼辦？

由於訊息傳遞的速度太快，我們不能依靠人工來決策並處理，而是需要一套完整的邏輯來處理這些瑣事，以下便來整理我學習 System Design 時，關於傳遞訊息時需要考量的重要設計：訊息代理。

聊到建立監控機制來維護上線的服務，我們可以收集系統的指標如 CPU、RAM 的使用率來確認某一時間內的系統狀態，也可以定期儲存 API Request 的 Response Time、QPS 來觀察系統的效能有沒有被影響。

那麼，這些 Metrics 都是怎麼被我們所收集的呢？又有哪些 Monitoring 的工具及服務可以使用？我們今天就來聊聊這個話題。