系統架構設計的原則和模式

1 分層架構

分層架構是最多見的架構，也被稱爲n層架構。多年以來，許多企業和公司都在他們的項目中使用這種架構，它已經幾乎成爲事實標準，所以被大多數架構師、開發者和軟件設計者所熟知。

分層架構中的層次和組件是水平方向的分層，每層扮演應用程序中特定的角色。根據需求和軟件複雜度，咱們能夠設計N層，但大多數應用程序使用3-4層。有太多層的設計會很糟糕，將致使複雜度的上升，由於咱們必須維護每一層。在傳統的分層架構中，分層包括 表現層、業務或者服務層，以及數據訪問層 。 表現層負責應用程序的用戶交互和用戶體驗（外觀和視覺）。一般咱們會使用 數據傳輸對象（Data Transfer Object） 將數據帶到這一層，而後使用 視圖模型（View Model） 渲染到客戶端。業務層接收請求並執行業務規則。數據訪問層負責操做各類類型的數據庫，每一個訪問數據庫的請求都要通過這一層。

分層無需知道其餘層如何去作，好比業務層無需知道數據訪問層是如何查詢數據庫的，相反，業務層在調用數據層的特定方法時，只需關注須要部分數據仍是所有數據。這就是咱們所說的 關注點分離 。這是很是強大的功能，每層負責其所負的責任。

分層架構中的核心概念是管理依賴。若是咱們使用依賴倒置原則和測試驅動開發(Test Driven Development)，咱們的架構會有更好的健壯性。由於，咱們要保證全部可能的用例都有測試用例。

咱們須要這樣的冗餘，即便業務層沒有處理業務規則，也要經過業務層來調用數據層，這叫 分層隔離 。對於某些功能，若是咱們從表現層直接訪問數據層，那麼數據層後續的任何變更都將影響到業務層和表現層。

 

分層架構中的一個重要的概念就是分層的開閉原則。若是某層是關閉的，那麼每一個請求都要通過着一層。相反，若是該層是開放的，那麼請求能夠繞過這一層，直接到下一層。

分層隔離有利於下降整個應用程序的複雜度。某些功能並不須要通過每一層，這時咱們須要根據開閉原則來簡化實現。

分層架構是SOLID原則的通用架構，當咱們不肯定哪一種架構更合適的時候，分層架構將是一個很好的起點。咱們須要注意防止架構陷入 污水池反模式 。這種反模式描述了請求通過分層，但沒作任何事或者只處理了不多的事。若是咱們的請求通過全部分層而沒有作任何事，這就是 污水池反模式 的徵兆。若是20%的請求只是通過各層，而80%的請求實際作事，這還好，若是這個比率不是這樣的，那麼咱們已經患上 反模式綜合徵 。

 

此外，分層架構能夠演變爲 巨石應用（Monolith） ，致使代碼庫難以維護。

分層架構分析：

• 敏捷性 ：整體敏捷性是指對不斷變化的環境做出反應的能力。因爲其總體風格（Monolith）的性質，可能會變得難以應對經過全部層的變化，開發者須要注意依賴性和分層分離。

• 易於部署 ：大型應用程序的部署會是個麻煩。一個小要求，可能須要部署整個應用程序。若是能作好持續交付，可能會有所幫助。

• 可測試性 ：使用Mocking和Faking，每一層能夠獨立測試，所以測試上很容易。

• 性能 ：雖然分層應用程序可能表現良好，可是由於請求須要通過多個分層，可能會存在性能問題。

• 可伸縮性 ：由於耦合太緊以及總體風格（Monolith）的天生特質，很難對分層應用程序進行伸縮。然而，若是分層可以被構建爲獨立的部署，仍是能夠具有伸縮能力的。可是，這樣作的代價可能很昂貴。

• 易於開發 ：這種模式特別易於開發。許多企業採用這種模式。大多數開發者也都知道、瞭解，而且能夠輕鬆學習如何使用它。

2 事件驅動架構

事件驅動架構（Event Driven Architecture）是一種流行的 分佈式異步架構 模式，用於建立 可伸縮的應用程序 。這種模式是自適應的，可用於小規模或者大規模的應用程序。事件驅動架構能夠與 調停者拓撲（Mediator Topology） 或者 代理者拓撲（Broker Topology） 一塊兒使用。理解拓撲的差別，爲應用程序選擇正確的拓撲是必不可少的。

調停者拓撲

調停者拓撲須要編排多種事件。好比在交易系統中，每一個請求流程必須通過特定的步驟，如驗證、訂單、配送，以及通知買家等。在這些步驟中，有些能夠手動完成，有些能夠並行完成。

一般，架構主要包含4種組件，事件隊列（Event Queue）、調停者（Mediator）、事件通道（Event Channel）和事件處理器（Event Processor）。客戶端建立事件，並將其發送到事件隊列，調停者接收事件並將其傳遞給事件通道。事件通道將事件傳遞給事件處理器，事件最終由事件處理器處理完成。

 

事件調停者不會處理也不知道任何業務邏輯，它只編排事件。事件調停者知道每種事件類型的必要步驟。業務邏輯或者處理髮生在事件處理器中，事件通道、消息隊列或者消息主題用於傳遞事件給事件處理器。事件處理器是自包含和獨立的，解耦於架構。理想狀況下，每種事件處理器應只負責處理一種事件類型。

一般，企業服務總線、隊列或者集線器能夠用做事件調停者。正確選擇技術和實現可以下降風險。

代理者拓撲

不像調停者拓撲， 代理者拓撲 不使用任何集中的編排，而是在事件處理器之間使用簡單的隊列或者集線器，事件處理器知道處理事件的下一個事件處理器。

 

