一、架構的定義

在軟件開發領域，自從架構這個詞被廣泛傳播之后，產生的架構模式也非常多，架構關注點也在增加。但回到“道”的層面，架構的定義或者說本質還是：

架構，又名軟件架構，是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。

——摘自《百度百科》

[[250268]]

二、架構是做什么？

很多做業務功能的增刪改查開發感受到無趣的小伙伴常把做架構想象成一片樂土，沒有嘈雜的業務聲音干擾，可以專心做一番牛X的技術。會把架構單純的理解成，牛X的性能、牛X的TPS、高可用，支撐了多少PV等等。但是其實這些只是架構很小的一部分，并不是全部。在互聯網時代之前都是C/S程序的天下，那個時候并沒有對性能等有像現在這樣的關注度，但是就已經有架構之說了。

世上本無架構，只是由于團隊越大越需要對整體的規則做約定，好讓大家往同一個方向發力，避免各自為戰，產生大量的內耗，所以才逐漸形成了架構。這條路就是“世上本無路，只是因為走的人多了變成了路”。

為什么說一個軟件架構是很重要的呢？當我們的團隊人數只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構凸顯的作用不是那么的明顯，但是如果團隊大了之后相信下面的這些現象會比較常見：

• 新上一個系統，往往不是獨立存在的，一般都需要與現存的系統進行交互，而需要集成交互的地方可能還很多，哪些集成是本系統需要實現的？同時，一般會劃分為多個階段開發，怎樣界定系統的邊界呢？
• 軟件系統是一個由多個模塊組成的整體。因此當上游開發與我們負責的模塊銜接老是出問題時，自己再做更多的努力也無法扭轉上游模塊的質量差帶來的負面效果。（我想大家這時候肯定是抓狂的。）
• 每次看到別人寫的代碼，老覺得自己來寫的話肯定不會這么寫。比他寫的更好。（我們做技術的，自我感覺良好是個常態：）。）
• 在某些場景下，自己腦子里有多套方案來實現，但是對孰優孰劣沒太大感覺，最終基本上就是拍腦袋選了一個。某塊代碼維護的次數多了，特別是中間由多個人接手過后，代碼風格各異，難以理解。
• 相似的代碼在好幾個地方出現，特別是一些非業務性的代碼，比如日志處理等。再甚是在大型的分布式系統中，不同子程序使用了不同的同類型中間件，同樣導致維護成本大增。
• 在2個相依賴項目邊界處的設計產生了分歧，并且站在各自的角度看都有道理。

任何事物都是有兩面性的，并不是說上面的這些問題，我們通過架構就要往另外一個極端去走。比如在大型的分布式系統中，不同子程序的確有必要在某些時刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ，但在特定的場景下能發揮的價值是無法相互替代的。

所以我們做架構有一點也是比較重要的，就是去Balance，選擇一個投入產出比***的方案。關于這點第四段中會多說幾句。

除此之外，架構的主要目的是為了讓大家往同一個方向，在同一個標準之上去發散擴張。一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發展空間。好比造一幢大樓，把框架結構設計好搭好，讓大家形成一個共識，什么是承重墻不能破壞，什么是創變空間可以自定義。在這樣的基礎下各自發展。這個看上去是個限制，但卻是做架構最重要的任務，所謂再多的文檔，再多的***實踐都比不上一條約束。降低復雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。

更甚之，我們做架構追求的理想國度是一個大家擁有一致共識的世界，架構是大家都像吃飯喝水這樣習以為常的習慣。去理解或者接手其它人負責的項目的時候就好像是自己寫的一樣。這個時候就消滅架構了，就好比現在沒有人會教你如何吃飯一樣。（就當YY一下吧：）。）

三、做架構的***實踐

上面提到更多的是做架構的目的，那么要做好架構，主要就是要做好抽象，做抽象的方式是類比，做類比的方式可以使用用例圖。所以建議大家多畫圖，通過畫圖來將大腦中抽象的結果直觀的體現在前面，再來進一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：

另外一種是魯棒圖，如圖：

整個過程的主要目的是：

• 描述其與外部實體（系統和最終用戶）的交互。
• 標識系統和外部實體間的信息和控制流。