架構師必讀，實用架構的搭建思路

因為碎片化的時間多了，休閑的時候，我關註了一些架構相關的內容。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以，我把看到的問題、回答過的問題中的部分內容整理一下，權當記錄，留給3年後的自己~

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

“架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。”——摘自《百度百科》

很多做業務功能的增刪改查開發感受到無趣的小夥伴常把做架構想象成一片樂土，沒有嘈雜的業務聲音幹擾，可以專心做一番牛X的技術。會把架構單純的理解成，牛X的效能、牛X的TPS、高可用、支撐了多少PV等等。但是其實這些只是架構很小的一部分，並不是全部。

在網際網路時代之前都是C/S程式的天下，那個時候並沒有對效能等有像現在這樣的關註度，但是就已經有架構之說了。

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

為什麼說一個軟體架構是很重要的呢？

當我們的團隊人數只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構凸顯的作用並不是那麼的明顯。但是如果團隊大了，相信下麵的這些現象會比較常見：

• 新上一個系統，往往不是獨立存在的，一般都需要與現存的系統進行互動，而需要整合互動的地方可能還很多，那麼哪些整合是本系統需要實現的？同時，一般會劃分為多個階段開發，怎樣界定系統的邊界呢？

• 軟體系統是一個由多個模組組成的整體。因此當上游開發與我們負責的模組銜接老是出問題時，自己做再多的努力也無法扭轉上游模組質量差帶來的負面效果。（我想大家這時候肯定是抓狂的。）

• 每次看到別人寫的程式碼，老覺得自己來寫的話肯定不會這麼寫，肯定比他寫的更好。（我們做技術的，自我感覺良好是個常態）

• 在某些場景下，自己腦子裡有多套方案來實現，但是對孰優孰劣沒太大感覺，最終基本上就是拍腦袋選了一個。

• 某塊程式碼維護的次數多了，特別是中間由多個人接手過後，程式碼風格各異，難以理解。

• 相似的程式碼在好幾個地方出現，特別是一些非業務性的程式碼，比如日誌處理等。再甚是在大型的分散式系統中，不同子程式使用了不同的同型別中介軟體，同樣導致維護成本大增。

• 在2個相依賴專案邊界處的設計產生了分歧，並且站在各自的角度看都有道理。

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

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

除此之外，架構的主要目的是為了讓大家往同一個方向，在同一個標準之上去發散擴張。一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發展空間。

好比造一幢大樓，把框架結構設計好搭好，讓大家形成一個共識，什麼是承重牆不能破壞，什麼是創變空間可以自定義。在這樣的基礎下各自發展。

這個看上去是個限制，但卻是做架構最重要的任務，所謂再多的檔案，再多的最佳實踐都比不上一條約束。降低複雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。

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

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

主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：

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

整個過程的主要目的是：

• 描述其與外部物體（系統和終端使用者）的互動；

• 標識系統和外部物體間的資訊和控制流。

理想的世界裡，我們程式的邊界設計恰好匹配於業務邊界。然而我們作為工程師首先要承擔業務需求的壓力，只能擠時間去做這些非業務性工作。也因此老專案的業務邊界也並不總是如新專案那樣明晰。

這意味著做任何架構的改動要考慮優先順序，特別在拆分業務領域之前，要認真地思考業務的邊界，排定優先順序，考量拆分的收益與風險。劃分業務的邊界，則需要更多的思考拆分後的未來將如何溝通協作，然後再考慮技術因素。

在技術因素前，主要考量這幾點：

• 是否擁有獨立的團隊來維護，以及是否擁有發展為一項獨立業務的潛力。（非必要的情況下，一定要避免共享內核的開發方式）

• 圍繞領域而非 feature，有明確的維護團隊，避免過於細粒度。

• 拆分或者組合之後，能否改善現有的協作流程。

• 能否幫助區分核心、非核心業務，改善穩定性。

上面這些完成了之後，便是選擇合適的中介軟體、技術框架來滿足技術層面的要求，這個的選拔主要以下麵幾點來考量：

• 如果是直接引入第三方的中介軟體的話，成熟度如何？是否有大公司在用？（有大公司的口碑背書的肯定大大加分）

• 近期的社群活躍度如何？（用於考量是否有更多的人在一起踩坑，降低各自遇到坑的數量和機率）

• 硬指標，當前場景的硬性要求是否滿足。如效能、對關鍵部分或者未來的可擴充套件性等。

• 軟指標，複雜度、可維護性等。這裡可以羅列幾個競品的優劣勢。

• 最重要的是要自己去親自驗證上面的幾點，並且做一定的模擬工作。

• 如果曾經用過或者有其中一部分的經驗可復用，這是加分項，畢竟在使用的過程中才發現hold不住它，那是災難性的！

之前有聽到過一句話，概括的很精闢。好的架構必須需要貼合業務。那麼把業務+技術演變成一個數學公式來表達可以理解為：2個數字的和等於10，求如何組合能得到最大的乘積。那不是3*7，也不是4*6，而是5*5。

所以架構不是生搬硬套，不是為了架構（搞事情）而架構，趕時髦，或者說裝X。

我們應避免透過個人的主觀意願來主導。比如自己覺得某個中介軟體好，就“拿著鎚子到處找釘子”，這一敲下來，看著不錯，但是帶來的成本和風險被忽略了。可能有更好的解決方案，或者完全沒必要在當下敲這一釘子下去。　　

好的架構需要評判投入產出比，收益更高的就是更好的架構，就如下圖的公式：

產出可以理解為我們因此獲得的好處（諸如可靠性、安全性、可擴充套件性、可維護性、可伸縮性、效能等），成本是我們改造花費的投入，如人力物力和時間。特別註意的是風險這點，是很重要也是很容易被大家忽略的一點，是起到指數級作用的。

選擇的方案再好，如果都是一些hold不住的技術，那麼風險就是無窮大，導致減號右側無限趨近於0，最終的結果就是收益是負數，投入的成本打水漂，甚至還要加上其它額外的付出。

上面提到的這些關註點都是架構師的職責，另外特別重要的一點是，架構師必須要是個有追求的“好碼農”（劃重點）。

軟體架構師不像建築師，其面對的本身是一個抽象的事物，如果再脫離了實操，這基本和紙上談兵無異。所以實際工作中的難點、要點都得清楚，並且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本。

成為了一個真正的“好碼農”就向架構師邁出第一步了。而後呢，需要不斷以深→廣→深→廣的節奏去開疆擴土，擴大自己的知識領域，當然需要以貼近當前工作內容的知識為主，這是第二步。到了這還沒完，還有打造三板斧：業務能力、溝通能力、個人魅力。

題外話，在國內，純技術的架構師沒有應用型的架構師吃的開。所以此文皆以應用型架構師的職能要求為參考。

回到文章開頭，架構的表現形式有很多，從本質上單體應用的架構設計思想和分散式系統是一致的，所謂服務化其實也是模組化的思想，只是維度的不同，導致用到的一些工具或者環境不同，但這都是“術”層面的東西。光學這些招數，永遠也學不完。架構之路漫長，繼續前行，共勉。