先講個小故事

如果給你一間兩室一廳的毛坯房，讓你設計屬于你自己的世界，相信你一定有非常多的想法：

• 不同的區域可以有完全不同的設計

• 家具擺放要兼顧美感和實用性

• 儲物空間要滿足未來不斷買買買的需求

• 電源插座個數、位置要滿足現在市面上不斷出現的新的電子化產品

• ……

裝修完畢，住進去的感覺真的是非常棒，一切都是按照自己的想法設計的，完美。

隨后，新需求來了，你結婚了，這個房間新增了一位主人。TA的想法可能和你的不完全一樣，TA也有很多東西要放，也有自己喜歡的生活方式，于是你的設計有一部分開始改變了原有的用途，甚至可能要重新裝修。

隨著人數的增加，需求也會不斷變化。你有了自己的寶寶，開始買大量的嬰兒用品，奶粉、紙尿褲、嬰兒床等等。以現在年輕人的工作節奏，大概都會叫雙方的老人過來幫忙帶孩子，老人的加入也會給房子的使用增添更多新的需求。

即使你很早就想到了這些，相信你也無法抵擋新增的需求帶來的沖擊。你一定遇到過想找個東西怎么也找不到，翻開衣柜和床底下的儲物空間，里面亂的讓你無法忍受的場景。

架構混沌的表現

軟件架構就像我們的房子一樣，隨著各種各樣的需求增加，我們劃分出來的各種組件都變得不再如最初設計的那么簡單，變得混亂，復雜。通常可能有以下幾種表現形式：

系統穩定性差

架構的腐化最初的表現大都是從用戶體驗側來反應出來的，比如不斷收到用戶的抱怨，不斷被吐槽功能無法正常使用等等。用戶的這種感覺就像在一個大且雜亂的儲物空間中找一個物品，不僅需要花費很多時間和體力，找到還不確定能正常使用，體驗非常差。

當軟件設計變得復雜時，架構設計、數據質量以及數據關系都變得復雜。甚至你會驚訝地發現前端一個請求過來，后端需要十幾個服務通力配合，通過幾十次的跨服務調用才能完成，這種情況下的性能和穩定性對于用戶體驗的影響都是致命的。

系統可擴展性差

對于開發團隊而言，上面提到的接口可能成為夢魘，幾乎沒人敢碰，因為誰也不知道改了會不會有新的問題。

這個問題原因有很多，比如服務之間存在循環依賴，服務冗余過多數據需要同步更新，還有些服務承擔了很多邊界之外的職責，也有因為設計不合理導致的多個服務合在一起才能完整處理一個業務，數據一致性問題頻頻發生。

這些設計的復雜度對擴展性影響非常大，牽一發而動全身，最后變得誰也不敢改動，只能推倒重來。就像同樣的戶型，不同的設計和使用會讓結果完全不同。如果儲物空間設計的不合理，功能區域劃分不合理，到處都堆滿了東西，老是覺得空間不足，最后也懶得收拾，也沒法再新增物品和家具，只能寄希望于換一個大點的房子，重新好好設計，但這往往是一廂情愿的奢望。

數據準確性差

數據是業務的核心，業務是各種數據變化遷移的邏輯組合，數據質量和一致性直接影響到業務的準確性，在分布式系統下，要做到這一點并不容易：

• 相關集成系統的數據流入質量差，臟數據多，導致流程很多無法走下去

• 業務邏輯設計復雜，導致一個操作要同時更新很多數據，在沒有分布式事務等特殊手段保證時，很容易導致一個服務的數據已經更新，其他服務的數據沒有更新而引起業務異常。

系統可用性差

系統集成也是出問題最多的場景之一，一個第三方集成系統出問題，經常會引起一系列的連鎖反應，導致系統的關鍵業務無法正常工作。遇到這種問題，既冤枉又無奈，但說到底還是沒有從設計上隔離其他系統對自己的影響。

各個系統面對的用戶不一樣，所以對系統的要求也不一樣。對于要求更嚴格的系統，它需要保證的響應時間和并發數可能都遠高于其他系統，當請求量較大時支撐系統很可能無法提供及時響應，導致核心業務系統也無法正常提供服務，這是常見的現象。另外基礎設施層面的異常也是讓系統可用性下降的非常直接且關鍵的原因之一。

