軟件架構分解

https://www.ibm.com/developerworks/cn/rational/1312_wanggb_arch/index.html

什麼是軟件架構

若是指望有一個權威統一的標準定義，那答案是沒有，目前存在多種軟件架構的定義，能夠說百花齊放，百家爭鳴。其中 IEEE1471-2000 的定義是這樣的：系統的架構是系統組件的基本組織形式，它們之間的關係以及和環境之間的關係，以及指導其設計和演化的原則。該定義中的系統組件能夠理解爲架構元素，根據涉及到的系統範圍和層次，架構元素能夠是子系統、模塊、類等等。從架構設計的動態角度出發，咱們能夠這樣來定義軟件架構：經過一系列架構決策，將系統分解爲一些架構元素，並定義這些元素之間的接口和交互關係、集成機制。架構決策就是在架構設計過程當中作出的一系列全局的決定和權衡取捨，例如將系統拆分紅幾個子系統、子系統的職責是什麼、子系統之間的接口是什麼、採用什麼通信方式和集成機制、採用的開發語言和技術框架等。

架構形而上的本質

除了軟件架構，衆所周知，在建築行業中也存在架構，並且建築架構比軟件架構歷史要悠久得多；在公司中存在組織架構。這就引起了咱們的思考，對這些不一樣的架構，它們的本質是什麼？

從抽象的形而上的角度來看，架構是架構做用力的平衡，如圖 1。

圖 1 中左側一個最初混沌的系統在架構做用力的相互做用下達到足夠程度的平衡。右側的橢圓蘊含的意思是架構應該是有彈性的，裏面的多個小圓表示在力的做用下分解產生的架構元素。

圖 1.形而上的架構

什麼是架構做用力

對一個建築工程項目，會涉及到多方涉衆，如建設單位、勘察單位、設計單位、施工單位、工程監理單位、使用單位等等，他們對工程項目存在各類需求；一樣在一個軟件系統中也會有多種涉衆，例如系統用戶、投資人、需求分析師、架構師、開發人員、測試人員、客服人員、運維人員等等。這些涉衆在架構層面有各自的架構需求，例如系統用戶除了要求知足他們的功能需求外，還有對系統的易用性、性能、可用性等非功能性存在要求；開發設計人員但願系統架構清晰，便於理解，關注代碼重用性、擴展性、可維護性。架構師更關注於系統可伸縮性、可用性、性能等非功能需求。這些需求必須在架構層面加以考慮，使這些涉衆的需求在架構層面獲得足夠的知足。

從抽象的層次來看，涉衆在架構層面的上述各類需求就是架構做用力，它們直接影響和驅動架構設計。大師 Grady Booch 在他的<<The architecture of Web applications>>一文中就已經關注軟件中的做用力（Forces in software）。在架構中除了存在這些外力外，在架構中也存在內力，就是架構元素之間的相互做用力，這裏不展開討論。

一個架構要知足全部的需求一般是不可能的，由於不一樣的涉衆，他們之間的需求多是相互衝突的，也就是做用力的方向是相反的。做用力的大小主要體如今需求的優先級上。

架構設計過程當中，架構師運用本身的經驗，結合當前的技術，從全局考慮需求和約束，進行折中和取捨，平衡這些涉衆的做用力。

在 IEEE1471-2000 規範中，將涉衆在架構層面的各類需求稱爲關注點，從這個概念來講架構分解就是關注點分離。

架構分解

當咱們看到一個複雜系統的架構視圖時，可能會思考這些視圖中的架構元素是怎麼來的。如何從混沌的鐵板一塊的總體架構演變成一個可伸縮高性能的分佈式系統？

分而治之是一種處理複雜問題的通用方法，在軟件架構中，它也是一種很重要的手段，例如多層架構、OSI 七層模型都體現了分而治之思想。在架構設計過程當中，經過將關注點分離對架構進行多層次分解，將系統層層分解爲多個架構元素，進而識別架構元素。

能夠說架構中的不少元素都是在架構分解的過程當中識別產生的。

架構分解的做用

萬事開頭難，架構分解是架構設計過程當中很是關鍵的一步。除了識別架構元素，對大規模的軟件系統，分解仍是解決非功能需求的重要手段。eBay 爲了解決可伸縮性、可用性、可管理性等問題，在架構的多個層面進行了分解：

• 在應用層面，按照功能或 SOA 服務進行分解，將系統垂直拆分爲多個應用池（應用池中的服務是無狀態的）。每一個應用池中有多個應用（水平拆分），能夠獨立靈活地進行伸縮。見圖 2 所示。
• 在數據層面，對數據進行垂直拆分（分庫）和水平拆分（數據分片 DB Sharding）；將分佈式事務拆分紅多個本地事務獨自提交，避免分佈式事務。見圖 3 所示。

