單體 V/s 分布式架構，你看明白了嗎？
在軟件領域，存在多種架構風格可供選擇，我們需要關注不同架構風格帶來的風險。選擇符合業務需求的架構風格是一個長期迭代的過程。
架構風格可以分為兩大主要類型：單體架構（將所有代碼部署在一個單元中）和分布式架構（通過遠程訪問協議連接多個部署單元）。它們又可以進一步細分為以下多個子架構風格，如下所示。
單體架構
- 分層架構
- 流水線架構
- 微內核架構
分布式架構
- 基于服務的架構
- 事件驅動架構
- 空間驅動架構
- 面向服務的架構
- 微服務架構
后期我將上述每種架構風格寫一個獨立的博客。這篇將專注于對架構風格的更廣泛分類，并試圖了解在使用這些架構時涉及的優缺點。
單體架構
當從零開始進行軟件開發時，通常會首先采用單體架構風格。這可能是默認選擇或意外選擇，因為在初始階段，架構師很難對適當的架構風格做出決策。對于小型、簡單的應用程序或網站，這種架構風格是一個不錯的選擇。
這種風格支持的分層機制是技術和領域級別的。以下是在此風格中使用的不同分區：
- 展示層 - 負責用戶界面和處理用戶輸入。
- 業務邏輯 - 執行應用程序的核心業務邏輯。
- 數據庫訪問 - 負責訪問數據庫的數據訪問對象。
- 應用程序集成 - 與其他服務進行集成（例如通過消息傳遞或REST API）
為什么要使用這種風格？
- 小型應用程序的不錯選擇。
- 在項目初期非常方便使用。
- 適用于預算緊張和時間有限的情況。
- 大多數開發人員和架構師都相當簡單和熟悉。
- 成本較低，對于架構師在分析業務需求和要求時還不確定使用哪種風格時是一個不錯的選擇。
為什么不使用這種風格？
隨著應用程序的增長，可維護性、敏捷性、可測試性和可部署性等特性會受到不利影響。第二個要注意的因素是架構下沉反(sinkhole_ ani)模式，當請求在各層之間以簡單的透傳處理方式進行傳遞，而在每個層內部沒有執行任何業務邏輯時，這種反模式會出現。
分布式架構
分布式架構風格雖然在性能、可擴展性、可部署性和可用性方面比單體架構風格強大得多，但是為了實現這種強大性能，也存在一些需要權衡的考慮。
在本節中，我們將討論與分布式架構風格相關的謬論。
謬論：
網絡可靠。
不能假設網絡總是可靠的(最近的電信信號事件)。眾所周知，網絡隨著技術的發展變得更加可靠，但網絡仍然普遍不可靠。考慮下圖
服務B可能完全正常，但由于網絡問題，服務A無法與其建立聯系?；蛘吒愀獾氖?，服務A向服務B發送了一個處理請求，由于網絡問題，沒有收到響應。系統越依賴網絡，就越有可能變得不可靠。
延遲為零
在討論網絡變得更快的觀點時，往往會忽視這個謬論。但是考慮一種情況，即在單體架構中，層與層之間的調用在本地進行，延遲只有納秒級，但在切換到分布式架構后，本地調用變為遠程調用，延遲增加到毫秒級。下面的圖表中進行了解釋。
帶寬是無限的
當使用單體架構風格時，這個謬論并不成立，因為組件之間的大部分調用都是本地方法調用。但是，當系統分布在遠程位置并需要通過REST調用進行通信時，情況就會發生變化。
請參考下面的圖表，其中服務A依賴于服務B來滿足用戶請求。對于單個請求，這可能是一種不錯的體驗。但是考慮到有數千個并發請求針對同一個查詢，這將導致網絡變慢，間接消耗帶寬，增加調用之間的延遲。
網絡是安全的
由于使用了虛擬專用網絡（VPN）、安全網絡和可信網絡等，大多數軟件人員往往忽視了這個謬論。但是網絡并不安全，在切換到分布式架構時，安全性變得更加具有挑戰性。威脅和攻擊的表面積增加了一個數量級。
拓撲永遠不會改變。
這個謬誤指的是整個網絡拓撲結構，包括整個網絡中使用的所有路由器、集線器、交換機、防火墻、網絡和設備。不要假設拓撲是固定的并且永遠不會改變。事實上，它是會發生變化的，而且變化是常態。
只有一個管理員
在分布式架構中，從來沒有單一的管理員。架構師需要與多個管理員合作和溝通，以維護整個生態系統的健康。由于單一部署單元的特性，單體架構風格不需要這種程度的溝通或協作。
傳輸成本為零
這里的傳輸成本不是指延遲，而是指與進行單個REST調用相關的實際成本。與單體架構相比，分布式架構在硬件、服務器、網關、防火墻、新子網、代理等方面的成本要高得多。
網絡是同質的
網絡并不只由一個網絡硬件供應商構成。而且，并非所有這些異構的硬件供應商之間都能很好地協同工作。這反過來會影響網絡的可靠性、延遲以及對帶寬的假設。
