在軟件開發(fā)領(lǐng)域，架構(gòu)設(shè)計(jì)是確保系統(tǒng)高效、穩(wěn)定運(yùn)行的重要環(huán)節(jié)或者稱之為重要動作。無論架構(gòu)從簡單到復(fù)雜，還是從復(fù)雜回歸簡潔的演變過程。在這個過程中，又無論是初創(chuàng)公司還是大型企業(yè)，架構(gòu)提效始終是技術(shù)團(tuán)隊(duì)的核心追求。本文將從穩(wěn)定、性能、代碼三大維度出發(fā)，結(jié)合實(shí)戰(zhàn)經(jīng)驗(yàn)，探討如何有效提升架構(gòu)效能。

為什么要選擇或者認(rèn)為這三個維度是必要要素呢？

“一切事物中包含的矛盾方面的相互依賴和相互斗爭，決定一切事物的生命，推動一切事物的發(fā)展。沒有什么事物是不包含矛盾的，沒有矛盾就沒有世界。”

當(dāng)然架構(gòu)也有自身的矛盾統(tǒng)一，在架構(gòu)提效上，系統(tǒng)的運(yùn)行正常和問題頻出是一對矛盾，功能的快和慢是一對矛盾，工程的整潔有序和無序是一對矛盾。這三對矛盾正是架構(gòu)提效的矛盾。

如果不穩(wěn)定，系統(tǒng)三天兩頭出故障，研發(fā)人員成了救火隊(duì)員，系統(tǒng)的效率將無從談起，穩(wěn)定是我們談架構(gòu)效率的基礎(chǔ)。如果性能不高，在網(wǎng)絡(luò)基礎(chǔ)環(huán)境穩(wěn)定的情況下，訪問一個頁面3S才響應(yīng)，那我們也不好意思說架構(gòu)有效率。如果代碼亂成一鍋粥，比如大段大段面條式的代碼，再比如滿眼望去N多個if結(jié)構(gòu)語句，研發(fā)人員加一個功能都要查找好久，也是無顏談效率。

因此，我們認(rèn)為，穩(wěn)定、性能、代碼是架構(gòu)提效矛盾中的主要方面。接下來我們將從這三個主要方面去介紹。

軟件工程發(fā)展了這么多年，高可用、高擴(kuò)展、高并發(fā)已經(jīng)有大量的文章篇幅，從宏觀的角度去講如何做微服務(wù)、如何分庫分表，如何使用緩存等等。因此呢，本篇文章想聚焦到架構(gòu)矛盾的微觀層面，也就是偏工程結(jié)構(gòu)、偏代碼方面去闡述這三個要素。另外本篇文章的思想也參考了前輩們的研究成果，我也附在了文末。

穩(wěn)定：架構(gòu)的基石與守護(hù)神

“萬事萬物都是運(yùn)動的，發(fā)展的”。業(yè)務(wù)功能變多，用戶數(shù)量變多，團(tuán)隊(duì)規(guī)模變大。如果沒有規(guī)則和規(guī)范的引導(dǎo)和約束，系統(tǒng)逐漸野蠻生長，逐漸碎片化。那么，我們的系統(tǒng)何談穩(wěn)定呢。

我們就希望能找到這樣的一種規(guī)則、規(guī)范 -- 正交分解或者叫做正交設(shè)計(jì)。

架構(gòu)設(shè)計(jì)的過程就是一個業(yè)務(wù)正交分解的過程。

架構(gòu)設(shè)計(jì)并不僅僅是技術(shù)層面的規(guī)劃，更重要的是對業(yè)務(wù)邏輯的深入理解和把握。通過正交分解，我們可以將復(fù)雜的業(yè)務(wù)系統(tǒng)拆解成若干個相互獨(dú)立但又彼此關(guān)聯(lián)的模塊或組件。這些模塊或組件在保持功能完整性的同時(shí)，還能實(shí)現(xiàn)高度的內(nèi)聚和松散的耦合，從而提高系統(tǒng)的可擴(kuò)展性、可維護(hù)性和可重用性。

