- 數據庫 和 消息隊列 的區別？
- 那 消息隊列 怎麼工作呢？
- 微服務架構是什麼？
- 同步通信的弊端？
一句話説完就是，消息隊列 就是解決 微服務架構 的應用程序，各模塊傳遞數據的雜七雜八的問題的！
本文完整版原文地址： https://www.ccgxk.com/emlog_dev/621.html
（PS: 現在有了 AI 作圖，做一些內容技術插圖真好用)
今天用一個單線的講述，把前 100 年講一下：
首先，先説一下數據庫。
就像 Postgres MongoDB MySQL 這種數據庫，是用於持久儲存數據的。
這個【消息隊列】也差不多，也是存數據的。
其實可以這樣來理解。
- 數據庫 是 一個倉庫。
- 消息隊列 是 一個順豐快遞公司。專業用於傳遞數據！
數據庫 和 消息隊列 的區別？
對於 第一個，數據庫。它生來設計，就是容納很多不同種類的物品的，比如數字、字母編號、秘鑰、文章.... 而且一般是為了存放很久的。跟倉庫一樣。
對於 第二個，消息隊列。內容會短暫進行存儲，但不會留很久，而是發放到它要去的地方。但也要保留足夠長的時間，以便能穩定發送到下一個地點。就跟一個順豐快遞一樣。
【消息隊列】的核心本質就是這樣：生產者和顧客之間的一個傳輸媒介，一箇中介。生產者生產 messages 消息，顧客 接收。
那 消息隊列 怎麼工作呢？
生產者 和 顧客 之間，會通過 消息隊列 協議，也就是 STOMP、AMQP、MQTT 這類這樣工作。
一般我們很喜歡在 微服務架構 （microservices） 裏各個系統間的通信裏使用 這個 消息隊列 協議。
微服務架構是什麼？
先説一下最原始的 monolith application ，我們國內常翻譯其為 單體架構。
單體架構 是指 整個代碼庫 都包含在一個應用程序裏。小項目一般都這樣，本身也沒多少代碼嘛.....
都放到一個程序裏，那必然開發、測試、部署都容易。
但程序一直開發迭代，架構會出現很多問題。即便採用了模塊、結構，將其拆分的很細..... 依然止不住代碼變得混亂。尤其是 bug，出現一點 bug ，就可能牽一髮動全身！
於是就引入了 微服務，將單一的多功能大應用，拆分成幾個小應用。每個小應用，只幹它自己的事！
其中最顯著的優點，就是 bug 隔離，書面化語言就是 故障隔離機制 。不會一個小 bug 把整個系統弄宕機了。
第二個優點，就是你各管各的，跟電路板電子一樣，使用不同的技術棧、做各種亂七八糟的優化。尤其也提現在 擴容 上，應用跑通了，發小財了，擴容就容易了，只需要根據需要擴充某部分就行。
我們的主題，消息隊列，就天然適合 微服務 之間的數據通信！
同步通信的弊端？
説一下 微服務 之間原來最常用的通信方式：
同步通信：也就是最常用的 REST API 接口風格，用 xml json 調來調去。但你要注意，是同步的。如果中間出現 bug，程序會翻車。
而今天這個 消息隊列 是異步的，A 給 B 送了一個「順豐快遞包裹」，無需等待迴應，直接會從 順豐 那裏得到一個簡單的回執，然後就該幹啥就幹啥，默認 B 已經收到了，不管了。
消息隊列 的另一個好處是，即便任務激增，消息隊列 內部也會有緩存機制，是一個專業的消息傳遞服務，能防止你的服務器過載，會慢慢根據性能，將消息一一傳遞出去。
總之，消息隊列 就是一個專業的幹傳遞信息、內容的 程序。
畢竟，之前那種什麼 json 那種，太簡陋了。一出 bug 就宕了。
