因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。
發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己~
按慣例，容許我裝x開頭~
一、架構的定義
在軟體開發領域，自從架構這個詞被廣泛傳播之後，產生的架構模式也非常多，架構關注點也在增加。但回到「道」的層面，架構的定義或者說本質還是：
架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計。
二、架構是做什麼？
很多做業務功能的增刪改查開發感受到無趣的小夥伴常把做架構想象成一片樂土，沒有嘈雜的業務聲音干擾，可以專心做一番牛x的技術。
會把架構單純的理解成，牛x的效能、牛x的tps、高可用，支撐了多少pv等等。但是其實這些只是架構很小的一部分，並不是全部。
在網際網路時代之前都是c/s程式的天下，那個時候並沒有對效能等有像現在這樣的關注度，但是就已經有架構之說了。
世上本無架構，只是由於團隊越大越需要對整體的規則做約定，好讓大家往同乙個方向發力，避免各自為戰，產生大量的內耗，所以才逐漸形成了架構。
這條路就是「世上本無路，只是因為走的人多了變成了路」。
為什麼說乙個軟體架構是很重要的呢？
當我們的團隊人數只有2、3個人，甚至只有1個人單槍匹馬的情況下，可能架構凸顯的作用不是那麼的明顯，但是如果團隊大了之後相信下面的這些現象會比較常見：
任何事物都是有兩面性的，並不是說上面的這些問題，我們通過架構就要往另外乙個極端去走。
比如在大型的分布式系統中，不同子程式的確有必要在某些時刻選擇同型別的其它中介軟體。如kafka和rabbitmq雖都是mq，但在特定的場景下能發揮的價值是無法相互替代的。
所以我們做架構有一點也是比較重要的，就是去balance，選擇乙個投入產出比最優的方案。關於這點第四段中會多說幾句。
除此之外，架構的主要目的是為了讓大家往同乙個方向，在同乙個標準之上去發散擴張。
一是把控硬性的下限標準，提高整體的最短版，二是提高上限水平位，也就是天花板位置，提供更大的發展空間。
好比造一幢大樓，把框架結構設計好搭好，讓大家形成乙個共識，什麼是承重牆不能破壞，什麼是創變空間可以自定義。在這樣的基礎下各自發展。
這個看上去是個限制，但卻是做架構最重要的任務，所謂再多的文件，再多的最佳實踐都比不上一條約束。
降低複雜度、降低理解難度，是實實在在的收益。最怕的就是憑空假設帶來的過度浪費。
更甚之，我們做架構追求的理想國度是乙個大家擁有一致共識的世界，架構是大家都像吃飯喝水這樣習以為常的習慣。
去理解或者接手其它人負責的專案的時候就好像是自己寫的一樣。這個時候就消滅架構了，就好比現在沒有人會教你如何吃飯一樣。(就當yy一下吧：)。)
三、做架構的最佳實踐
上面提到更多的是做架構的目的，那麼要做好架構，主要就是要做好抽象，做抽象的方式是模擬，做模擬的方式可以使用用例圖。
如下圖：
另外一種是魯棒圖，如圖：
整個過程的主要目的是：
理想的世界裡，我們程式的邊界設計恰好匹配於業務邊界。然而我們作為工程師首先要承擔業務需求的壓力，只能擠時間去做這些非業務性工作。也因此老專案的業務邊界也並不總是如新專案那樣明晰。
這意味著做任何架構的改動要考慮優先順序，特別在拆分業務領域之前認真地思考業務的邊界。
排定優先順序，考量拆分的收益與風險。劃分業務的邊界，則需要更多的思考拆分後的未來將如何溝通協作，然後再考慮技術因素。
在技術因素前，主要考量這幾點：
上面這些完成了之後，便是選擇合適的中介軟體、技術框架來滿足技術層面的要求，這個的選拔主要以下面幾點來考量：
四、什麼是好架構
之前有聽到過一句話，概括的很精闢。
好的架構必須需要貼合業務，那麼把業務+技術演變成乙個數學公式來表達可以理解為：2個數字的和等於10，求如何組合能得到最大的乘積。那不是3*7，也不是4*6，而是5*5。
所以架構不是生搬硬套，為了架構(搞事情)而架構，趕時髦，或者說裝x。我們應避免通過個人的主觀意願來主導。
比如自己覺得某個中介軟體好，就」拿著錘子到處找釘子「，這一敲下來，看著不錯，但是帶來的成本和風險被忽略了。可能有更好的解決方案，或者完全沒必要在當下敲這一釘子下去。
好的架構需要評判投入產出比，收益更高的就是更好的架構，就如下圖的公式。
產出可以理解為我們因此獲得的好處(諸如可靠性、安全性、可擴充套件性、可維護性、可伸縮性、效能等)，成本是我們改造花費的投入，如人力物力和時間。
特別注意的是風險這點，是很重要也是很容易被大家忽略的一點，是起到指數級作用的。
選擇的方案再好，如果都是一些hold不住的技術，那麼風險就是無窮大，導致減號右側無限趨近於0，最終的結果就是收益是負數，投入的成本打水漂，甚至還要加上其它額外的付出。
五、如何成為架構師
上面提到的這些關注點都是架構師的職責，另外特別重要的一點是，架構師必須要是個有追求的「好碼農」！！！(劃重點)。
軟體架構師不像建築師，其面對的本身是乙個抽象的事物，如果再脫離了實操，這基本和紙上談兵無異。
所以實際工作中的難點、要點都得清楚，並且能夠給出解決方案或者方向。另外只有熟悉實操才能更準確的評估成本。
成為了乙個真正的「好碼農」就向架構師邁出第一步了。
而後呢，需要不斷以深 --> 廣 --> 深 --> 廣的節奏去開疆擴土，擴大自己的知識領域，當然需要以貼近當前工作內容的知識為主，這是第二步。到了這還沒完，還有打造三板斧：業務能力、溝通能力、個人魅力。
題外話，在國內，純技術的架構師沒有應用型的架構師吃的開。所以此文皆以應用型架構師的職能要求為參考。
六、結語
回到文章開頭，架構的表現形式有很多，從本質上單體應用的架構設計思想和分布式系統是一致的。
所謂服務化其實也是模組化的思想，只是維度的不同，導致用到的一些工具或者環境不同，但這都是「術」層面的東西。光學這些招數，永遠也學不完。
架構之路漫長，繼續前行，共勉。
mysql架構設計 初識mysql架構設計
一 應用系統如何與mysql進行一次互動？最開始接觸jdbc的時候，我們系統如何完成一次sql操作呢？第一步，建立資料庫連線 第二步，操作sql 第三步，釋放連線。但是每次建立與資料庫的連線非常耗時和資源，所以我們加入了連線池的概念。第一步的獲取連線是從連線池中獲取乙個可用的連線，第三步的釋放連線不...
《從0開始學架構》 什麼是架構設計
本系列是極客時間 從0開始學架構 的讀書筆記。對應 01 架構到底是指什麼？架構是頂層設計 框架是面向程式設計或配置的半成品 元件是從技術維度上的復用 模組是從業務維度上職責的劃分 系統是相互協同可執行的實體。按照我的理解，架構的維度是最大的，一般我們會講業務架構和技術架構兩類。而框架重在提供一種約...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...