怎么就混沌了呢？

上面的問題是任何一個架構師也不希望面對的，然而架構逐漸變得復雜難以維護，從長期來看是個必然的趨勢，但到底是哪些原因讓這個趨勢不可逆轉呢？

這里我們拋開人員能力的問題，雖然這個問題也不容忽視，但在討論當前這個話題時，我們假設團隊的開發人員都是盡了自己最大的努力來保證架構和代碼的整潔的，然后看看還有哪些因素是導致架構逐漸變的混沌復雜的，進而可以采取一些措施延緩架構的腐化。

上下文丟失造成的低認知

可以想象，當一個系統中只有一個服務，幾萬行代碼，任何一個開發人員都可以花一段時間理解且記住邏輯的細節，當業務需求變更，開發人員可以不進行任何調研就設計解決方案，甚至可以馬上和其他開發一起討論方案的合理性。

再試想，當業務不斷增長，系統逐漸變的復雜，服務擴充到幾十個甚至上百個，相信沒有一個開發人員可以說的清所有的邏輯細節，甚至很難找到一個開發人員可以說清其中一個他最熟悉的服務的所有實現細節。因為當業務變得復雜，都需要多個服務配合才能完成，邏輯鏈條很長，而人的腦容量畢竟有限，系統不斷增長的知識會逐漸超出人類所能記憶的范圍。

對于一直在這個軟件系統上工作的開發人員尚且如此，那么對于新加入的開發人員，可想而知，業務和系統的知識會更少，更難理解原有邏輯設計的上下文和決策原因。項目人員的更替是無法避免的，這種更替會讓團隊人員對于上下文知識變的越來越少，這種趨勢也是不可逆的。

上下文不足，對系統的認知有限，那么做出的設計和決策很容易出現問題，也就加快了系統復雜的速度。

系統大但邊界不清

設計系統的架構受制于產生這些設計的組織的溝通結構。—— 《康威定律》

隨著軟件系統逐漸變的復雜，服務越拆越多，但如果工作在這個系統上的開發人員還是一個團隊，根據康威定律，這個系統的架構也會趨向于一個整體，而不會像預期的各個服務各司其職那樣邊界分明。

這就好像在自己的房子里，房子的主人可以隨意的擺放自己的東西；而在一個合租的房子里，一定是有邊界的，即便有公共空間也有公共空間的規則，超越邊界會變得非常棘手。

因此，當一個系統逐漸變大、變得復雜，如果系統的各個組件之間沒有做到很好的隔離，只能讓各個組件之間的邊界變得更加模糊，也就增大了組件之間的耦合度，讓系統變的更加復雜，這跟負責這個系統的組織結構有很大關系。

做項目而非做產品

軟件系統的開發和演進有很多驅動因素，但多數場景導致系統更加復雜的是按照特定需求開發特定功能，也就是類似做項目的方式，每次都有明確的目標，而且這個目標的方案多數也是設計好的。

做項目的方式對系統最直接的影響就是需求的一致性，多個不同的項目作用在同一個系統上，為了解決不同的問題，單純的疊加功能，缺少對這個軟件系統的整體認知和規劃。而不像做產品，每一款產品都有一個愿景和核心要解決的問題，任何不符合愿景或者無法幫助解決核心問題的需求都是偽需求，不應該被添加到這個系統中。

因此，以做項目的方式推進的軟件系統，隨著項目不斷的推進，多個不相關或沒有經過深思熟慮的需求疊加到系統中，也會不斷加劇軟件系統的復雜度。

小結

就像開篇講的故事一樣，軟件系統就像一個不斷有人居住的房子一樣，隨著需求的不斷增加，會變得復雜和混亂，這個趨勢是無法避免的，這種混沌的狀態會直接影響到系統的使用者和維護者，不管作為用戶還是作為開發者，體驗都是非常差的。但當我們意識到了上面這些能夠讓系統變的復雜的因素，還是可以采取一些措施，盡量避免這些因素的發生，或者反過來利用這些因素采取一些逆向的措施，讓系統能夠更長久的保持健康狀態。