https://github.com/fresh-tech-lab/fenix-study-group/issues/1

Table of Contents

原始分佈式時代

• 當時在設計分佈式環境時，需使服務調用、資源訪問、數據儲存等操作盡可能透明化、簡單化，使開發人員不必過於關注他們訪問的方法或資源是位於本地還是遠端。
• 礙於硬體效能的限制，設計必須作出妥協。若要開發一個良好且符合初衷的分佈式應用，對於開發人員又會有極高的要求。

單體系統時代

• 單體系統又稱「巨石系統 (Monolithic Application)」。

• 單體只是表明系統中主要的過程調用都是進程內調用，不會發生進程間的通訊。也就是說，對於所需資源，它都可以自給自足。

• "單體"不代表該系統"不分層"，還是可能 “水平分層” 與 “垂直分層”。也就是說可能會讓各層之間以不同形式的數據結構進行傳遞，或是功能、職責等拆分成許多模組。

  

• 單體的缺點在於：拆分之後的隔離與自治能力上的缺陷。如果任一個部分的程式碼過度消耗進程內的資源，造成的影響也將是全域性的、難以隔離的。

• 所有程式碼共享同一個進程內的資源，不能隔離也就無法做到單獨停止、更新、升級等等。所以，從可維護性來說，單體系統是不佔優勢的。

• 也會面臨難以技術異構的困難，也就是說，每個模組的程式碼都需要使用同一個程式語言、框架等技術去開發。

SOA 時代

• SOA = Service-Oriented Architecture
• 為了對大型系統拆分，讓每個子系統可以獨立的部署、運行、更新，也曾嘗試以下許多架構：

  • 煙囪式架構 (Information Silo Architecture)：

    • 訊息煙囪又稱"訊息孤島 (Information Island)"。指的是一種完全不與其他相關訊息系統進行互操作或協調工作的模式。
    • 但"子系統之間完全不互相通訊"這種事不太理想。

  • 微內核架構 (Microkernel Architecture)：

    

    • 也被稱為"插件式架構 (Plug-in Architecture)"。將各子系統使用到的主要數據、服務、資源等集中到一塊，成為所有業務系統共同依賴的核心 (Kernel, or Core System)，具體的業務系統以**插件模塊 (Plug-in Modules)**的形式存在。
    • 該架構假設系統中各個插件模塊之間是互不認識的，不可預知系統將安裝哪些模塊，因此這些插件不會直接交互。這一前提假設在許多場景中（如企業訊息系統或互聯網應用等等）都並不成立。

  • 事件驅動架構 (Event-Driven Architecture)：

    

    • 在子系統之間建立一套事件隊列管道 (Event Queues)，來自系統外部的訊息將以事件的形式發送至管道中，各個子系統從管道裡獲取自己感興趣、能夠處理的事件訊息，也可以為事件新增或修改其中的附加訊息，甚至可以自己發布一些新的事件到管道隊列中去。如此每個消息的處理者都是獨立、高度解耦的，但又能與其他處理者透過事件管道信行互動。