Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (11)
Ähnlich wie 軟體架構模式
Ähnlich wie 軟體架構模式 (20)
軟體架構模式
- 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