軟件架構模式

閱讀《clean architecture》也花了較長的時間，大體也瞭解到整潔的架構要作到如下兩點：

• well-isolated components：component是獨立部署的最小單元，由一系列遵循SOLID原則的module按照REP、CCP、CEP原則組成。
• dependency rule：低層的detail去依賴高層的police

但感受並無對架構設計給出可行的參考。

clean architecture 中的架構實例

在《clean architecture》的第34章 「The Missing Chapter」（由 Simon Brown 編寫）給出了一個具體的案例，用四種架構設計來實現一個 「online book store」。

package by layer

這是最多見的方案，從前日後分爲：前端、後臺（business logic）、持久化DB。

優勢是：簡單、容易上手，符合大多數公司的組織架構。

存在的問題：

• 軟件規模和複雜度增長時，三層架構就不夠了，須要從新考慮拆分；
• 分層架構體現不出business domain；

PACKAGE BY FEATURE

垂直切分方案，全部的java代碼都放在一個package裏面

好處在於凸顯domain concept

PORTS AND ADAPTERS

clean architecture這本書推薦的方案, 外層依賴於內層的domain

PACKAGE BY COMPONENT

本章做者 Simon Brown 提出的方案，service-centric view，將全部相關的職責打包稱一個粗粒度的Jar包

bundling all of the responsibilities related to a single coarse-grained component into a single Java package

看起來相似如今微服務的部署方式

對於以上四種結構，依賴關係看起來是這樣的

值得注意的是

• 虛線箭頭表示component之間的依賴關係
• PORTS AND ADAPTERS這種架構更能體現domain（business logic），即接口命名爲Orders而不是OrdersRepository

本章的做者最後還指出：++無論架構怎麼設計，粗心的implementation均可能違背最初的設計；依賴編譯器來保證架構的一以貫之，而不是自我約束或者過後檢查。++

五種常見架構模式

看完了clean architecture後，在網上搜索架構設計相關的書籍，發現了software architecture patterns這本小冊子，篇幅很短，稱不上book，而是一個report。

software architecture patterns 指出缺少架構設計的軟件每每高度耦合，難以改變。所以，這本小冊子的目標就是介紹經常使用架構模式的特色、優勢、缺點，幫助咱們針對特定的業務需求作出合適的選擇。

Layered Architecture

分層架構也稱爲n-tire architecture，這是最爲常見的一種架構模式，通常從前日後分爲四層：presentation, business, persistence, and database。以下圖所示：

分層架構通常是一個新系統的最佳首選，由於其完美匹配傳統IT公司組織架構：通常的公司招人都是前端、後端、數據庫。

分層架構的優勢在於關注點隔離（separation of concerns），每一層作好本身這一層的職責，並向上一層提供服務便可，最爲經典的案例就是七層網絡模型，這有利於開發、測試、管理與維護。

分層架構中，須要注意的是兩個概念：closed layer、open layer

closed layer的核心就是不要越層訪問，好比在上圖中，Presentation Layer就不該該跨國Business Layer直接去Persistence Layer訪問數據。

A closed layer means that as a request moves from layer to layer, it must go through the layer right below it to get to the next layer below that one

closed layer保證了層隔離（ layers of isolation），使得某一層的修改影響的範圍儘量小，比較可控。但closed layer有時候也會帶來一個問題：architecture sinkhole anti pattern（污水池反模式），具體是指，爲了查簡單數據，層層轉發請求。好比爲了在展現層顯示玩家的某個數據，須要經過業務層、再到持久化層、再到DB層；取到數據再一層層傳遞回來，在這個過程當中，業務層並無對數據有邏輯上的處理。

顯示，污水池反模式衝擊了closed layer的美好想法。如何衡量這種層層轉發的請求是否是問題，能夠參考80-20法則。

若是80%是附帶邏輯的，那麼就是ok的，但若是有80% 是 simple passthrough processing，那麼就得考慮讓某些layer open。好比在複雜的業務系統中, 常常會有一些可複用的邏輯，這個時候會抽取爲通用的服務層(service layer)。以下圖所示

open layer 、close layer的概念能夠幫助理清楚架構和請求流程之間的關係，讓架構師、程序員都清楚架構的邊界（boundary）在哪裏，重要的是，這個open-closed關係須要明確的文檔化，不要隨意打破，不然就會一團糟。

Event-Driven Architecture

The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications.

