閱讀《clean architecture》也花了較長(zhǎng)的時(shí)間，大致也了解到整潔的架構(gòu)要做到以下兩點(diǎn)：

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

但感覺并沒有對(duì)架構(gòu)設(shè)計(jì)給出可行的參考。

clean architecture 中的架構(gòu)實(shí)例

在《clean architecture》的第34章 “The Missing Chapter”（由 Simon Brown 編寫）給出了一個(gè)具體的案例，用四種架構(gòu)設(shè)計(jì)來實(shí)現(xiàn)一個(gè) “online book store”。

package by layer

這是最常見的方案，從前往后分為：前端、后臺(tái)（business logic）、持久化DB。

優(yōu)點(diǎn)是：簡(jiǎn)單、容易上手，符合大多數(shù)公司的組織架構(gòu)。

存在的問題：

• 軟件規(guī)模和復(fù)雜度增加時(shí)，三層架構(gòu)就不夠了，需要重新考慮拆分；
• 分層架構(gòu)體現(xiàn)不出business domain；

PACKAGE BY FEATURE

垂直切分方案，所有的java代碼都放在一個(gè)package里面

好處在于凸顯domain concept

PORTS AND ADAPTERS

clean architecture這本書推薦的方案, 外層依賴于內(nèi)層的domain

PACKAGE BY COMPONENT

本章作者 Simon Brown 提出的方案，service-centric view，將所有相關(guān)的職責(zé)打包稱一個(gè)粗粒度的Jar包

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

看起來類似現(xiàn)在微服務(wù)的部署方式

對(duì)于以上四種結(jié)構(gòu)，依賴關(guān)系看起來是這樣的

值得注意的是

• 虛線箭頭表示component之間的依賴關(guān)系
• PORTS AND ADAPTERS這種架構(gòu)更能體現(xiàn)domain（business logic），即接口命名為Orders而不是OrdersRepository

本章的作者最后還指出：++不管架構(gòu)怎么設(shè)計(jì)，粗心的implementation都可能違背最初的設(shè)計(jì)；依賴編譯器來保證架構(gòu)的一以貫之，而不是自我約束或者事后檢查。++

五種常見架構(gòu)模式

看完了clean architecture后，在網(wǎng)上搜索架構(gòu)設(shè)計(jì)相關(guān)的書籍，發(fā)現(xiàn)了software architecture patterns這本小冊(cè)子，篇幅很短，稱不上book，而是一個(gè)report。

software architecture patterns 指出缺乏架構(gòu)設(shè)計(jì)的軟件往往高度耦合，難以改變。因此，這本小冊(cè)子的目標(biāo)就是介紹常用架構(gòu)模式的特點(diǎn)、優(yōu)點(diǎn)、缺點(diǎn)，幫助我們針對(duì)特定的業(yè)務(wù)需求做出合適的選擇。

Layered Architecture

分層架構(gòu)也稱為n-tire architecture，這是最為常見的一種架構(gòu)模式，一般從前往后分為四層：presentation, business, persistence, and database。如下圖所示：

分層架構(gòu)一般是一個(gè)新系統(tǒng)的最佳首選，因?yàn)槠渫昝榔ヅ鋫鹘y(tǒng)IT公司組織架構(gòu)：一般的公司招人都是前端、后端、數(shù)據(jù)庫。

分層架構(gòu)的優(yōu)點(diǎn)在于關(guān)注點(diǎn)隔離（separation of concerns），每一層做好自己這一層的職責(zé)，并向上一層提供服務(wù)即可，最為經(jīng)典的案例就是七層網(wǎng)絡(luò)模型，這有利于開發(fā)、測(cè)試、管理與維護(hù)。

分層架構(gòu)中，需要注意的是兩個(gè)概念：closed layer、open layer

closed layer的核心就是不要越層訪問，比如在上圖中，Presentation Layer就不應(yīng)該跨國(guó)Business Layer直接去Persistence Layer訪問數(shù)據(jù)。

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有時(shí)候也會(huì)帶來一個(gè)問題：architecture sinkhole anti pattern（污水池反模式），具體是指，為了查簡(jiǎn)單數(shù)據(jù)，層層轉(zhuǎn)發(fā)請(qǐng)求。比如為了在展示層顯示玩家的某個(gè)數(shù)據(jù)，需要通過業(yè)務(wù)層、再到持久化層、再到DB層；取到數(shù)據(jù)再一層層傳遞回來，在這個(gè)過程中，業(yè)務(wù)層并沒有對(duì)數(shù)據(jù)有邏輯上的處理。

顯示，污水池反模式?jīng)_擊了closed layer的美好想法。如何衡量這種層層轉(zhuǎn)發(fā)的請(qǐng)求是不是問題，可以參考80-20法則。

如果80%是附帶邏輯的，那么就是ok的，但如果有80% 是 simple passthrough processing，那么就得考慮讓某些layer open。比如在復(fù)雜的業(yè)務(wù)系統(tǒng)中, 經(jīng)常會(huì)有一些可復(fù)用的邏輯，這個(gè)時(shí)候會(huì)抽取為通用的服務(wù)層(service layer)。如下圖所示

open layer 、close layer的概念可以幫助理清楚架構(gòu)和請(qǐng)求流程之間的關(guān)系，讓架構(gòu)師、程序員都清楚架構(gòu)的邊界（boundary）在哪里，重要的是，這個(gè)open-closed關(guān)系需要明確的文檔化，不要隨意打破，否則就會(huì)一團(tuán)糟。

Event-Driven Architecture

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

從上述定義可以看出事件驅(qū)動(dòng)架構(gòu)的幾個(gè)特點(diǎn)：分布式、異步、可伸縮。其核心是：高度解耦合、專一職責(zé)的事件處理單元(Event Processor)

