Software Architecture Patterns 1

O'Reilly 提供了一份Software Architecture Patterns [Book] ，裡面描述了五個基本的軟體架構。這邊是 layered 與 event-driven architecture。

Layered

layered architecture 是最常見的架構，也稱為 n-tier architecture pattern。最初是因為 Java EE application 而變成顯學。

本架構分為四個基本的 layers：presentation, business, persistence, database，有時候可以簡化，將 business 與 persistence 合併為一個 business layer，也就是把 SQL, HSQL 放在 business layer component 裡面，適合小型專案。

layered architecture 最重要的功能，就是 separation of concerns among components。

本架構重要概念是: closed，也就是 request 必須一層一層轉換移動，不能跳躍。雖然有時候會遇到一些非常簡單的功能，可以直接將 presenation layer 的資料儲存到 database，但遵循本架構的原則：layers of isolation，不能破壞 layers 之間的階層關係。一但破壞這個開發原則，會讓 application 不容易修改，難以維護。

如果要解決 layers 的 overhead 與耗時，可以將 layer 由 closed 變成 open。例如加上一個 open 的 shared-service layer，這個 service layer 可區分 access restriction 的 service 及 common service。

Pattern 分析

• agility: low

  layers 提供了修改的彈性，但會多了一些 code 開發與執行時間的 overhead

• ease of deployment: low

  通常會更新整個 application，無法針對 compoent 單獨更新

• performance: low

• scalability: low

  這個架構適用於一個獨立的 application

• ease of development: high

  分層後，讓 code 容易維護

Event-Driven

這是常見的 distributed asynchronous architecture pattern，用來開發 scalable applications。

本架構包含兩個基本的 topologies: mediator 及 broker。mediator 用在一個 event 透過一個 central mediator 處理多個 steps。broker 用在 chain events together。因兩種架構的差異，在一開始要確定哪一種適用。

Mediator

當 event 有多個 steps，且有多個處理 event 的組合，可使用 mediator。

mediator 有四種 components: event queues, an event mediator, event channels, event processors

當 mediator 收到 event，會發送給不同的 event channel 處理某個 step，event processor 會監聽 channel，取得 event 並執行 business logic

在 event-driven architecture 可能會有上百的 event queues，並沒有限定如何如做 event queue，可能是 message queue/web serivce endpoint

event 有兩種 types: initial event 及 processing event

mediator 負責協調處理 initial event 的 steps，本身不執行 business logic，會發送 processing event 到 event channel 給 processor 處理

event channel 可以是 message queue 或是 message topics，在 mediator topology 比較常使用 message topics，因為可以派送給多個 event processors

event processor 包含了處理該 event 的 business logic，每個 processor 都是 self-contained, indepenedent, highly decoupled

event mediator 有多種實作方式，要選擇適用的方案

1. 使用 open source integration hubs，ex: Spring Integration, Apache Camel, or Mule ESB，通常是用 Java code 或 DSL(domain-specific language) 實作

2. 比較複雜的方法，使用 BPEL (business process execution language) ，open source BPEL engine 有 Apache ODE。BPEL 是 standard XML-like language

3. 最大型的 application，有複雜到中間有需要人工處理的步驟時，可以用 BPM (business process manager) ex: jBPM 實作

example

提出搬家資訊更新需求給保險公司，initial event: relocation event，要完成此 event 其中包含上圖多個步驟，mediator 會產生多個 processing event，並發送給 event channel，由 processor 處理，processing event 上面的箭頭線段代表那些 event 可以同時被處理

Broker

broker topology 沒有 central event mediator，message 以 chain-like 方式流過 lightweight message broker (ex: ActiveMQ, HornetQ)，當有簡單的 event processing flow 時可使用。

有兩個 components: broker, event processor

broker 可以是 centralized 或 federated，包含所有 event channels。event channels 可以是 message queue, message topics, 或兩者的組合。

event processor 負責處理 event 後，並產生下一個動作的新 event。

ex: an event processor 處理 portfolio of stocks 收到 initial event: stock split，收到該 event 會執行 portfolio rebalancing，然後發布一個新的 "rebalance portfolio" event 給 broker，接下來由另一個 processor 處理。

系統有可能會因為某些特殊狀況 ex: 升級，發生某些 event 沒有被 processor 處理的狀況

example: 提出搬家資訊更新需求給保險公司

"customer process" 接收 initial event，修改客戶的地址，並發送 "change address event"。"quote process" 與 "claims process" 對這個 event 有註冊要使用該 event。

"quote processor" 會根據地址重新計算新的 auto-insurance rate，並發布 "recalc quote event" 給系統。 "claims process" 接收到 "change address event" 會更新 outstanding insurance claim，並發布 "update claim event" 給系統。

event processor 會處理新的 event，直到沒有新的 events

broker topology 是用 chaining of events 執行 business function，就像是接力賽跑一樣。

注意事項

因為 asynchronous distributed 特性，event-driven architecture 比較複雜，要注意 remote process availability, lack of responsiveness, broker reconnectoin logic

另一個要注意的是缺少單一 business process 的 "atomic transaction"，因為 event processor 互相分散獨立，很難跨越 processors 提供 transaction。

使用時必須持續注意 events 可能無法獨立運作，如果有某些功能需要 undivided transaction，可能就不能使用這個 pattern

最難實作的是 creation, maintenance, governance of event processor component contracts，也就是要統一 event 的格式，建議可以用 XML, JSON, Java Object 等等，並要建立 contract versioning policy

Pattern 分析

• agility: high

  因每個 processor 功能單一，且各自獨立，可快速修改更新

• ease of deployment: high

  decoupled nature of the event processor components

• testability: low

  unit testing 簡單，但整合測試很複雜

• performance: high

  因為都是非同步呼叫

• scalability: high

  每個 event processor 可分別 scaled

• ease of development: low

  因為非同步呼叫，開發困難，不容易做錯誤處理 (unresponsive event processor, failed broker)

References

软件架构入门 - 阮一峰的网络日志