软体架构模式
- 3. ?大綱 ? 介紹 ? 分層架構 (Layered Architecture) ? 事件驅動架構 (Event-Driven Architecture) ? 微核?心架構 (Microkernel Architecture) ? 微服務架構 (Microservices Architecture) ? 基於空間的架構 (Space-Based Architecture)
- 4. – Wikipedia “Software architecture is the high level structure of a software system”
- 5. – Wikipedia “Architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context.”
- 6. 為什麼要談软体架构模式？ ? 避免陷?入?大泥球反模式 (big ball of mud anti-pattern) ? 開發低耦合 、強健的、容易修改、有清楚的開發?方向的軟體 ? 可以說出＆討論應?用程式的架構特性 ? 選擇對的架構來達成業務需求和??目標
- 9. 分層架構 ? 也叫做多層架構模式 (N-tier architecture pattern) ? 多數 Java EE 的?非官?方標準 ? 架構師、設計師、開發?人員最熟悉的架構 ? 和傳統 IT 通訊、組織架構最接近 (Conway’s law)
- 10. 模式描述 ? 分層架構模式內的組件被劃分到多個 架構層，每?一層都代表應?用所需要的 特定?角?色和職能 ? 分層數量不限，但?一般分為四層：表 現層、業務層、持久層和資料庫層 重點：關注分離 (separation of concerns)
- 11. 封閉 vs. 開放 ? 封閉層 (Closed Layer) 代表請求必須 ?一層?一層的傳遞，達到隔離的效果 ? 限制修改的影響範圍只有上下層，降 低組件之間的耦合 ? 重構影響低
- 12. 封閉 vs. 開放 ? 開放層 (Open Layer) 代表請求可以 直接穿越它，存取其下的架構層 ? 通常?用於提供共?用服務/資源 ? 定義?一層的開放或封閉，確定了請求 流動的?方式 ? 所有開發?人員都要理解這些限制
- 13. 范例
- 14. 筆記 ? 如果你不知道要?用什麼架構，分層架構適合你。 ? 避免污?水池反模式 (architecture sinkhole anti-pattern) ? 避免?大部分的請求在某些架構層總是直接流過 ? 80-20 法則
- 15. 模式分析 評價 原因 整體靈活性 低 修改費時、較為笨重、可能出現?高耦合 是否易於佈署 低 ?小改動可能影響到整體，需要有計劃進?行 可測試性 ?高 可分別測試或?用 mock 代替 性能 低 ?一次業務請求需要穿越?大量的架構層 伸縮性 低 架構層間的緊密耦合、通常規模較?大 是否容易開發 是 熟悉度?高、和組織分層相近
- 17. 事件驅動架構 ? 主流的異步分發事件架構模式 ? 由單?一??目的、?高度解耦合的的事件處理組件 (Event Processor) 構成 ? 常?用於需要?高度可擴展的應?用中 ? 從?小?至?大型的應?用都表現不錯 ? 有兩種拓撲結構：中介 (Mediator) 和 代理 (Broker)
- 18. 中介 (Mediator）拓撲 ? 適?用於處理事件有相依性和需要協調 的場景 ? 組件： ? 事件列隊 (event queue) ? 事件通道 (event channel) ? 事件處理器 (event processor) ? 例如：Apache Camel、Apache ODE+BPEL 初始事件 待處理 事件
- 19. 范例
- 20. 代理（Broker）拓撲 ? 適?用於事件較為簡單，?高效能要求的 場景。 ? 沒有核?心的事件中介，改由輕量的消 息列隊取代。 ? 組件： ? 代理 (Broker) ? 事件處理器 (Event Process) ? 例如：ActiveMQ, ZeroMQ, etc. Broker
- 21. 范例
- 22. 筆記 ? 異步處理會造成實現上的困難 ? 要處理遠程操作的可?用性，各個組件操作失敗的處理 ? 顆粒度需要仔細思考 ? 不?支援交易 (transaction) ? 要?一開始就定下事件處理的協定和格式
- 23. 模式分析 評價 原因 整體靈活性 ?高 事件處理器?高度解耦合 是否易於佈署 ?高 事件處理器?高度解耦合 可測試性 低 雖然單元測試簡單，但整合測試困難 ? （需要整體＋異步問題） 性能 ?高 ?高度解耦合＋異步處理 伸縮性 ?高 事件處理器?高度解耦合 是否容易開發 否 需考慮異步處理、訂定協定和流程、處理錯誤狀況
- 25. 微核?心架構 ? 從 OS 得名，也稱作插件應?用架構 ? 可以透過插件的?方式添加額外的特性到核?心系統 ? 具備良好的擴展性和隔離性 ? 例如 Eclipse IDE
- 26. 微核?心架構 ? 組成：核?心系統＋插件組件 ? 核?心系統通常只包含能讓系統運作的 最?小功能 ? 從應?用?角度來看，核?心系統定義了業 務邏輯，?而插件則實作了具體業務邏 輯 ? 插件是?用於提供新特性的獨?立模組， 但也可以互相溝通 (不建議）
- 27. 核?心與插件的互動 ? 實現上沒有限制 ? 核?心系統存取插件可能是透過插件註冊表 ? 註冊表提供插件名稱、傳輸協定、輸?入輸出規範 ? 例如： SOAP + WSDL ? 插件連接核?心可能是?用：OSGi、Message Queue、Web service、DI
- 28. 范例
- 29. 筆記 ? 微核?心架構可以嵌?入到另?一種架構中 ? 良好?支援漸進式設計和增量開發 ? 对於产物导向的应?用来说，微核?心架构是第?一选择
- 30. 模式分析 評價 原因 整體靈活性 ?高 插件兼的鬆耦合，可以隔離變化。 是否易於佈署 ?高 依據實作，插件可以?支援熱差拔 可測試性 ?高 各個插件可以分開測試。可使?用 mock 性能 ?高 透過插件調整可以只包含必要的模組 伸縮性 低 實現是基於產品，?非此架構特??長 是否容易開發 否 需要設計和管理規約，版本控制，考慮顆粒度
- 32. 微服務架構 ? 最近正夯，?用於取代 SOA，但仍在發展中 ? 採?用獨?立佈署、分佈式的服務組件(service component)，透過簡化的 傳輸?方式互動 ? ?高擴展性、鬆耦合，容易佈署 ? 如何正確設計組件的顆粒度是最?大難度
- 33. 模式描述 ? 是?一個演化?而來的架構 ? 透過切割組件，解決分層架構環環 相扣的問題 ? 透過概念簡化來消除 SOA 的複雜 度 ? 常?見拓撲 ? 基於 REST API ? 基於 REST 應?用 ? 集中式消息
- 34. 基於 REST API 拓撲 ? 每?一個服務組件皆透過單獨佈署的 Web 服務，以 REST API 的?方式提供 服務。 ? 顆粒度?非常的細 （也是名稱由來） ? 許多?大型企業提供此類服務
- 35. 基於 REST 應?用拓撲 ? 透過 Web 或是胖客?戶端來處理請 求，?而?非 API。 ? 相較於前者，此實現的服務組件顆粒 度較?大 ? 常?見於中?小型企業，或複雜度較低的 應?用
- 36. 集中式消息實現 ? 透過集中式的消息代理來存取服務。 ? 適?用於較?大型的業務應?用，?支援排隊 機制、異步、監控、錯誤處理、負載 均衡和增強可擴展性。 ? 可以透过代理群集来处理单点问题
- 37. 決定顆粒度 ? 此架構最?大挑戰就是決定服務組件的顆粒度 ? 顆粒度過?大，此服務的好處都享受不到 ? 顆粒度過細會造成使?用上的複雜度、效能犧牲 ? 觀察 ? 需要在應?用接?口中調?用多個服務＝>可能切太細 ? 在服務組件間需要通訊＝>可能切太細
- 38. 筆記 ? 怎麼調整顆粒度都不對，代表你的應?用不適合 ? 微服務架構提供了實時佈署能?力 ? 他是分佈式架构，和事件驱动模式会有?一些共同的问题
- 39. 模式分析 評價 原因 整體靈活性 ?高 服務組件?高度解耦合 是否易於佈署 ?高 服務組件?高度解耦合 可測試性 ?高 服務組件可分開測試，且相依度不?高，可以減少對整體進 ?行測試的負擔 性能 低 分佈式特性不適合?高性能 伸縮性 ?高 服務組件?高度解耦合 是否容易開發 ?高 功能被隔離成不同服務組件，開發範圍?小，且互相不影響
- 40. 參考資料 ? http://www.oreilly.com/programming/free/software-architecture-patterns.csp ? http://en.wikipedia.org/wiki/Software_architecture ? http://en.wikipedia.org/wiki/Architectural_pattern ? http://colobu.com/2015/04/08/software-architecture-patterns/ ? https://github.com/bboyfeiyu/android-tech-frontier/tree/master/software- architecture-patterns ? http://jonathanspeaking.blogspot.tw/2010/11/conways-law.html