建站
咨詢
售后
建站咨詢
新聞中心
本篇文章我們將從軟件系統(tǒng)的價值出發(fā)，首先認識架構工作的價值和目標， 接下來依次了解架構設計的基礎、指導思想(設計原則)、組件拆分的方法和粒度、組件之間依賴設計、組件邊界多種解耦方式以及取舍、降低組件之間通信成本的方法，從而最終指導我們做出正確的架構決策和架構設計。
公司主營業(yè)務：網站設計制作、成都網站設計、移動網站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出武山免費做網站回饋大家。
一、軟件系統(tǒng)的價值
架構是軟件系統(tǒng)的一部分，所以要明白架構的價值，首先要明確軟件系統(tǒng)的價值。軟件系統(tǒng)的價值有兩方面，行為價值和架構價值。
行為價值是軟件的核心價值，包括需求的實現(xiàn)，以及可用性保障(功能性 bug 、性能、穩(wěn)定性)。這幾乎占據了我們90%的工作內容，支撐業(yè)務先贏是我們工程師的首要責任。如果業(yè)務是明確的、穩(wěn)定的，架構的價值就可以忽略不計，但業(yè)務通常是不明確的、飛速發(fā)展的，這時架構就無比重要，因為架構的價值就是讓我們的軟件(Software)更軟(Soft)?？梢詮膬煞矫胬斫猓?/p>
- 當需求變更時，所需的軟件變更必須簡單方便。
- 變更實施的難度應該和變更的范疇(scope)成等比，而與變更的具體形狀(shape)無關。
當我們只關注行為價值，不關注架構價值時，會發(fā)生什么事情?這是書中記錄的一個真實案例，隨著版本迭代，工程師團隊的規(guī)模持續(xù)增長，但總代碼行數卻趨于穩(wěn)定，相對應的，每行代碼的變更成本升高、工程師的生產效率降低。從老板的視角，就是公司的成本增長迅猛，如果營收跟不上就要開始賠錢啦。
可見架構價值重要性，接下來從著名的緊急重要矩陣出發(fā)，看我們如何處理好行為價值和架構價值的關系。
重要緊急矩陣中，做事的順序是這樣的：1.重要且緊急 > 2.重要不緊急 > 3.不重要但緊急 > 4.不重要且不緊急。實現(xiàn)行為價值的需求通常是 PD 提出的，都比較緊急，但并不總是特別重要;架構價值的工作內容，通常是開發(fā)同學提出的，都很重要但基本不是很緊急，短期內不做也死不了。所以行為價值的事情落在1和3(重要且緊急、不重要但緊急)，而架構價值落在2(重要不緊急)。我們開發(fā)同學，在低頭敲代碼之前，一定要把雜糅在一起的1和3分開，把我們架構工作插進去。
二、架構工作的目標
前面講解了架構價值，追求架構價值就是架構工作的目標，說白了，就是用最少的人力成本滿足構建和維護該系統(tǒng)的需求，再細致一些，就是支撐軟件系統(tǒng)的全生命周期，讓系統(tǒng)便于理解、易于修改、方便維護、輕松部署。對于生命周期里的每個環(huán)節(jié)，優(yōu)秀的架構都有不同的追求：
- 開發(fā)階段：組件不要使用大量復雜的腳手架;不同團隊負責不同的組件，避免不必要的協(xié)作。
- 部署階段：部署工作不要依賴成堆的腳本和配置文件;組件越多部署工作越繁重，而部署工作本身是沒有價值的，做的越少越好，所以要減少組件數量。
- 運行階段：架構設計要考慮到不同的吞吐量、不同的響應時長要求;架構應起到揭示系統(tǒng)運行的作用：用例、功能、行為設置應該都是對開發(fā)者可見的一級實體，以類、函數或模塊的形式占據明顯位置，命名能清晰地描述對應的功能。
- 維護階段：減少探秘成本和風險。探秘成本是對現(xiàn)有軟件系統(tǒng)的挖掘工作，確定新功能或修復問題的***位置和方式。風險是做改動時，可能衍生出新的問題。
三、編程范式
其實所謂架構就是限制，限制源碼放在哪里、限制依賴、限制通信的方式，但這些限制比較上層。編程范式是最基礎的限制，它限制我們的控制流和數據流：結構化編程限制了控制權的直接轉移，面向對象編程限制了控制權的間接轉移，函數式編程限制了賦值，相信你看到這里一定一臉懵逼，啥叫控制權的直接轉移，啥叫控制權的間接轉移，不要著急，后邊詳細講解。
這三個編程范式最近的一個也有半個世紀的歷史了，半個世紀以來沒有提出新的編程范式，以后可能也不會了。因為編程范式的意義在于限制，限制了控制權轉移限制了數據賦值，其他也沒啥可限制的了。很有意思的是，這三個編程范式提出的時間順序可能與大家的直覺相反，從前到后的順序為：函數式編程(1936年)、面向對象編程(1966年)、結構化編程(1968年)。
1.結構化編程
結構化編程證明了人們可以用順序結構、分支結構、循環(huán)結構這三種結構構造出任何程序，并限制了 goto 的使用。遵守結構化編程，工程師就可以像數學家一樣對自己的程序進行推理證明，用代碼將一些已證明可用的結構串聯(lián)起來，只要自行證明這些額外代碼是確定的，就可以推導出整個程序的正確性。
前面提到結構化編程對控制權的直接轉移進行了限制，其實就是限制了 goto 語句。什么叫做控制權的直接轉移?就是函數調用或者 goto 語句，代碼在原來的流程里不繼續(xù)執(zhí)行了，轉而去執(zhí)行別的代碼，并且你指明了執(zhí)行什么代碼。為什么要限制 goto 語句?因為 goto 語句的一些用法會導致某個模塊無法被遞歸拆分成更小的、可證明的單元。而采用分解法將大型問題拆分正是結構化編程的核心價值。
其實遵守結構化編程，工程師們也無法像數學家那樣證明自己的程序是正確的，只能像物理學家一樣，說自己的程序暫時沒被證偽(沒被找到bug)。數學公式和物理公式的***區(qū)別，就是數學公式可被證明，而物理公式無法被證明，只要目前的實驗數據沒把它證偽，我們就認為它是正確的。程序也是一樣，所有的 test case 都通過了，沒發(fā)現(xiàn)問題，我們就認為這段程序是正確的。
2.面向對象編程
面向對象編程包括封裝、繼承和多態(tài)，從架構的角度，這里只關注多態(tài)。多態(tài)讓我們更方便、安全地通過函數調用的方式進行組件間通信，它也是依賴反轉(讓依賴與控制流方向相反)的基礎。
在非面向對象的編程語言中，我們如何在互相解耦的組件間實現(xiàn)函數調用?答案是函數指針。比如采用C語言編寫的操作系統(tǒng)中，定義了如下的結構體來解耦具體的IO設備， IO 設備的驅動程序只需要把函數指針指到自己的實現(xiàn)就可以了。
struct FILE { void (*open)(char* name, int mode); void (*close)(); int (*read)(); void (*write)(char); void (*seek)(long index, int mode);}
這種通過函數指針進行組件間通信的方式非常脆弱，工程師必須嚴格按照約定初始化函數指針，并嚴格地按照約定來調用這些指針，只要一個人沒有遵守約定，整個程序都會產生極其難以跟蹤和消除的 Bug。所以面向對象編程限制了函數指針的使用，通過接口-實現(xiàn)、抽象類-繼承等多態(tài)的方式來替代。
前面提到面向對象編程對控制權的間接轉移進行了限制，其實就是限制了函數指針的使用。什么叫做控制權的間接轉移?就是代碼在原來的流程里不繼續(xù)執(zhí)行了，轉而去執(zhí)行別的代碼，但具體執(zhí)行了啥代碼你也不知道，你只調了個函數指針或者接口。
3.函數式編程
函數式編程有很多種定義很多種特性，這里從架構的角度，只關注它的沒有副作用和不修改狀態(tài)。函數式編程中，函數要保持獨立，所有功能就是返回一個新的值，沒有其他行為，尤其是不得修改外部變量的值。前面提到函數式編程對賦值進行了限制，指的就是這個特性。
在架構領域所有的競爭問題、死鎖問題、并發(fā)問題都是由可變變量導致的。如果有足夠大的存儲量和計算量，應用程序可以用事件溯源的方式，用完全不可變的函數式編程，只通過事務記錄從頭計算狀態(tài)，就避免了前面提到的幾個問題。目前要讓一個軟件系統(tǒng)完全沒有可變變量是不現(xiàn)實的，但是我們可以通過將需要修改狀態(tài)的部分和不需要修改的部分分隔成單獨的組件，在不需要修改狀態(tài)的組件中使用函數式編程，提高系統(tǒng)的穩(wěn)定性和效率。
綜上，沒有結構化編程，程序就無法從一塊塊可證偽的邏輯搭建，沒有面向對象編程，跨越組件邊界會是一個非常麻煩而危險的過程，而函數式編程，讓組件更加高效而穩(wěn)定。沒有編程范式，架構設計將無從談起。
四、設計原則
和編程范式相比，設計原則和架構的關系更加緊密，設計原則就是架構設計的指導思想，它指導我們如何將數據和函數組織成類，如何將類鏈接起來成為組件和程序。反向來說，架構的主要工作就是將軟件拆解為組件，設計原則指導我們如何拆解、拆解的粒度、組件間依賴的方向、組件解耦的方式等。
設計原則有很多，我們進行架構設計的主導原則是 OCP(開閉原則)，在類和代碼的層級上有：SRP(單一職責原則)、LSP(里氏替換原則)、ISP(接口隔離原則)、DIP(依賴反轉原則);在組件的層級上有：REP(復用、發(fā)布等同原則)、 CCP(共同閉包原則)、CRP(共同復用原則)，處理組件依賴問題的三原則：無依賴環(huán)原則、穩(wěn)定依賴原則、穩(wěn)定抽象原則。
1.OCP(開閉原則)
設計良好的軟件應該易于擴展，同時抗拒修改。這是我們進行架構設計的主導原則，其他的原則都為這條原則服務。
2.SRP(單一職責原則)
任何一個軟件模塊，都應該有且只有一個被修改的原因，“被修改的原因“指系統(tǒng)的用戶或所有者，翻譯一下就是，任何模塊只對一個用戶的價值負責。該原則指導我們如何拆分組件。
舉個例子，CTO 和 COO 都要統(tǒng)計員工的工時，當前他們要求的統(tǒng)計方式可能是相同的，我們復用一套代碼，這時 COO 說周末的工時統(tǒng)計要乘以二，按照這個需求修改完代碼，CTO 可能就要過來罵街了。當然這是個非常淺顯的例子，實際項目中也有很多代碼服務于多個價值主體，這帶來很大的探秘成本和修改風險。
另外當一份代碼有多個所有者時，就會產生代碼合并沖突的問題。
3.LSP(里氏替換原則)
當用同一接口的不同實現(xiàn)互相替換時，系統(tǒng)的行為應該保持不變。該原則指導的是接口與其實現(xiàn)方式。
你一定很疑惑，實現(xiàn)了同一個接口，他們的行為也肯定是一致的呀，還真不一定。假設認為矩形的系統(tǒng)行為是：面積=寬*高，讓正方形實現(xiàn)矩形的接口，在調用 setW 和 setH 時，正方形做的其實是同一個事情，設置它的邊長。這時下邊的單元測試用矩形能通過，用正方形就不行，實現(xiàn)同樣的接口，但是系統(tǒng)行為變了，這是違反 LSP 的經典案例。
Rectangle r = ...r.setW(5);r.setH(2);assert(r.area() == 10);
4.ISP(接口隔離原則)
不依賴任何不需要的方法、類或組件。該原則指導我們的接口設計。
當我們依賴一個接口但只用到了其中的部分方法時，其實我們已經依賴了不需要的方法或類，當這些方法或類有變更時，會引起我們類的重新編譯，或者引起我們組件的重新部署，這些都是不必要的。所以我們***定義個小接口，把用到的方法拆出來。
5.DIP(依賴反轉原則)
跨越組建邊界的依賴方向永遠與控制流的方向相反。該原則指導我們設計組件間依賴的方向。
依賴反轉原則是個可操作性非常強的原則，當你要修改組件間的依賴方向時，將需要進行組件間通信的類抽象為接口，接口放在邊界的哪邊，依賴就指向哪邊。
6.REP(復用、發(fā)布等同原則)
軟件復用的最小粒度應等同于其發(fā)布的最小粒度。直白地說，就是要復用一段代碼就把它抽成組件。該原則指導我們組件拆分的粒度。
7.CCP(共同閉包原則)
為了相同目的而同時修改的類，應該放在同一個組件中。CCP 原則是 SRP 原則在組件層面的描述。該原則指導我們組件拆分的粒度。
對大部分應用程序而言，可維護性的重要性遠遠大于可復用性，由同一個原因引起的代碼修改，***在同一個組件中，如果分散在多個組件中，那么開發(fā)、提交、部署的成本都會上升。
8.CRP(共同復用原則)
不要強迫一個組件依賴它不需要的東西。CRP 原則是 ISP 原則在組件層面的描述。該原則指導我們組件拆分的粒度。
相信你一定有這種經歷，集成了組件A，但組件A依賴了組件B、C。即使組件B、C 你完全用不到，也不得不集成進來。這是因為你只用到了組件A的部分能力，組件A中額外的能力帶來了額外的依賴。如果遵循共同復用原則，你需要把A拆分，只保留你要用的部分。
REP、CCP、CRP 三個原則之間存在彼此競爭的關系，REP 和 CCP 是黏合性原則，它們會讓組件變得更大，而 CRP 原則是排除性原則，它會讓組件變小。遵守REP、CCP 而忽略 CRP ，就會依賴了太多沒有用到的組件和類，而這些組件或類的變動會導致你自己的組件進行太多不必要的發(fā)布;遵守 REP 、CRP 而忽略 CCP，因為組件拆分的太細了，一個需求變更可能要改n個組件，帶來的成本也是巨大的。
優(yōu)秀的架構師應該能在上述三角形張力區(qū)域中定位一個最適合目前研發(fā)團隊狀態(tài)的位置，例如在項目早期，CCP比REP更重要，隨著項目的發(fā)展，這個最合適的位置也要不停調整。
9.無依賴環(huán)原則
健康的依賴應該是個有向無環(huán)圖(DAG)，互相依賴的組件，實際上組成了一個大組件，這些組件要一起發(fā)布、一起做單元測試。我們可以通過依賴反轉原則 DIP 來解除依賴環(huán)。
10.穩(wěn)定依賴原則
依賴必須要指向更穩(wěn)定的方向。
這里組件的穩(wěn)定性指的是它的變更成本，和它變更的頻繁度沒有直接的關聯(lián)(變更的頻繁程度與需求的穩(wěn)定性更加相關)。影響組件的變更成本的因素有很多，比如組件的代碼量大小、復雜度、清晰度等等，最最重要的因素是依賴它的組件數量，讓組件難以修改的一個最直接的辦法就是讓很多其他組件依賴于它!
組件穩(wěn)定性的定量化衡量指標是：不穩(wěn)定性(I) = 出向依賴數量 / (入向依賴數量 + 出向依賴數量)。如果發(fā)現(xiàn)違反穩(wěn)定依賴原則的地方，解決的辦法也是通過 DIP 來反轉依賴。
11.穩(wěn)定抽象原則
一個組件的抽象化程度應該與其穩(wěn)定性保持一致。為了防止高階架構設計和高階策略難以修改，通常抽象出穩(wěn)定的接口、抽象類為單獨的組件，讓具體實現(xiàn)的組件依賴于接口組件，這樣它的穩(wěn)定性就不會影響它的擴展性。
組件抽象化程度的定量化描述是：抽象程度(A)= 組件中抽象類和接口的數量 / 組件中類的數量。
將不穩(wěn)定性(I)作為橫軸，抽象程度(A)作為縱軸，那么最穩(wěn)定、只包含抽象類和接口的組件應該位于左上角(0，1)，最不穩(wěn)定、只包含具體實現(xiàn)類，沒有任何接口的組件應該位于右下角(1，0)，他們連線就是主序列線，位于線上的組件，他們的穩(wěn)定性和抽象程度相匹配，是設計良好的組件。位于(0，0)周圍區(qū)域的組件，它們是非常穩(wěn)定(注意這里的穩(wěn)定指的是變更成本)并且非常具體的組件，因為他們的抽象程度低，決定了他們經常改動的命運，但是又有許多其他組件依賴他們，改起來非常痛苦，所以這個區(qū)域叫做痛苦區(qū)。右上角區(qū)域的組件，沒有其他組件依賴他們，他們自身的抽象程度又很高，很有可能是陳年的老代碼，所以這個區(qū)域叫做無用區(qū)。
另外，可以用點距離主序列線的距離 Z 來表示組件是否遵循穩(wěn)定抽象原則，Z 越大表示組件越違背穩(wěn)定依賴原則。
五、架構工作的基本方針
了解了編程范式和設計原則，接下來我們看看如何應用他們拆分組件、處理組件依賴和組件邊界。架構工作有兩個方針：
盡可能長時間地保留盡可能多的可選項。這里的可選項指的是無關緊要的細節(jié)設計，比如具體選用哪個存儲方式、哪種數據庫，或者采用哪種 Web 框架。業(yè)務代碼要和這些可選項解耦，數據庫或者框架應該做到像插件一樣切換，業(yè)務層對這個切換的過程應該做到完全無感。
低層次解耦方式能解決的，不要用高層次解耦方式。組件之間的解耦方式后邊細講，這里強調的是邊界處理越完善，開發(fā)和部署成本越高。所以不完全邊界能解決的，不要用完全邊界，低層次解耦能解決的，不要用高層次解耦。
六、組件拆分
首先要給組件下個定義：組件是一組描述如何將輸入轉化為輸出的策略語句的集合，在同一個組件中，策略的變更原因、時間、層次相同。
從定義就可以看出，組件拆分需要在兩個維度進行：按層次拆分、按變更原因拆分。
這里的變更原因就是業(yè)務用例，按變更原因進行組件拆分的例子是：訂單組件、聊天組件。按層次拆分，可以拆為：業(yè)務實體、用例、接口適配器、框架與驅動程序。
業(yè)務實體：關鍵業(yè)務數據和業(yè)務邏輯的集合，與界面無關、與存儲無關、與框架無關，只有業(yè)務邏輯。
用例：特定場景下的業(yè)務邏輯，可以理解為 輸入 + 業(yè)務實體 + 輸出 = 用例。
接口適配器：包含整個整個MVC，以及對存儲、設備、界面等的接口聲明和使用。
一條策略距離系統(tǒng)的輸入、輸出越遠，它的層次越高，所以業(yè)務實體是***的層，框架與驅動程序是***的層。
七、組件依賴處理
前面拆好了組件分好了層，依賴就很好處理了：依賴關系與數據流控制流脫鉤，而與組件所在層次掛鉤，始終從低層次指向高層次，如下圖。越具體的策略處在的層級越低，越插件化。切換數據庫是框架驅動層的事情，接口適配器完全無感知，切換展示器是接口適配器層面的事情，用例完全無感知，而切換用例也不會影響到業(yè)務實體。
八、組件邊界處理
一個完整的組件邊界包括哪些內容?首先跨越組件邊界進行通信的兩個類都要抽象為接口，另外需要聲明專用的輸入數據模型、聲明專用的返回數據模型，想一想每次進行通信時都要進行的數據模型轉換，就能理解維護一個組件邊界的成本有多高。
除非必要，我們應該盡量使用不完全邊界來降低維護組件邊界的成本。不完全邊界有三種方式：
省掉***一步：聲明好接口，做好分割后，仍然放在一個組件中，等到時機成熟時再拆出來獨立編譯部署。
單向邊界：正常的邊際至少有兩個接口，分別抽象調用方和被調用方。這里只定義一個接口，高層次組件用接口調用低層次組件，而低層次組件直接引用高層次組件的類。
門戶模式：控制權的間接轉移不用接口和實現(xiàn)去做，而是用門戶類去做，用這種方式連接口都不用聲明了。
除了完全邊界和不完全邊界的區(qū)分，邊界的解耦方式也可以分為3個層次：
源碼層次：做了接口、類依賴上的解耦，但是放在同一個組件中，通常放在不同的路徑下。和不完全邊界的省略***一步一樣。
部署層次：拆分為可以獨立部署的不同組件，比如 iOS 的靜態(tài)庫、動態(tài)庫，真正運行時處于同一臺物理機器上，組件之間通常通過函數調用通訊。
服務層次：運行在不同的機器上，通過 url 、網絡數據包等方式進行通訊。
從上到下，(開發(fā)、部署)成本依次升高，如果低層次的解耦已經滿足需要，不要進行高層次的解耦。
本文標題：架構整潔之道，看這一篇就夠了！
分享鏈接：http://m.fisionsoft.com.cn/article/dhhcjop.html