正交分解的關(guān)鍵在于消除重復(fù)、分離關(guān)注點(diǎn)和管理依賴。通過這一方法，我們可以將業(yè)務(wù)系統(tǒng)中的公共部分和可變部分進(jìn)行明確的劃分，從而實(shí)現(xiàn)對業(yè)務(wù)邏輯的精準(zhǔn)掌控。在架構(gòu)設(shè)計(jì)過程中，我們需要不斷地對業(yè)務(wù)進(jìn)行抽象和分解，直至得到一系列規(guī)模可控、結(jié)構(gòu)清晰的小模塊。這些小模塊通過組合和協(xié)作，能夠形成更加復(fù)雜且功能完善的軟件系統(tǒng)。

因此，正交分解的思想是我們架構(gòu)設(shè)計(jì)保障穩(wěn)定的重要方法基礎(chǔ)。

性能：速度與效率的雙重考驗(yàn)

想快，就使用“戰(zhàn)術(shù)設(shè)計(jì)”。曾經(jīng)這是很多程序員的法寶，因?yàn)樗麄冋J(rèn)為這樣開發(fā)“確實(shí)快”。

大多數(shù)程序員以稱為戰(zhàn)術(shù)編程的心態(tài)來進(jìn)行軟件開發(fā)。在戰(zhàn)術(shù)方法中，主要重點(diǎn)是使某些功能正常工作，例如新功能或錯誤修復(fù)。乍一看，這似乎是完全合理的：還有什么比編寫有效的代碼更重要的呢？但是，戰(zhàn)術(shù)編程幾乎不可能產(chǎn)生出良好的系統(tǒng)設(shè)計(jì)。

想快的“戰(zhàn)術(shù)設(shè)計(jì)”會造成常見的下面這樣的情況。

“團(tuán)隊(duì)新人不熟悉系統(tǒng)，為了急于上線一個特性，又不想影響到系統(tǒng)的其他部分，就會很自然地在某個地方加一個 flag，然后在所有需要改動的地方加 if 判斷，而不是去調(diào)整系統(tǒng)設(shè)計(jì)以適應(yīng)新的問題空間。”

在一個充滿活力的軟件開發(fā)團(tuán)隊(duì)中，新成員小張剛剛加入不久。他對于團(tuán)隊(duì)正在使用的復(fù)雜系統(tǒng)還不是很熟悉，但面對緊迫的項(xiàng)目進(jìn)度和上級施加的壓力，他急于證明自己，并希望能盡快為團(tuán)隊(duì)做出貢獻(xiàn)。團(tuán)隊(duì)正計(jì)劃上線一個新的特性，這個特性需要在不干擾系統(tǒng)其他部分的前提下實(shí)現(xiàn)。

小張?jiān)跒g覽了系統(tǒng)的代碼庫后，發(fā)現(xiàn)要全面理解并調(diào)整整個系統(tǒng)設(shè)計(jì)以適應(yīng)新的特性，需要花費(fèi)大量的時(shí)間和精力。他深知自己作為新人，在這方面還有所欠缺，因此，他決定采取一個他認(rèn)為更為“高效”的方法：在某個關(guān)鍵位置添加一個臨時(shí)的標(biāo)志位（flag），然后在所有需要改動的地方都加上if判斷，以確保新特性能夠按時(shí)上線，同時(shí)盡量減少對現(xiàn)有系統(tǒng)的影響。

雖然這種方法在短時(shí)間內(nèi)確實(shí)讓新特性得以順利上線，但團(tuán)隊(duì)中的資深成員很快便發(fā)現(xiàn)了潛在的問題。這種做法雖然看似快速解決了問題，但實(shí)際上卻在系統(tǒng)中埋下了隱患。它不僅增加了代碼的復(fù)雜性，降低了代碼的可讀性和可維護(hù)性，還可能在未來引發(fā)更多的bug和性能問題。更重要的是，這種做法違背了軟件開發(fā)中的最佳實(shí)踐，即應(yīng)通過優(yōu)化系統(tǒng)設(shè)計(jì)來適應(yīng)新的問題空間，而不是通過添加臨時(shí)性的補(bǔ)丁來解決問題。