圖 2.應用的垂直和水平拆分

圖 3.數據的垂直和水平拆分

架構分解的原則

德國哲學家、數學家萊布尼茲一針見血地指出：「不講分解技巧，分而治之就不大有用。無經驗者對問題分解不當，反而會增長困難「。爲了正確的進行分解，須要遵循一些分解原則：

• 低耦合、高內聚：萊布尼茲指出：「分解的主要難點在於怎麼分。分解策略之一是按容易求解的方式來分，之二是在弱耦合處下手，切斷聯繫」。在弱耦合處下手，切斷聯繫。太精闢了！高內聚、低耦合也是軟件設計的基本原則，軟件設計中的不少設計原則其實均可以認爲它的派生或具體化，如單一職責原則、依賴倒置原則、模塊化封裝原則，這些原則在架構分解中也是適用的。
• 層次性：分解一般是先業務後技術，按部就班，先邏輯後物理，從上到下逐級進行分解展開：系統－>子系統－>模塊－>組件->類。
• 正交原則：和物理學中的正交分解相似，架構分解出的架構元素應是相互獨立的，在職責上沒有重疊。
• 抽象原則：架構元素識別，在較大程度上是架構師抽象思惟的結果，架構師應該具有在抽象概念層面進行架構構思和架構分解的能力。
• 穩定性原則：將穩定部分和易變部分分解爲不一樣的架構元素，穩定部分不該依賴易變部分。根據穩定性原則，將通用部分和專用部分分解爲不一樣的元素；將動態部分和靜態部分分解爲不一樣的元素；將機制和策略分離爲不一樣的元素；將應用和服務分離。
• 複用性原則：就是對知識的重用.重用相似系統已有的架構設計、設計經驗、成熟的架構模式或參考模型、設計模式、領域模型、架構思想等，由於它們已經在不一樣的層次上分解識別出了許多架構元素，或者指出了一些分解方向，對咱們的架構分解具備借鑑和指導做用。例如 IBM SOA 解決方案參考模型對 SOA 服務化具備重要的指導意義，咱們能夠參照它對系統進行初步的架構分解。

圖 4 IBM SOA 解決方案參考模型

架構分解的過程模型

對複雜的系統，特別是前人沒有作過的新系統，一般難以一會兒設計出合適的架構。在架構設計的初期，一般都要經歷一個不斷探索的階段。

在架構設計過程當中，架構分解是必不可少的的關鍵步驟。如何進行架構分解？從哪裏入手開始進行分解？咱們須要有一個架構分解的過程模型來指導分解過程，啓發和探索架構分解的維度和線索，提升架構分解的效率。

架構分解過程模型如圖 3 所示，是一個迭代的模型。經過這個迭代的分解，從無到有、從粗到細、從模糊到清晰，一步步精（細）化、豐富架構。迭代的過程也是一個否認之否認的過程，隨着分解的逐步推動或系統的架構演化，後面的分解除了會識別出新的架構元素，也可能會對先前識別出的架構做出調整。

圖 5.架構分解過程模型

依次在 4 個域中進行架構分解，基本順序是先業務後技術，經過多維度多層次的分解將關注點分離。

• 業務域分解：先從業務域進行分解，狹義的業務域具備商業的概念，從這個概念來看，有的系統沒有業務域，但若是寬泛一點來看，業務域就是問題域（問題空間），問題域老是存在的。

首先是從系統需求入手，尋找業務域中的分解維度，將架構從業務域層面進行大尺度（大粒度）的分解。在業務域中進行分解，一般採用的分解維度是根據業務主題，將系統分解爲多個子系統，每一個子系統聚焦於一個獨立的業務主題，子系統間具備清晰的邊界。例如對某電商系統，咱們能夠根據業務主題維度進行架構分解，初步劃分出：會員子系統、交易（訂單）子系統、產品子系統、搜索子系統、物流子系統、支付子系統等。

領域驅動設計（DDD）中的邊界上下文（context boundary）是一種根據業務相關性進行大尺度分解的方法，它和基於業務主題的分解是相似的。

圖 6 基於業務主題的分解

對業務域分解不該只侷限於基於業務主題的分解，根據具體狀況，還可能有其餘的分解維度。一個通用的發現分解維度的方法是試着從領域模型和需求分析文檔中尋找名詞和形容詞，將文檔中的核心概念（名詞和形容詞）做爲分解的候選分解維度或分解線索。