從上述定義能夠看出事件驅動架構的幾個特色：分佈式、異步、可伸縮。其核心是：高度解耦合、專注職責的事件處理單元(Event Processor)

事件驅動架構有兩種常見拓撲結構： the mediator and the broker.

Mediator Topology

須要一箇中心化（全局惟一）的協調單元，用於組織一個事件中的多個步驟，這些步驟中有些是可並行的，有些必須是順序執行的，這就依賴Event Mediator的調度。以下圖所示

Broker Topology
這種是沒有中心的架構

the message flow is distributed across the event processor components in a chain-like fashion through a lightweight message broker

以下圖所示

事件驅動的好處在於，高度可伸縮、便於部署、總體性能較好（得益於某些事件的併發執行）。但因爲其分佈式異步的本性，其缺點也很明顯：開發比較複雜、維護成本較高；並且很難支持事務，尤爲是一個邏輯事件跨越多個processor的時候。

Microkernel Architecture

微內核架構又稱之爲插件式架構（plug-in architecture）。以下圖所示：

微內核架構包含兩部分組件

• a core system
• plug-in modules.

plug-in modules 是相互獨立的組件，用於增長、擴展 core system 的功能。

這種架構很是適用於 product-based applications 即須要打包、下載、安裝的應用，好比桌面應用。最經典的例子就是Eclipse編輯器，玩遊戲的同窗常常下載使用的MOD也能夠看出插件。

微內核架構一般能夠是其餘架構的一部分，以實現特定部分的漸進式設計、增量開發

Microservices Architecture Pattern

微服務架構並非爲了解決新問題而發明的新架構，而是從分層架構的單體式應用和SOA（service-oriented architecture）演化而來。

微服務解決了分層架構潛在的成爲單體式應用（Monolithic application）的問題：

through the development of continuous delivery, separating the application into multiple deployable units

同時，微服務還經過簡化（泛化）服務的概念，消除編排需求，簡化對服務組件的鏈接訪問。從而避免了SOA的各類缺點：複雜、昂貴、重度、難以理解和開發。

The microservices architecture style addresses this complexity by simplifying the notion of a service, eliminating orchestration needs, and simplifying connectivity and access to service components.

微服務架構以下：

其核心是service component，這些服務組件相互解耦，易於獨立開發、部署。服務組件的粒度是微服務架構中最難的挑戰

• 太大：失去了微服務架構的優點
• 過小：致使須要編排，或者服務組件間的通訊、事務。

而微服務架構相比SOA而言，其優點就在於避免依賴和編排 -- 編排引入大量的複雜工做。

對於單個請求 若是service之間還要通訊，那麼多是就是粒度太小。解決辦法：

• 若是通訊是爲了訪問數據：那麼能夠經過共享db解決
• 若是通訊是爲了使用功能：那麼能夠考慮代碼的冗餘，雖然這違背了DRY原則。在clean architecture中也指出，component的自完備性有時候要高於代碼複用。

Space-Based Architecture

基於空間的架構，其核心目標是解決因爲數據庫瓶頸致使的低伸縮性、低併發問題。

分層架構中，在用戶規模激增的狀況下，數據層的擴展每每會成爲最後的瓶頸（相對而言，前端和業務邏輯都容易作成無狀態，比較好水平擴展）。而基於空間的架構的核心是內存複製，根本上解決了這個問題。

High scalability is achieved by removing the central database constraint and using replicated in-memory data grids instead

架構以下：

其核心組件包括

• processing unit，處理單元，其內部又包含一下組成
  • business logic
  • in-memory data grid
  • an optional asynchronous persistent store for failover
  • replication engine，用於同步數據修改
• virtualized middleware
  • Messaging Grid: 監控processing unit可用性，路由客戶端請求到processing unit
  • Data Grid: 核心，負責processingunit之間的數據同步，毫秒級同步？
  • Processing Grid: 可選組件，若是一個請求須要多個processing unit的服務，那麼負責協調分發
  • Deployment Manager： 負責processing unit的按需啓停

基於空間的架構不多見，並且從上面的核心組件描述來看的話，開發和維護應該都是比較負責的，因爲是數據的同步這塊。並且因爲數據都保存在內存中，那麼數據量就不能太大。

基於空間的架構適用於需求變化大的小型web應用，不適用於有大量數據操做的傳統大規模關係型數據庫應用

references

clean architecture

software architecture patterns