“幾乎每個軟件開發(fā)組織都有至少一個將戰(zhàn)術(shù)編程發(fā)揮到極致的開發(fā)人員：戰(zhàn)術(shù)龍卷風(fēng)”，而且常常被視為團(tuán)隊(duì)”英雄“，因?yàn)槟堋翱焖偻瓿扇蝿?wù)且高產(chǎn)”。

“戰(zhàn)術(shù)龍卷風(fēng)”通常以戰(zhàn)術(shù)編程為主要手段，即采用最快速、最直接的方法來解決當(dāng)前的問題，而不考慮長遠(yuǎn)的影響和代碼的可持續(xù)性。這種方法在初次使用時(shí)往往能夠取得顯著的效果，任務(wù)完成得既快又好，贏得了團(tuán)隊(duì)成員的贊譽(yù)和領(lǐng)導(dǎo)的認(rèn)可。

然而，隨著時(shí)間的推移，“戰(zhàn)術(shù)龍卷風(fēng)”所留下的隱患逐漸暴露出來。由于缺乏對系統(tǒng)設(shè)計(jì)的深入理解和長遠(yuǎn)規(guī)劃，他的代碼往往難以維護(hù)和擴(kuò)展。當(dāng)需要添加新功能或修復(fù)bug時(shí)，團(tuán)隊(duì)成員往往需要花費(fèi)更多的時(shí)間和精力來理解和修改他的代碼。因此，第二次和第三次修改時(shí)，效率會大幅下降，甚至可能引發(fā)新的問題。

實(shí)際造成結(jié)果：第一次快、第二次慢、第三次更慢。

代碼：簡潔與優(yōu)雅的雙重追求

我們做業(yè)務(wù)開發(fā)，代碼的優(yōu)雅簡潔，不能局限在一段方法，還是要從整個工程結(jié)構(gòu)然后在到類、到方法，這樣從宏觀到中觀再到微觀的整體去要求。我們的應(yīng)用工程結(jié)構(gòu)，常見大致分為四層。分別是api層、biz層、domain層和dao層。

這個時(shí)候我們就要很清晰地熟悉每一層的職責(zé)，然后將我們的代碼放入進(jìn)去。首先，api層的作用，正如它的名字一樣，是提供api服務(wù)的。向誰提供api呢，比如客戶端，比如APP端、pc端等等，公司外面的客戶，比如isv等。其次，biz層的作用，這一層也叫業(yè)務(wù)服務(wù)層。它主要負(fù)責(zé)編排。把一個業(yè)務(wù)場景下的主流程邏輯處理完成。這個主流程會涉及到多個原子接口，就在這層負(fù)責(zé)組裝。再次，domain層的作用，也叫做領(lǐng)域服務(wù)層。按照OO思想，領(lǐng)域編程的思維，我們的”厚對象“的代碼都在這層。比如訂單域、運(yùn)費(fèi)域等。這里對“這一層的位置”多說幾句，在沒有形成領(lǐng)域之前，這層一般叫service層，不過我們都是建議領(lǐng)域思維編寫代碼。最后是dao層，也就是我們的存儲層了，負(fù)責(zé)持久化。

在清晰了每一層的作用之后，如果我們的代碼職責(zé)也是按照這樣逐層放入的，那么大體是符合我們的整潔要求的。但是呢，隨著時(shí)間的推移，需求的增多和變化。原來整潔的工程結(jié)構(gòu)和代碼已經(jīng)不那么優(yōu)雅了。

這個時(shí)候，一般會出現(xiàn)兩類現(xiàn)象，一類是業(yè)務(wù)層（biz）變的臃腫，能力層（domain）變的單薄。另一類是出現(xiàn)了網(wǎng)狀調(diào)用。而且這兩類現(xiàn)象也很有可能是混合在一起出現(xiàn)。