在業務域的分解中，咱們要和業務（行業）專家密切交流，多研究業務架構、適當考慮企業戰略，這樣可在必定程度上保證架構分解的合理性。

• 業務功能域分解：經過對業務流程和用例進行分析，根據功能職責，進行垂直和水平分解，識別出業務功能或業務服務，將它們歸類到子系統中相應模塊中去。

對業務域功能域分解，一個通用的方法是試着經過動詞來將子系統拆分爲多個服務；另外一個是根據資源類型（名詞）來將系統拆分爲服務，每一個服務負責實現對應資源上的一組操做。例如根據資源類型（會員、商品等），對電商系統，可分解識別出會員查詢服務和會員管理模塊、商品服務等。

這兩步的架構分解都是純業務上的，不涉及技術，但要這兩步分解出的架構元素要映射到技術域中去實現，或用來幫助架構師推導出技術域的對應架構元素。

• 技術域分解：是從技術角度對系統和模塊進行分解。在該階段，一般會選取關鍵的需求（包括功能需求和非功能性需求）和已分解出的模塊或子系統，結合當前的 IT 技術（技術框架、架構模式、參考架構、中間件、業務平臺）和架構思想、架構經驗、開發人員的技能以及系統的上下文環境等，進一步進行架構分解。

  例如不少系統採用 MVC、多層架構模式、SOA、事件驅動架構等技術或思想進行技術域中的架構分解。對電商交易子系統的訂單流程，考慮到要須要靈活支撐多種交易流程和解耦流程層與業務邏輯層的須要，按照 IBM SOA 的參考架構（圖 4）能夠分拆出流程層、服務層等，在流程層中採用流程引擎技術。

  在技術域分解中，對功能需求，橫切（分層）豎割是一種經常使用的分解手法。對非功能需求，可將性能、伸縮性、可用性等做爲維度對系統進行分解，在非功能需求分解戰術中將專門說明這些維度的分解技術（稱爲戰術）。

  在業務域和業務功能域中分解出來的架構元素，考慮到技術實現，在映射到技術域時，可能要對架構元素進行修改或做一些微調，業務域和業務功能域中分解出的架構元素一般會進一步分解爲技術域中的多個架構元素。例如在業務功能域分解出的會員查詢服務模塊，在技術域中分解時，考慮到有多個不一樣類型的調用方會使用該服務，而且這些調用方須要的查詢接口差別較大，調用頻率等也不同，那咱們可能會對每一個調用方拆分出獨立的查詢接口模塊，這樣也避免了胖接口，相關的 DAO 類也是在技術域中新產生的。

  在從模塊分解到類的過程當中（假設有些模塊要分解到類級別），須要進行靜態和動態的分析以便識別出類元素。首先是根據業務域需求，創建領域模型，識別出領域（概念）類，再將領域類映射到技術域中的設計類（實體類），也就是領域類可幫助咱們識別推導出部分設計類。再基於具體用例，進行魯棒分析和序列圖設計，考慮技術上的實現和採用的技術架構，例如採用一些技術框架和類庫或工具類，如 ibatis 框架，就會識別出另外一些設計類（邊界類、控制類）或引入一些新的設計類，這些引入的類可能直接來自框架或類庫，或是繼承框架中的類（成爲框架類的子類）。一般設計過程不會就此結束，考慮到開發維護和設計質量等因素，咱們會運用一些設計原則（如高內聚低耦合、單一職責、信息專家等）、設計模式、重構模式等對設計進行進一步的優化，這時又會產生識別出一些設計類，一般在這一步會對咱們的設計進行一些修改和調整，例如採用工廠方法設計模式，會引入工廠方法類，咱們的序列圖就要修改。這樣咱們最終完成了一個完整的設計。由於要考慮技術域，因此對整個分析設計來講，它是源於業務但要高於業務。

  在技術域的分解中，對公共的技術需求應全盤考慮，抽象出底層的公共技術基礎設施，例如定時任務在許多子系統中都存在，此時可能會規劃一個定時任務框架和定時任務執行系統。也可能會採用一些成熟的框架和中間件技術，如消息中間件、ESB 等。

  技術域的分解一般是比較複雜的，這一方面來源於問題域的本質複雜性，特別是各類非功能性需求的複雜性，須要架構師掌握應對這些需求的常見模式。另外一方面也是因爲 IT 新技術的突飛猛進，要求架構師對技術敏感，與時俱進。

  要注意的是，當在技術域分解中碰到困難時，能夠再回到業務域中去尋找答案和線索。例如爲了解決某計費系統中的性能和可伸縮性問題，可在業務域中尋找名詞和形容詞，發現能夠根據付費類型（預付費和後付費）將系統初步分拆爲預付費系統和後付費系統。對網絡通信系統，能夠根據請求消息中的某些屬性對消息處理系統進行拆分或根據客戶端類型等進行拆分。

