在軟件開發領域，架構設計是確保系統高效、穩定運行的重要環節或者稱之為重要動作。無論架構從簡單到復雜，還是從復雜回歸簡潔的演變過程。在這個過程中，又無論是初創公司還是大型企業，架構提效始終是技術團隊的核心追求。本文將從穩定、性能、代碼三大維度出發，結合實戰經驗，探討如何有效提升架構效能。

為什么要選擇或者認為這三個維度是必要要素呢？

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

當然架構也有自身的矛盾統一，在架構提效上，系統的運行正常和問題頻出是一對矛盾，功能的快和慢是一對矛盾，工程的整潔有序和無序是一對矛盾。這三對矛盾正是架構提效的矛盾。

如果不穩定，系統三天兩頭出故障，研發人員成了救火隊員，系統的效率將無從談起，穩定是我們談架構效率的基礎。如果性能不高，在網絡基礎環境穩定的情況下，訪問一個頁面3S才響應，那我們也不好意思說架構有效率。如果代碼亂成一鍋粥，比如大段大段面條式的代碼，再比如滿眼望去N多個if結構語句，研發人員加一個功能都要查找好久，也是無顏談效率。

因此，我們認為，穩定、性能、代碼是架構提效矛盾中的主要方面。接下來我們將從這三個主要方面去介紹。

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

穩定：架構的基石與守護神

“萬事萬物都是運動的，發展的”。業務功能變多，用戶數量變多，團隊規模變大。如果沒有規則和規范的引導和約束，系統逐漸野蠻生長，逐漸碎片化。那么，我們的系統何談穩定呢。

我們就希望能找到這樣的一種規則、規范 -- 正交分解或者叫做正交設計。

架構設計的過程就是一個業務正交分解的過程。

架構設計并不僅僅是技術層面的規劃，更重要的是對業務邏輯的深入理解和把握。通過正交分解，我們可以將復雜的業務系統拆解成若干個相互獨立但又彼此關聯的模塊或組件。這些模塊或組件在保持功能完整性的同時，還能實現高度的內聚和松散的耦合，從而提高系統的可擴展性、可維護性和可重用性。

正交分解的關鍵在于消除重復、分離關注點和管理依賴。通過這一方法，我們可以將業務系統中的公共部分和可變部分進行明確的劃分，從而實現對業務邏輯的精準掌控。在架構設計過程中，我們需要不斷地對業務進行抽象和分解，直至得到一系列規模可控、結構清晰的小模塊。這些小模塊通過組合和協作，能夠形成更加復雜且功能完善的軟件系統。

因此，正交分解的思想是我們架構設計保障穩定的重要方法基礎。

性能：速度與效率的雙重考驗

想快，就使用“戰術設計”。曾經這是很多程序員的法寶，因為他們認為這樣開發“確實快”。

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

想快的“戰術設計”會造成常見的下面這樣的情況。

“團隊新人不熟悉系統，為了急于上線一個特性，又不想影響到系統的其他部分，就會很自然地在某個地方加一個 flag，然后在所有需要改動的地方加 if 判斷，而不是去調整系統設計以適應新的問題空間。”

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

小張在瀏覽了系統的代碼庫后，發現要全面理解并調整整個系統設計以適應新的特性，需要花費大量的時間和精力。他深知自己作為新人，在這方面還有所欠缺，因此，他決定采取一個他認為更為“高效”的方法：在某個關鍵位置添加一個臨時的標志位（flag），然后在所有需要改動的地方都加上if判斷，以確保新特性能夠按時上線，同時盡量減少對現有系統的影響。

雖然這種方法在短時間內確實讓新特性得以順利上線，但團隊中的資深成員很快便發現了潛在的問題。這種做法雖然看似快速解決了問題，但實際上卻在系統中埋下了隱患。它不僅增加了代碼的復雜性，降低了代碼的可讀性和可維護性，還可能在未來引發更多的bug和性能問題。更重要的是，這種做法違背了軟件開發中的最佳實踐，即應通過優化系統設計來適應新的問題空間，而不是通過添加臨時性的補丁來解決問題。

“幾乎每個軟件開發組織都有至少一個將戰術編程發揮到極致的開發人員：戰術龍卷風”，而且常常被視為團隊”英雄“，因為能“快速完成任務且高產”。

“戰術龍卷風”通常以戰術編程為主要手段，即采用最快速、最直接的方法來解決當前的問題，而不考慮長遠的影響和代碼的可持續性。這種方法在初次使用時往往能夠取得顯著的效果，任務完成得既快又好，贏得了團隊成員的贊譽和領導的認可。

然而，隨著時間的推移，“戰術龍卷風”所留下的隱患逐漸暴露出來。由于缺乏對系統設計的深入理解和長遠規劃，他的代碼往往難以維護和擴展。當需要添加新功能或修復bug時，團隊成員往往需要花費更多的時間和精力來理解和修改他的代碼。因此，第二次和第三次修改時，效率會大幅下降，甚至可能引發新的問題。

實際造成結果：第一次快、第二次慢、第三次更慢。

代碼：簡潔與優雅的雙重追求

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

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

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

這個時候，一般會出現兩類現象，一類是業務層（biz）變的臃腫，能力層（domain）變的單薄。另一類是出現了網狀調用。而且這兩類現象也很有可能是混合在一起出現。

這兩類現象會直接帶來下面4種結果。

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

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

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

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

很顯然，到這里，這樣的結構現狀，代碼現狀，已經遠離了我們簡潔和優雅的初衷。也談不上提效了。

到此，我們介紹了架構提效中的穩定、性能和代碼這三個主要的方面，限于篇幅和架構本身的實踐性，還需要我們在架構提效上進行持續的優化。需要我們在穩定、性能、代碼三大維度上不斷探索和實踐。通過高可用架構設計、性能優化策略、模塊化與解耦、代碼質量與規范等措施，我們可以構建一個既穩定又高效，且易于維護和擴展的系統。

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

架構的發展本身也是對抗熵增這一矛盾的過程，我們上面描述的穩定、性能和代碼中的矛盾方面有是圍繞和關聯這一主要矛盾的。在這個過程中不僅有系統的有序變無序，也有組織的簡單變復雜。我們既要關注技術層面的提升，更要注重團隊協作、知識共享和持續改進的文化建設。只有這樣，我們才能在快速變化的市場環境中，保持競爭力，不斷前行。

最后，如果您對文章中的表述和觀點有任何問題，亦或者您當前也正在致力于架構提效方面的工作，我們可以一起學習交流，微信號：wangxindong2015。

REF：
1、https://time.geekbang.org/column/article/167844 如何判斷架構設計的優劣
2、https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/ 軟件設計的哲學
3、https://mp.weixin.qq.com/s/jJzzJIGozOpt7KaXwBS3Ww 業務系統架構實踐總結
4、《矛盾論》


審核編輯 黃宇