這兩類現(xiàn)象會直接帶來下面4種結(jié)果。

1、biz層越來越”胖“。胖了之后，還長成了兩小層。上小層是面向單一業(yè)務(wù)場景的“業(yè)務(wù)biz層”，下小層成了通用場景可復(fù)用的“通用biz層”。

2、service層越來越”瘦“。當(dāng)service層變薄了以后，也就只能淪為service了，而這樣的service層跟dao層實(shí)際沒什么區(qū)別，更不能再稱之為domain層或者沒有機(jī)會演變成domain層。

3、但是也不是所有的service層都變瘦、變薄了。可能有的萎縮，有的膨脹。人員與設(shè)計(jì)的差異，導(dǎo)致顆粒度不一。

4、出現(xiàn)了網(wǎng)狀調(diào)用。原本biz-1 -> service-1 的實(shí)現(xiàn)鏈路下，隨著新增業(yè)務(wù)邏輯，又新起了一個service-2，鏈路演變成了biz-1 -> service-1-> service-2。“這樣的趨勢持續(xù)發(fā)展下去，會發(fā)現(xiàn)biz-1下的service調(diào)用鏈路越發(fā)的復(fù)雜，呈現(xiàn)為一顆深度調(diào)用樹，而biz層失去了業(yè)務(wù)編排的作用退化為一個業(yè)務(wù)場景入口的標(biāo)志符”。有可能后面繼續(xù)3-4-5-6，越挖越深，不見盡頭。

很顯然，到這里，這樣的結(jié)構(gòu)現(xiàn)狀，代碼現(xiàn)狀，已經(jīng)遠(yuǎn)離了我們簡潔和優(yōu)雅的初衷。也談不上提效了。

到此，我們介紹了架構(gòu)提效中的穩(wěn)定、性能和代碼這三個主要的方面，限于篇幅和架構(gòu)本身的實(shí)踐性，還需要我們在架構(gòu)提效上進(jìn)行持續(xù)的優(yōu)化。需要我們在穩(wěn)定、性能、代碼三大維度上不斷探索和實(shí)踐。通過高可用架構(gòu)設(shè)計(jì)、性能優(yōu)化策略、模塊化與解耦、代碼質(zhì)量與規(guī)范等措施，我們可以構(gòu)建一個既穩(wěn)定又高效，且易于維護(hù)和擴(kuò)展的系統(tǒng)。

“在復(fù)雜的事物發(fā)展過程中，有許多的矛盾存在，其中必有一種是主要的矛盾，由于它的存在和發(fā)展規(guī)定和影響著其他矛盾的存在和發(fā)展。”

架構(gòu)的發(fā)展本身也是對抗熵增這一矛盾的過程，我們上面描述的穩(wěn)定、性能和代碼中的矛盾方面有是圍繞和關(guān)聯(lián)這一主要矛盾的。在這個過程中不僅有系統(tǒng)的有序變無序，也有組織的簡單變復(fù)雜。我們既要關(guān)注技術(shù)層面的提升，更要注重團(tuán)隊(duì)協(xié)作、知識共享和持續(xù)改進(jìn)的文化建設(shè)。只有這樣，我們才能在快速變化的市場環(huán)境中，保持競爭力，不斷前行。

最后，如果您對文章中的表述和觀點(diǎn)有任何問題，亦或者您當(dāng)前也正在致力于架構(gòu)提效方面的工作，我們可以一起學(xué)習(xí)交流，微信號：wangxindong2015。

REF：
1、https://time.geekbang.org/column/article/167844 如何判斷架構(gòu)設(shè)計(jì)的優(yōu)劣
2、https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ 軟件設(shè)計(jì)的哲學(xué)
3、https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww 業(yè)務(wù)系統(tǒng)架構(gòu)實(shí)踐總結(jié)
4、《矛盾論》


審核編輯 黃宇