• 涉衆域分解：全面考慮各種涉衆在架構層面的關鍵需求，特別是非功能需求，例如性能需求、可伸縮性需求等，進一步對系統進行分解。

  涉衆域分解包括了前面說的業務域分解、業務功能域分解、技術域分解，一般涉衆域分解和它們有部分是重疊的，例如在技術域和涉衆域中都有性能方面的架構分解。涉衆域分解保證咱們的分解是完備的，沒有遺漏。

  在涉衆域的分解過程當中，極可能會產生新的子系統，例如考慮用戶的性能方面的需求，可能會分解出分佈式數據緩存子系統（也可能在技術域分解中就已經考慮到了）。 

  涉衆域分解的一個可能的維度是根據涉衆類型，基於他們的關注點來進行架構分解，試着爲某類涉衆劃分出對應的子系統或模塊（架構元素），例如考慮到前臺涉衆和後臺涉衆的用戶類型、關注點差異較大等因素，可能會將系統劃分爲前臺系統和後臺系統兩大類。對第三方涉衆（外部系統），考慮到接入認證受權、安全性和互操做性，可能會分解出網關子系統。

  爲什麼首先從業務域開始分解，其實很好理解，咱們開發一個系統確定是爲了解決業務問題，是爲業務服務的，不可能脫離業務去設計一個空洞的無目標的系統和架構。

架構分解維度

從上面的描述能夠看出，架構分解就是從多個維度多層次對系統進行分解，識別出架構元素，逐步精化、豐富系統架構的過程。圖 4 形象地表示了架構分解的多維度立體拆分。

圖 7.多維度分解

這 4 個域中除了分解過程模型一節中說起的一些分解維度，根據具體的系統，還可發掘出許多分解維度，如時間維度、物理空間維度、優先級維度、職責角色維度（不一樣的角色）、客戶端維度、調用方維度（不一樣的調用方）、請求類型維度、數據維度、數據處理維度（OLAP、OLTP）等。

有幾個要指出的問題是：

• 分層和分解的不一樣，分層只是分解的手段之一，是一種有層次的分解，還有不少分解手段不屬於分層，例如基於業務主題的分解和各類數據分解。
• 橫切豎割式的二維分解是一種分解形式，對複雜系統，可能要從 4~5 個或更多維度對系統進行較大尺度的分解。
• 授人以魚，不如授人以漁。本文列出的一些分解維度只是爲了幫助闡釋多維度多層次分解的方法，重點是分解方法和一些發現分解維度的策略，不是列出的分解維度，不要本末倒置。在運用多維度分解方法時，不要侷限於這些維度，也有可能這些分解維度不適合你的產品或項目，應根據實際狀況，去發現合適的分解維度。
• 在架構設計中，除了分解，還有集（合）成，在分解時要有總體思惟，在分解的過程當中要考慮到和其餘架構元素的集成，保證分解出的架構元素最終能集成在一塊兒。
• 軟件架構中科學與藝術並存，註定了架構設計（包括架構分解）沒有銀彈，但咱們能夠不斷努力探索架構設計中的科學成分，欣賞偉大架構師的設計藝術。

非功能需求的分解戰術

對非功能性分解維度，在具體的分解過程當中，能夠藉助一些成熟的模式來實現架構元素的識別，在<<軟件構架實踐>>中，將在架構層面應對非功能需求特性的架構模式或架構策略稱爲戰術，例如對可用性，經常使用的戰術包括：冗餘、錯誤檢測。

在<< The Art of Scalability >>中，對可伸縮性，提出了一個伸縮立方模型（Scale Cube），以下圖 5。

圖 8.伸縮立方模型

這是一個三維的立方模型，表示可在三個維度上實現可伸縮性：

• X 軸表示水平復制（克隆），就是在負載均衡器後面部署多個相同的應用來進行水平伸縮；
• Y 軸表示功能分解，按不一樣的功能對應用進行分解。也可用於數據，就是分庫，不一樣類型的數據在不一樣的庫中。
• Z 軸表示數據分片（sharding），每一個數據分片有單獨的應用負責訪問。也可表示應用分片，每一個應用只負責提供部分數據服務，多個應用合起來提供完整的服務。

這三個維度能夠結合在一塊兒使用，也可單獨使用。