因其分佈式和異步的性質， 事件驅動架構 的實現相對複雜。咱們須要面對不少問題，好比網絡分區、調停者失敗、從新鏈接邏輯等。因爲這是一個分佈式且異步的模式，若是你須要事務，那就麻煩了，你得須要一個 事務協調器 。 分佈式系統 中的事務很是難以管理，很難找到標準的工做單位模式。

另外一個充滿挑戰的概念是契約。架構師聲稱服務的契約應該預先定義，而應變是很是昂貴的。

事件驅動架構分析：

• 敏捷性 ：因爲事件和事件處理器之間解耦，而且可獨立維護，所以這種模式的敏捷性很高。變化能夠快速、輕鬆地完成，而不會影響整個系統。

• 易於部署 ：因爲架構是解耦的，所以很容易部署。組件能夠獨立部署，而且能夠在調停者上註冊。部署在代理者拓撲上也至關簡單。

• 可測試性 ：雖然獨立測試組件很容易，但測試整個應用程序頗有挑戰。所以端到端的測試是很難的。

• 性能 ：事件驅動架構性能很是好，由於它是異步的。此外，事件通道和事件處理器能夠並行工做，由於它們是解耦的。

• 可伸縮性 ：事件驅動架構的伸縮性很是好，由於組件之間解耦，組件能夠獨立擴展。

• 易於開發 ：這種架構的開發不是很容易。須要明肯定義契約，錯誤處理和重試機制得處理得當。

3 微內核架構

微內核架構（Microkernel architecture）模式也被稱爲 插件架構（plugin architecture） 模式。這是產品型應用程序的理想模式，由兩部分組成： 核心系統 和插件模塊 。核心系統一般包含最小的業務邏輯，並確保可以加載、卸載和運行應用所需的插件。許多操做系統使用這種模式，所以得名微內核。

插件彼此獨立，所以解偶。核心系統持有註冊器，插件將本身註冊其上，所以核心系統知道哪裏能夠找到它們以及如何運行它們。

 

這種模式很是適合桌面應用程序，可是也能夠在Web應用程序中使用。事實上，許多不一樣的架構模式能夠做爲整個系統的一個插件。對於產品型應用程序來講，若是咱們想將新特性和功能及時加入系統，微內核架構是一種不錯的選擇。

微內核架構分析：

• 敏捷性 ：因爲插件能夠獨立開發並註冊到核心系統，微內核架構具備很高的敏捷性。

• 易於部署 ：依賴於核心系統的實現，能作到不須要從新啓動整個系統來完成部署。

• 可測試性 ：若是插件開發是獨立的，測試就能夠獨立且隔離地進行。還能夠Mock核心系統來測試插件。

• 性能 ：這取決於咱們有多少插件在運行，但性能能夠調優。

• 可伸縮性 ：若是整個系統被部署爲單個單元，這個系統將難以擴展。

• 易於開發 ：這種架構不容易開發。實現核心系統和註冊會很困難，並且插件契約和數據交換模型增長了難度。

4 微服務架構

儘管微服務的概念還至關新，但它確實已經快速地吸引了大量的眼球，以替代總體應用和麪向服務架構（SOA）。其中的一個核心概念是具有高可伸縮性、易於部署和交付的獨立部署單元（Separately Deployable Units）。最重要的概念是包含業務邏輯和處理流程的服務組件（Service Component）。拿捏粒度設計服務組件是必要而具備挑戰性的工做。服務組件是解耦的、分佈式的、彼此獨立的，而且可使用已知協議來訪問。

微服務的發展是由於總體應用和麪向服務應用程序的缺陷。總體應用程序一般包含緊耦合的層，難以部署和交付。好比，若是應用程序總在每次應對變化時垮掉，這是一個因耦合而產生的大問題。微服務將應用程序分解爲多個部署單元，所以很容易提高開發和部署能力，以及可測性。雖然面向服務架構很是強大，具備異構鏈接和鬆耦合的特性，可是性價比不高。它很複雜、昂貴，難於理解和實現，一般對於大多數應用程序來講矯枉過正。微服務簡化了這種複雜性。

 

跨服務組件的代碼冗餘是徹底正常的。開發微服務時，爲了受益於獨立的部署單元，以及更加容易的部署，咱們能夠違反DRY原則。其中的挑戰來自服務組件之間的契約，以及服務組件的可用性。

微服務架構分析：

• 敏捷性 ：因爲服務組件能夠各自獨立開發，彼此沒有耦合，所以微服務架構具備很高的敏捷性。獨立部署單元可以對變化做出迅速的反應。

• 易於部署 ：相比其餘的架構模式，微服務的優點是服務組件便是單獨部署單元。

• 可測試性 ：服務組件的測試能夠獨自完成。微服務的可測試性很高。

• 性能 ：依賴於服務組件和這種特定模式的分佈式性質。

• 可伸縮性 ：獨立部署單元自然具有很好的伸縮性。

• 易於開發 ：每一個服務組件能夠各自獨立實現。

https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247484493&idx=1&sn=1f4433d08a42e8ea53a1c99545a57489&chksm=fbb28db3ccc504a5cb1d68f320865c62c0159574d65004e32912e80c61d2319d25d78fb07564&mpshare=1&scene=1&srcid=0224Maz4s6stgNgFihBAgFAW&key=819d0d70e718cb3683600c532ab633542d457009ef5350bbada96c2ec3fa5c28ff5707291f23d503a6dd69137ae867bea6d40099dc093b292bed02292a3106e64056ea4c6bdd2c9fcb2a5b18128cd272&ascene=0&uin=OTIwNjc0MTU%3D&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.12.4+build(16E195)&version=12010110&nettype=WIFI&lang=zh_CN&fontScale=100&pass_ticket=tr9ThSjWvhTKVvoxS06JQ7ltNk%2BtCz60yYV5xG08%2F%2Bk%3D