作者： 李偉山
公眾號：技術(shù)方舟
架構(gòu)設(shè)計思維-分解
開篇我們先講兩個成語：『好高騖遠』和『高瞻遠矚』，如果一個人做一些不切實際的事情，我們稱之為好高騖遠；如果一個人有眼界視野，我們稱之為高瞻遠矚；同樣是高、遠，為何描述著兩種完全不同的人？因為前者的好、騖講的都是追求，而后者的瞻、矚，指的卻是具體的行動。當(dāng)我們把高遠的目標(biāo)只作為一種追求，而不付諸于實踐的時候，就是不切實際；當(dāng)我們把它變成“時時顧看”這樣的行動時，我們就漸漸地變得有眼界視野了。所以志存高遠并沒有錯，只是要切忌不務(wù)實?！爸塾诟哌h”這就是作為一個架構(gòu)師所需的基本修養(yǎng)，而所有的架構(gòu)設(shè)計思維都是從這修養(yǎng)中汲取而來。
01
概述
所有的系統(tǒng)開發(fā)方法都要解決從需求到實踐的轉(zhuǎn)換問題，為了提高系統(tǒng)的質(zhì)量，前人提出了需求分析工程和各種建模技術(shù)，但是在需求和設(shè)計之間還是很難逾越，也就是說缺乏能夠反映做決策的中間過程，于是系統(tǒng)架構(gòu)設(shè)計應(yīng)運而生。
對于架構(gòu)設(shè)計人們已經(jīng)提出了許多方法，分類為：工件驅(qū)動的方法；用例驅(qū)動的法；模式驅(qū)動的方法；領(lǐng)域驅(qū)動的方法。一個經(jīng)典的架構(gòu)設(shè)計過程模型，沿用了RUP中迭代增量的思想，由分析、描述、選擇、構(gòu)造和組合5個階段組成，如圖：
（有興趣的可以學(xué)習(xí)一下架構(gòu)設(shè)計的元模型來設(shè)計屬于自己領(lǐng)域或者產(chǎn)品線的設(shè)計過程模型，其實下面的模型也是元模型的實例化）
依據(jù)需求規(guī)格說明書分析出功能需求和架構(gòu)需求，通過用例和場景的描述，把需求分為關(guān)鍵的，次要的和可選的3類。關(guān)鍵需求決定架構(gòu)，結(jié)合軟件架構(gòu)風(fēng)格和通用知識選擇最關(guān)鍵、影響最大的子系統(tǒng)分析設(shè)計并產(chǎn)生構(gòu)件。組合就是定義構(gòu)件接口，構(gòu)件作為一個封閉的功能實體，對外提供交互接口，并通過連接件將構(gòu)件連接起來形成最終的軟件架構(gòu)描述。5個階段是不斷迭代的過程，在每一次迭代中，都選取并實現(xiàn)一組用例和場景來確認(rèn)并完善架構(gòu)。
這個過程模型看似很流暢，但是，架構(gòu)師在設(shè)計時很難把握他的正確性和精準(zhǔn)性，而且用它架構(gòu)的系統(tǒng)是否對后續(xù)設(shè)計開發(fā)形成一種原則上的指導(dǎo)是很難說的。但是對于架構(gòu)師來說有些思路可以進行參考，大致將架構(gòu)思維可以分為：分解、集成、分離、復(fù)用、分層、模式、抽象、結(jié)構(gòu)化、迭代、勿做過度設(shè)計這幾部分，按照這個思維方式來設(shè)計系統(tǒng)架構(gòu)。
02
架構(gòu)設(shè)計思維-分解
分而治之是一種處理復(fù)雜問題的通用方法，在系統(tǒng)架構(gòu)中也是一種很重要的手段，例如多層架構(gòu)、OSI 七層模型都體現(xiàn)了分而治之思想。在架構(gòu)設(shè)計過程中，通過將關(guān)注點分離對架構(gòu)進行多層次分解，將系統(tǒng)層層分解為多個架構(gòu)元素，進而識別架構(gòu)元素。同時保證分解后的各個部分還能夠高內(nèi)聚，松耦合，最終又集成為一個完整的整體。分解核心是定義問題，因此架構(gòu)首先仍然需要理解清楚需求。
01
分解的作用
架構(gòu)分解是架構(gòu)師接到需求到完成架構(gòu)設(shè)計中最關(guān)鍵的一步，分解可以幫助架構(gòu)師了解需求中未呈現(xiàn)出來的隱性需求要素，分解也是架構(gòu)師解決非功能層面需求的重要手段，架構(gòu)要解決高性能、高可用、伸縮性、可擴展性等問題，針對這些問題，我們一般從幾個方面進行入手：
02
分解的原則
01
業(yè)務(wù)原則
02
技術(shù)原則
03
治理原則
電商架構(gòu)設(shè)計模型
03
分解的過程
面對一個系統(tǒng)，特別是前人沒有做過的新系統(tǒng)，通常難以一下子設(shè)計出合適的架構(gòu)。在架構(gòu)設(shè)計的初期，通常都要經(jīng)歷一個不斷探索的階段。在架構(gòu)設(shè)計過程中，架構(gòu)分解是必不可少的的關(guān)鍵步驟。如何進行架構(gòu)分解？從哪里入手開始進行分解？我們需要有一個架構(gòu)分解的過程模型來指導(dǎo)分解過程，啟發(fā)和探索架構(gòu)分解的維度和線索，提高架構(gòu)分解的效率。
架構(gòu)分解過程如下圖所示，是一個迭代的模型。通過這個迭代的分解，從無到有、從粗到細(xì)、從模糊到清晰，一步步精（細(xì)）化、豐富架構(gòu)。迭代的過程也是一個否定之否定的過程，隨著分解的逐步推進或系統(tǒng)的架構(gòu)演化，后面的分解除了會識別出隱性需求，也可能會對先前識別出的架構(gòu)作出調(diào)整。
依次從 4 個域中進行架構(gòu)分解，基本順序是先業(yè)務(wù)后技術(shù)，通過多維度多層次的分解將關(guān)注點分離。
首先是從業(yè)務(wù)需求入手，尋找業(yè)務(wù)需求中的分解維度，將架構(gòu)從業(yè)務(wù)需求層面進行大粒度的分解。在業(yè)務(wù)域中進行分解，通常采用的分解維度是根據(jù)業(yè)務(wù)主題，將系統(tǒng)分解為多個子系統(tǒng)，每個子系統(tǒng)聚焦于一個獨立的業(yè)務(wù)主題，子系統(tǒng)間具有清晰的邊界。例如對某電商系統(tǒng)，我們可以根據(jù)業(yè)務(wù)需求維度進行架構(gòu)分解，初步劃分出：訂單系統(tǒng)、用戶中心、購物車系統(tǒng)、搜索系統(tǒng)、廣告系統(tǒng)、庫存系統(tǒng)、物流系統(tǒng)、商品中心、支付系統(tǒng)等模塊。
對業(yè)務(wù)需求分解不應(yīng)只局限于基于業(yè)務(wù)需求的分解，根據(jù)具體情況，還可能有其他的分解維度。一個通用的發(fā)現(xiàn)分解維度的方法是試著從領(lǐng)域模型和需求分析文檔中尋找名詞和形容詞，將文檔中的核心概念（名詞和形容詞）作為分解的候選分解維度或分解線索。
業(yè)務(wù)需求的分解中，我們要和產(chǎn)品經(jīng)理密切交流，適當(dāng)考慮企業(yè)戰(zhàn)略，這樣可在一定程度上保證架構(gòu)分解的合理性。
對業(yè)務(wù)功能需求分解，一個通用的方法是試著通過動詞來將子系統(tǒng)拆分為多個服務(wù)；另一個是根據(jù)資源類型（名詞）來將系統(tǒng)拆分為服務(wù)，每個服務(wù)負(fù)責(zé)實現(xiàn)對應(yīng)資源上的一組操作。例如根據(jù)資源類型（用戶、商品等），對電商系統(tǒng)，可分解識別出用戶查詢服務(wù)和用戶管理模塊、商品服務(wù)等。
在技術(shù)需求分解中，對功能需求，橫切（分層）豎割是一種常用的分解手法。對非功能需求，可將性能、伸縮性、可用性等作為維度對系統(tǒng)進行分解，在非功能需求分解戰(zhàn)術(shù)中將專門說明這些維度的分解技術(shù)（稱為戰(zhàn)術(shù)）。
在技術(shù)需求的分解中，對公共的技術(shù)需求應(yīng)全盤考慮，抽象出底層的公共技術(shù)基礎(chǔ)設(shè)施，例如定時任務(wù)在許多子系統(tǒng)中都存在，此時可能會規(guī)劃一個定時任務(wù)框架和定時任務(wù)執(zhí)行系統(tǒng)。也可能會采用一些成熟的框架和中間件技術(shù)，如消息中間件、RPC 等。
技術(shù)需求分解通常是比較復(fù)雜的，這一方面來源于問題域的本質(zhì)復(fù)雜性，特別是各種非功能性需求的復(fù)雜性，需要架構(gòu)師掌握應(yīng)對這些需求的常見模式。另一方面也是由于 互聯(lián)網(wǎng)技術(shù)的日新月異，要求架構(gòu)師對技術(shù)敏感，與時俱進。要注意的是，當(dāng)在技術(shù)域分解中碰到困難時，可以再回到業(yè)務(wù)域中去尋找答案和線索。
架構(gòu)需求分解包括了前面說的業(yè)務(wù)需求分解、業(yè)務(wù)功能需求分解、技術(shù)需求分解，通常架構(gòu)需求分解和它們有部分是重疊的，例如在技術(shù)需求和架構(gòu)需求中都有性能方面的架構(gòu)分解。架構(gòu)需求分解保證我們的分解是完備的，沒有遺漏。
04
分解緯度
架構(gòu)分解就是從多個維度多層次對系統(tǒng)進行分解，識別出架構(gòu)元素，逐步精化、豐富系統(tǒng)架構(gòu)的過程。從上面可以總結(jié)出，緯度大致有，業(yè)務(wù)緯度、業(yè)務(wù)功能緯度、技術(shù)緯度，涉眾緯度。
根據(jù)具體的系統(tǒng)，還可發(fā)掘出許多分解維度，如時間維度、物理空間維度、優(yōu)先級維度、職責(zé)角色維度（不同的角色）、客戶端維度、調(diào)用方維度（不同的調(diào)用方）、請求類型維度、數(shù)據(jù)維度、數(shù)據(jù)處理維度。緯度就看架構(gòu)師對于需求的理解程度多深刻。
05
分解戰(zhàn)術(shù)
將在架構(gòu)層面應(yīng)對非功能需求特性的架構(gòu)模式或架構(gòu)策略稱為戰(zhàn)術(shù)，例如對可用性，常用的戰(zhàn)術(shù)包括：冗余、錯誤檢測。
06
分解的粒度
多維度多層次分解到什么粒度才停止？這個沒有統(tǒng)一的標(biāo)準(zhǔn)，通常要能進行并行開發(fā)，能指導(dǎo)后續(xù)的詳細(xì)設(shè)計。需要根據(jù)具體的產(chǎn)品或項目來定，有的到模塊級別就行，對關(guān)鍵的部分，可以到類級別。
07
分解的時機
架構(gòu)分解的時機通常就是架構(gòu)改造演化的時機。當(dāng)架構(gòu)出現(xiàn)腐化和臭味，已經(jīng)難以滿足關(guān)鍵涉眾的關(guān)鍵需求，例如用戶的響應(yīng)速度越來越慢已經(jīng)接近臨界值，并且根據(jù)預(yù)見，響應(yīng)速度還有可能繼續(xù)較低；開發(fā)人員越來越難以維護，這個時候可以考慮進行架構(gòu)演化，對架構(gòu)進行改造。當(dāng)然如果能提前預(yù)見系統(tǒng)的問題，經(jīng)過慎重評估后，在問題發(fā)生之前，提前一段時間進行架構(gòu)演化也是可以的。
要注意的問題是不要過度分解，過早分解，這樣做除了增加成本，還可能帶來風(fēng)險。例如很多系統(tǒng)在建設(shè)初期，考慮到規(guī)模較小和快速上線，通常都是一個整體的系統(tǒng)，不會進行大的架構(gòu)分解，以后隨著需求和規(guī)模的逐漸增加，會逐步進行架構(gòu)改造和架構(gòu)分解。
03
總結(jié)
分解作為架構(gòu)設(shè)計中關(guān)鍵的步驟，架構(gòu)分解沒有成熟的方法體系來指導(dǎo)架構(gòu)師，但是以上的過程和緯度可以作為一定的參考來進行架構(gòu)分解，架構(gòu)分解的關(guān)鍵點在于分解緯度和分解戰(zhàn)術(shù)，希望能幫助架構(gòu)師們。后續(xù)我會繼續(xù)講解其他套路。