事件驅(qū)動(dòng)架構(gòu)有兩種常見拓?fù)浣Y(jié)構(gòu)： the mediator and the broker.

Mediator Topology

需要一個(gè)中心化（全局唯一）的協(xié)調(diào)單元，用于組織一個(gè)事件中的多個(gè)步驟，這些步驟中有些是可并行的，有些必須是順序執(zhí)行的，這就依賴Event Mediator的調(diào)度。如下圖所示

Broker Topology
這種是沒有中心的架構(gòu)

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

如下圖所示

事件驅(qū)動(dòng)的好處在于，高度可伸縮、便于部署、整體性能較好（得益于某些事件的并發(fā)執(zhí)行）。但由于其分布式異步的本性，其缺點(diǎn)也很明顯：開發(fā)比較復(fù)雜、維護(hù)成本較高；而且很難支持事務(wù)，尤其是一個(gè)邏輯事件跨越多個(gè)processor的時(shí)候。

Microkernel Architecture

微內(nèi)核架構(gòu)又稱之為插件式架構(gòu)（plug-in architecture）。如下圖所示：

微內(nèi)核架構(gòu)包含兩部分組件

• a core system
• plug-in modules.

plug-in modules 是相互獨(dú)立的組件，用于增加、擴(kuò)展 core system 的功能。

這種架構(gòu)非常適用于 product-based applications 即需要打包、下載、安裝的應(yīng)用，比如桌面應(yīng)用。最經(jīng)典的例子就是Eclipse編輯器，玩游戲的同學(xué)經(jīng)常下載使用的MOD也可以看出插件。

微內(nèi)核架構(gòu)通常可以是其他架構(gòu)的一部分，以實(shí)現(xiàn)特定部分的漸進(jìn)式設(shè)計(jì)、增量開發(fā)

Microservices Architecture Pattern

微服務(wù)架構(gòu)并不是為了解決新問題而發(fā)明的新架構(gòu)，而是從分層架構(gòu)的單體式應(yīng)用和SOA（service-oriented architecture）演化而來。

微服務(wù)解決了分層架構(gòu)潛在的成為單體式應(yīng)用（Monolithic application）的問題：

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

同時(shí)，微服務(wù)還通過簡(jiǎn)化（泛化）服務(wù)的概念，消除編排需求，簡(jiǎn)化對(duì)服務(wù)組件的連接訪問。從而避免了SOA的各種缺點(diǎn)：復(fù)雜、昂貴、重度、難以理解和開發(fā)。

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.

微服務(wù)架構(gòu)如下：

其核心是service component，這些服務(wù)組件相互解耦，易于獨(dú)立開發(fā)、部署。服務(wù)組件的粒度是微服務(wù)架構(gòu)中最難的挑戰(zhàn)

• 太大：失去了微服務(wù)架構(gòu)的優(yōu)勢(shì)
• 太小：導(dǎo)致需要編排，或者服務(wù)組件間的通信、事務(wù)。

而微服務(wù)架構(gòu)相比SOA而言，其優(yōu)勢(shì)就在于避免依賴和編排 -- 編排引入大量的復(fù)雜工作。

對(duì)于單個(gè)請(qǐng)求 如果service之間還要通信，那么可能是就是粒度過小。解決辦法：

• 如果通信是為了訪問數(shù)據(jù)：那么可以通過共享db解決
• 如果通信是為了使用功能：那么可以考慮代碼的冗余，雖然這違背了DRY原則。在clean architecture中也指出，component的自完備性有時(shí)候要高于代碼復(fù)用。

Space-Based Architecture

基于空間的架構(gòu)，其核心目標(biāo)是解決由于數(shù)據(jù)庫瓶頸導(dǎo)致的低伸縮性、低并發(fā)問題。

分層架構(gòu)中，在用戶規(guī)模激增的情況下，數(shù)據(jù)層的擴(kuò)展往往會(huì)成為最后的瓶頸（相對(duì)而言，前端和業(yè)務(wù)邏輯都容易做成無狀態(tài)，比較好水平擴(kuò)展）。而基于空間的架構(gòu)的核心是內(nèi)存復(fù)制，根本上解決了這個(gè)問題。

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

架構(gòu)如下：

其核心組件包括

• processing unit，處理單元，其內(nèi)部又包含一下組成
  • business logic
  • in-memory data grid
  • an optional asynchronous persistent store for failover
  • replication engine，用于同步數(shù)據(jù)修改
• virtualized middleware
  • Messaging Grid: 監(jiān)控processing unit可用性，路由客戶端請(qǐng)求到processing unit
  • Data Grid: 核心，負(fù)責(zé)processingunit之間的數(shù)據(jù)同步，毫秒級(jí)同步？
  • Processing Grid: 可選組件，如果一個(gè)請(qǐng)求需要多個(gè)processing unit的服務(wù)，那么負(fù)責(zé)協(xié)調(diào)分發(fā)
  • Deployment Manager： 負(fù)責(zé)processing unit的按需啟停

基于空間的架構(gòu)很少見，而且從上面的核心組件描述來看的話，開發(fā)和維護(hù)應(yīng)該都是比較負(fù)責(zé)的，由于是數(shù)據(jù)的同步這塊。而且由于數(shù)據(jù)都保存在內(nèi)存中，那么數(shù)據(jù)量就不能太大。

基于空間的架構(gòu)適用于需求變化大的小型web應(yīng)用，不適用于有大量數(shù)據(jù)操作的傳統(tǒng)大規(guī)模關(guān)系型數(shù)據(jù)庫應(yīng)用

references

clean architecture

software architecture patterns