从架构设计到架构师
一、架構的定義
在軟件開發領域，自從架構這個詞被廣泛傳播之后，產生的架構模式也非常多，架構關注點也在增加。但回到“道”的層面，架構的定義或者說本質還是：
架構，又名軟件架構，是有關軟件整體結構與組件的抽象描述，用于指導大型軟件系統各個方面的設計。————摘自《百度百科》
二、架構是做什么？
很多做業務功能的增刪改查開發感受到無趣的小伙伴常把做架構想象成一片樂土，沒有嘈雜的業務聲音干擾，可以專心做一番牛X的技術。會把架構單純的理解成，牛X的性能、牛X的TPS、高可用，支撐了多少PV等等。但是其實這些只是架構很小的一部分，并不是全部。在互聯網時代之前都是C/S程序的天下，那個時候并沒有對性能等有像現在這樣的關注度，但是就已經有架構之說了。 世上本無架構，只是由于團隊越大越需要對整體的規則做約定，好讓大家往同一個方向發力，避免各自為戰，產生大量的內耗，所以才逐漸形成了架構。這條路就是“世上本無路，只是因為走的人多了變成了路”。
為什么說一個軟件架構是很重要的呢？當我們的團隊人數只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構凸顯的作用不是那么的明顯，但是如果團隊大了之后相信下面的這些現象會比較常見：
新上一個系統，往往不是獨立存在的，一般都需要與現存的系統進行交互，而需要集成交互的地方可能還很多，哪些集成是本系統需要實現的？同時，一般會劃分為多個階段開發，怎樣界定系統的邊界呢？
軟件系統是一個由多個模塊組成的整體。因此當上游開發與我們負責的模塊銜接老是出問題時，自己再做更多的努力也無法扭轉上游模塊的質量差帶來的負面效果。（我想大家這時候肯定是抓狂的。）
每次看到別人寫的代碼，老覺得自己來寫的話肯定不會這么寫。比他寫的更好。（我們做技術的，自我感覺良好是個常態。）
在某些場景下，自己腦子里有多套方案來實現，但是對孰優孰劣沒太大感覺，最終基本上就是拍腦袋選了一個。
某塊代碼維護的次數多了，特別是中間由多個人接手過后，代碼風格各異，難以理解。
相似的代碼在好幾個地方出現，特別是一些非業務性的代碼，比如日志處理等。再甚是在大型的分布式系統中，不同子程序使用了不同的同類型中間件，同樣導致維護成本大增。
在2個相依賴項目邊界處的設計產生了分歧，并且站在各自的角度看都有道理。
任何事物都是有兩面性的，并不是說上面的這些問題，我們通過架構就要往另外一個極端去走。比如在大型的分布式系統中，不同子程序的確有必要在某些時刻選擇同類型的其它中間件。如Kafka和RabbitMQ雖都是MQ，但在特定的場景下能發揮的價值是無法相互替代的。
所以我們做架構有一點也是比較重要的，就是去Balance，選擇一個投入產出比最優的方案。關于這點第四段中會多說幾句。
除此之外，架構的主要目的是為了讓大家往同一個方向，在同一個標準之上去發散擴張。一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發展空間。好比造一幢大樓，把框架結構設計好搭好，讓大家形成一個共識，什么是承重墻不能破壞，什么是創變空間可以自定義。在這樣的基礎下各自發展。這個看上去是個限制，但卻是做架構最重要的任務，所謂再多的文檔，再多的最佳實踐都比不上一條約束。降低復雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。
更甚之，我們做架構追求的理想國度是一個大家擁有一致共識的世界，架構是大家都像吃飯喝水這樣習以為常的習慣。去理解或者接手其它人負責的項目的時候就好像是自己寫的一樣。這個時候就消滅架構了，就好比現在沒有人會教你如何吃飯一樣。
三、做架構的最佳實踐
上面提到更多的是做架構的目的，那么要做好架構，主要就是要做好抽象，做抽象的方式是類比，做類比的方式可以使用用例圖。所以建議大家多畫圖，通過畫圖來將大腦中抽象的結果直觀的體現在前面，再來進一步分析合理性。主要推薦2種圖的類別，一種就是前面提到的用例圖。如下圖：
另外一種是魯棒圖，如圖：
整個過程的主要目的是：
描述其與外部實體（系統和最終用戶）的交互。
標識系統和外部實體間的信息和控制流。
理想的世界里，我們程序的邊界設計恰好匹配于業務邊界。然而我們作為工程師首先要承擔業務需求的壓力，只能擠時間去做這些非業務性工作。也因此老項目的業務邊界也并不總是如新項目那樣明晰。
這意味著做任何架構的改動要考慮優先級，特別在拆分業務領域之前認真地思考業務的邊界。排定優先級，考量拆分的收益與風險。劃分業務的邊界，則需要更多的思考拆分后的未來將如何溝通協作，然后再考慮技術因素。在技術因素前，主要考量這幾點：
是否擁有獨立的團隊來維護，以及是否擁有發展為一項獨立業務的潛力。（非必要的情況下，一定要避免共享內核的開發方式）
圍繞領域而非 feature，有明確的維護團隊，避免過于細粒度。
拆分或者組合之后，能否改善現有的協作流程。
能否幫助區分核心、非核心業務，改善穩定性。
上面這些完成了之后，便是選擇合適的中間件、技術框架來滿足技術層面的要求，這個的選拔主要以下面幾點來考量：
如果是直接引入第三方的中間件的話，成熟度如何？是否有大公司在用？（有大公司的口碑背書的肯定大大加分）
近期的社區活躍度如何？（用于考量是否有更多的人在一起踩坑，降低各自遇到坑的數量和概率）
硬指標，當前場景的硬性要求是否滿足。如性能、對關鍵部分或者未來的可擴展性等。
軟指標，復雜度、可維護性等。這里可以羅列幾個競品的優劣勢。
最重要的是要自己去親自驗證上面的幾點，并且做一定的模擬工作。
如果曾經用過或者有其中一部分的經驗可復用，這是加分項，畢竟在使用的過程中才發現hold不住它，那是災難性的！
四、什么是好架構
之前有聽到過一句話，概括的很精辟。好的架構必須需要貼合業務，那么把業務+技術演變成一個數學公式來表達可以理解為：2個數字的和等于10，求如何組合能得到最大的乘積。那不是3*7，也不是4*6，而是5*5。
所以架構不是生搬硬套，為了架構（搞事情）而架構，趕時髦，或者說裝X。我們應避免通過個人的主觀意愿來主導。比如自己覺得某個中間件好，就”拿著錘子到處找釘子“，這一敲下來，看著不錯，但是帶來的成本和風險被忽略了。可能有更好的解決方案，或者完全沒必要在當下敲這一釘子下去。
好的架構需要評判投入產出比，收益更高的就是更好的架構，就如下圖的公式。產出可以理解為我們因此獲得的好處（諸如可靠性、安全性、可擴展性、可維護性、可伸縮性、性能等），成本是我們改造花費的投入，如人力物力和時間。特別注意的是風險這點，是很重要也是很容易被大家忽略的一點，是起到指數級作用的。選擇的方案再好，如果都是一些hold不住的技術，那么風險就是無窮大，導致減號右側無限趨近于0，最終的結果就是收益是負數，投入的成本打水漂，甚至還要加上其它額外的付出。
五、如何成為架構師
上面提到的這些關注點都是架構師的職責，另外特別重要的一點是，架構師必須要是個有追求的“好碼農”！！！（劃重點）。軟件架構師不像建筑師，其面對的本身是一個抽象的事物，如果再脫離了實操，這基本和紙上談兵無異。所以實際工作中的難點、要點都得清楚，并且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本
成為了一個真正的“好碼農”就向架構師邁出第一步了。而后呢，需要不斷以深 --> 廣 --> 深 --> 廣的節奏去開疆擴土，擴大自己的知識領域，當然需要以貼近當前工作內容的知識為主，這是第二步。到了這還沒完，還有有一個學習路線。
一名從事了10年后端的老程序員，辭職目前在做講師，整理了一份現在把架構師必須具備的一些技術總結出來一套學習思維導圖和錄制了一些相關視頻，分享給大家，供大家參考。
需要相關資料可以關注+轉發+私信我（架構）就能獲取
一：開源框架源碼分析
學習Java技術體系，設計模式，流行的框架與組件
常見的設計模式，編碼必備
Spring5
MyBatis
AOP源碼解析
IOC源碼解析
SpringMVC
二：架構筑基
任何脫離細節的ppt架構師都是耍流氓，向上能運籌帷幄，向下能解決一線性能問題，Java技術體系，需要了解：
性能優化
JVM調優
Web調優
常見工具調優
linux基礎與進階
三：高性能架構
高并發，高可用，海量數據，沒有分布式的架構知識肯定是玩不轉的：
分布式框架思維
分布式協調和分流
高可靠數據存儲
緩存與NoSQL
異步與消息中間件
分布式解決方案實戰
四：微服務架構
業務越來越復雜，服務分層，微服務架構是架構升級的必由之路，Java技術體系，和微服務相關的技術有哪些呢？
Spring Boot
Spring Cloud
Docker虛擬化技術
Dubbo應用及源碼解讀
五：團隊協作
工欲善其事必先利其器，不管是小白，還是資深開發，玩Java技術體系，選擇好的工具，提升開發效率和團隊協作效率，是必不可少的：
Maven，項目管理
Jenkins，持續集成
Sonar，代碼質量管理
Git，版本管理
六：B2C項目實戰
系統設計
用戶管理子系統
商品管理子系統
搜索子系統
訂單子系統
支付系統
分布式調度系統
后臺系統
歡迎工作一到五年的Java程序員朋友們加入Java架構交流：810589193
本群提供免費的學習指導 架構資料 以及免費的解答
不懂得問題都可以在本群提出來 之后還會有職業生涯規劃以及面試指導
轉載于:https://blog.51cto.com/14214335/2364170
總結
- 上一篇： 团体意外险和雇主责任险的区别，有以下5点
- 下一篇： AMD 最新芯片组驱动优化 7950X3