鬆耦合的關鍵

系統架構就和公司架構、或政府架構、或生物體一樣，當規模很小、複雜度很低的時候，可以用單一控制中心的組織形式，強力地、完整地、完美地、精準地控制所有的流程。但是當系統的規模大、複雜度高的時候，如果還想用這種我所謂的控制狂（Control Freak）架構，系統反而容易失控，一個小的意外就會導致連鎖反應，延燒形成不可挽回的局面，導致系統錯亂甚至崩潰，這是必然的、早晚會發生的事情。

現代社會因為商業競爭和使用者太多等因素，導致系統需求多、需求複雜、需求經常需要改變、且牽涉因素太多，想要完美地控制流程難度越來越高。況且，控制狂的設計還會導致牽一髮動全身，風險非常高。從這個時代開始，設計分散式、鬆耦合的系統才是正確的道路。

鬆耦合的（loosely-Coupled）系統是由許多小巧的、自給自足的程式模組（連同其資料）組合起來的，好的微服務（microservices）設計也應該以此為設計原則。這些自給自足的程式模組可以隨時加入系統或者從系統中移除，不會造成系統太大的漣漪。模組動態加入、移除、更新，根據系統繁忙程度動態地複製模組實體來分擔任務，或消減模組實體來減少資源耗費，這些都是這類系統的日常，只要一開始設計的好，後面一點都不費勁。

當我們不設計一大塊的控制狂系統，改設計許許多多的鬆耦合模組聯合的系統時，我們馬上面臨一個問題：這些模組要如何彼此協作，還能夠保持彼此之間鬆耦合？答案是透過「訊息」的傳遞，這就是為什麼「訊息」在現代的系統中扮演很重要的角色。

當一個模組接收到訊息時，就會做出一些反應，反應的結果可能會產生數量不一定的訊息，這些訊息又進入到其他模組。就是在這些訊息的收發之間，許多模塊一同完成了一件更大的任務。所以說：鬆耦合的（loosely-Coupled）系統是由許多小巧的、自給自足的程式模組（連同其資料）組合起來的。

大量透過訊息來聯繫許多的模組，會面臨一個潛在的問題：訊息量太大的時候怎麼辦？使用訊息時，我們一般透過所謂的「傳訊中間系統」（messaging middleware）來傳遞訊息，以保持模組之間的鬆耦合。我們當然可以利用一個中央的傳訊中間系統來連上系統內的全部模組，但我不建議這麼做，因為如果訊息量很大，就算是叢集化（clustered）的中央傳訊系統，依然可能很快就抵擋不住大量訊息的狂風暴雨。

「微服務設計的十個步驟」一文提到第七步是「設計訊息瀑布」，就是用來解決這個問題的。我發明了一個「訊息瀑布」機制，來盡可能在設計之初就保留最大的彈性，抵抗訊息風暴。訊息瀑布機制的兩個重要的意義是：1. 讓訊息之間的上下游關係明確，避免訊息發生循環。2. 「傳訊中間系統」一開始就分割得很細，有助於後續的擴展。

訊息瀑布的設計重點是：1. 先把所有的訊息類型排列出來。2. 設計出數個「傳訊中間系統」，每個只經手某些類型的訊息，「傳訊中間系統」之間要有嚴格的上下游關係。3. 每個模組再根據各自關聯的訊息，連接到適當的「傳訊中間系統」，一個模組可以連接到不只一個傳訊中間系統。

儘管你的鬆耦合系統一開始可能沒有抵抗訊息風暴的需要，但我還是建議你一開始就設計訊息瀑布，總有一天老闆會稱讚你有先見之明的。

鬆耦合的系統，對我們在程式設計、架構設計、和維運方式等方面都提出挑戰，所幸的是，一旦我們通過了挑戰，我們就能進入一個美好的桃花源。這挑戰，值！