能夠看出，前面提到的 eBay 可伸縮性實踐應用了該模型。

部分非功能需求的經常使用戰術以下表 1：

表 1. 非功能需求戰術

非功能需求類型	戰術
可用性	高可用集羣 服務降級 異步消息
性能	負載均衡集羣 緩存（頁面、數據） 數據讀寫分離、數據分片 、分庫、分表 併發處理 異步處理
可伸縮性	採用彈性雲計算平臺 數據層面：緩存、垂直伸縮、讀寫分離、數據分片、分庫、分表 應用層面：垂直伸縮、水平復制（水平伸縮）、功能分解（服務無狀態）、應用分片

分解維度與戰術的關係

戰術除了應用在非功能需求上，在架構層面應對功能性需求的架構模式、架構策略和其餘技術手段也可稱爲戰術。例如分層模式、AOP（面向切面編程）技術等都是戰術。

分解維度和戰術的關係，就是戰略和戰術的關係，分解維度指明分解的位置和目標所在，戰術是實現該分解的手段。例如在森林裏伐木，分解維度指出砍哪顆樹，戰術指出是用斧頭砍仍是鋸子鋸。沒有戰略，就不知道目標和方向，成爲無頭蒼蠅；沒有戰術，戰略就成空想，不能落地實現。對軟件系統中的橫切關注點，在 AOP 技術出現以前，知道要進行分離，但一直沒發現實現分離的完美戰術，直到 AOP 技術出現後，才較爲完美的實現了橫切關注點分離，可見戰術和機制也很重要。

對簡單的系統或有經驗的相似系統，也可直接應用成熟的戰術，不需在架構分解上過多投入。

架構分解的粒度

多維度多層次分解到什麼粒度才中止？這個沒有統一的標準，一般要能進行並行開發，能指導後續的詳細設計。須要根據具體的產品或項目來定，有的到模塊級別就行，對關鍵的部分，能夠到類級別。

架構分解的時機

架構分解的時機一般就是架構改造演化的時機。當架構出現腐化和臭味，已經難以知足關鍵涉衆的關鍵需求，例如用戶的響應速度愈來愈慢已經接近臨界值，而且根據預見，響應速度還有可能繼續較低；開發人員愈來愈難以維護，這個時候能夠考慮進行架構演化，對架構進行改造。固然若是能提早預見系統的問題，通過慎重評估後，在問題發生以前，提早一段時間進行架構演化也是能夠的。

要注意的問題是不要過分分解，過早分解，這樣作除了增長成本，還可能帶來風險。例如不少系統在建設初期，考慮到規模較小和快速上線，一般都是一個總體的系統，不會進行大的架構分解，之後隨着需求和規模的逐漸增長，會逐步進行架構改造和架構分解。

架構視圖和架構視點

在 IEEE1471-2000 規範中對視圖和視點的定義以下：

• 視圖：是從相關的一組關注點投射的整個系統的一個表示。爲了捕獲或表示系統架構的設計，架構設計師通常會建立一個或多個架構模型，可能用不一樣的工具。視圖由這其中選擇出來的一個或多個模型組成，選擇這些模型是爲了展現個一個或一組利益相關人，以便他們的關注點在設計系統架構的過程當中得到了足夠的關注。
• 視點：架構視點是用於構建和利用一個視圖的約定規範，它是一個模式或模版，能夠用來肯定一個視圖的目標、用戶以及建立和分析的技術，從而創建一個獨立的視圖。

視點可理解爲觀察系統的一個角度，每一個系統有多個視點，每一個視點都有一個涉衆；該類涉衆從某個角度觀察系統，所看到的系統的部分信息就是該視點對應的視圖，系統有多個視圖。

視圖和視點一般用在架構文檔中，做爲描述架構的重要手段，在架構分解過程當中，可用來做爲發現架構分解維度的一種輸入，幫助進行架構分解。

在 RUP 中定義了「4+1「視圖，其中的開發視圖就是開發人員從開發視點出發，用來爲開發人員提供切實的指導。

除此以外，在企業架構 TOGAF 框架和 RM-ODP 也定義了視點和視圖來建模和描述各類類型的架構。

總結

對複雜的軟件系統，其架構設計是一項複雜的系統工程，架構分解做爲架構設計中的關鍵步驟，在軟件行業中尚未成熟的系統的架構分解方法論來指導架構分解。本文對此問題作了初步的探討，提出了架構分解的過程模型和架構分解多維度模型，用來幫助架構師逐步進行架構分解，識別出其中的架構元素。對架構分解，關鍵在於找到合適的架構分解維度和分解戰術。