架構思維：抽象、分層、分治、演化
互聯網的精髓就是共享，可以共享技術、共享經驗、共享情感、共享快樂~
很多年前就有這個想法了，從事IT行業時間也不短了，應該把自己工作和業余所學習的東西記錄並分享出來，和有緣人一起學習和交流。
如果您是那個有緣人，請上島一敘！爪哇島隨時歡迎您！
一、總述架構
- 架構的本質是管理復雜性，抽象、分層、分治和演化架構的本質是管理復雜性，抽象、分層、分治和演化 是應對和管理復雜性的四種最基本武器。
- 對思維習慣和思考能力的培養，其重要性遠遠大於對實際技術工具的掌握。
二、抽象思維
- 抽象(abstraction)這個詞大家經常聽到，但是真正理解和能講清楚什么是抽象的人少之又少。抽象其實是這樣定義的：對某種事物進行簡化表示或描述的過程，抽象讓我們關注要素，隱藏額外細節。
- 在系統架構和設計中，抽象幫助我們從大處着眼（get our mind about big picture），隱藏細節（temporarily hide details）。抽象能力的強弱，直接決定我們所能解決問題的復雜性和規模大小。
搭積木的時候，小朋友腦袋里頭先有一個城堡的大圖（抽象），然后他/她大腦里頭會有一個初步的子模塊分解（潛意識中完成），接着用利用積木搭建每一個子模塊，最終拼裝出最后的城堡。 - 架構師先要在大腦中形成抽象概念，然后是子模塊分解，然后是依次實現子模塊，最后將子模塊拼裝組合起來，形成最后系統。 優秀的架構師受職業習慣影響，眼睛里看到的世界都是模塊化拼裝組合式的。抽象能力不僅對軟件系統架構設計重要，對建築、商業、管理等人類其它領域活動同樣非常重要。其實可以這樣認為，我們生存的世界都是在抽象的基礎上構建起來的，離開抽象人類將寸步難行。
- 有經驗的程序員寫代碼會保持抽象層次的一致性，代碼讀起來像講故事，比較清晰易於理解；而沒有經驗的程序員會有明顯的抽象層次跳躍問題，代碼讀起來就比較累，這個是抽象能力不足造成。
上述流程中的抽象是在同一個層次上的，比較清晰易於理解，但是沒有經驗的程序員在實現這個流程的時候，代碼層次會跳，比方說主流程到支付卡校驗一塊，他的代碼會突然跳出一行某銀行API遠程調用，這個就是抽象跳躍，銀行API調用是細節，應該封裝在PaycardVerification這個抽象里頭。
三、分層思維
- 構建一套復雜系統，我們把整個系統划分成若干個層次，每一層專注解決某個領域的問題，並向上提供服務。
有些層次是縱向的，它貫穿所有其它層次，稱為共享層。
分層也可以認為是抽象的一種方式，將系統抽象分解成若干層次化的模塊。
今天的互聯網系統可以認為是現代文明的一個層次，其上是基於互聯網的現代商業，其下是現代電子工業基礎設施。
四、分治思維
- 分而治之(divide and combine或者split and merge)也是應對和管理復雜性的一般性方法，下圖展示一個分治的思維流程：
- 分治：分解和合並
分解： 對於一個無法一次解決的大問題，我們會先把大問題分解成若干個子問題，如果子問題還無法直接解決，則繼續分解成子子問題，直到可以直接解決的程度，這個是分解(divide)的過程；
合並： 將子子問題的解組合拼裝成子問題的解，再將子問題的解組合拼裝成原問題的解，這個是組合(combine)的過程。
【面試題】 給你一台8G內存/500G磁盤空間的普通電腦，如何對一個100G的大文件進行排序？假定文件中都是字符串記錄，一行約100個字符。
【思路】 100G的大文件肯定無法一次加載到內存直接排序，所以需要先切分成若干小問題來解決；
【拆解1】 8G內存的計算機一次大概能排多大的數據量，可以在有限的時間內排完呢？ 100G的大文件要怎么切法，切成多少份比較合適？【 考察候選人的時間空間復雜度估算能力】
【解題】 8G內存，排除操作系統消耗，Java排序程序JVM可用2~4G內存，基於經驗值，一次排1G左右的數據應該沒有問題； 所以100G的文件需要先切分成100份，每份1G，這樣每個子文件可以直接加載到內存進行排序。另外， 對於1G數據量的字符串排序，采用Java里頭提供的快速排序算法是比較合適的。
【分解2】現在硬盤上有100個已經排好序的文件，但是我們最終需要的是一個排好序的文件，下面該怎么做？ 這個時候我們需要把已經解決的子問題組合起來，合並成我們需要的最終結果文件。【 考察候選人對外排序和歸並排序算法的掌握程度】
【解題】 將100個排好序的文件進行兩兩歸並排序，這樣不斷重復，我們就會得到50個排好序的文件，每個大小是2G。然后再兩兩歸並，不斷重復，直到最后兩個文件歸並成目標文件，這個文件就是100G並且是排好序的。（ 因為是外排序+歸並排序，每次只需要讀取當前索引指向的文件記錄到內存，進行比較，小的那個輸出到目標文件，內存占用極少。 另外，上面的算法是兩路歸並，也可以采用多路歸並，甚至是采用堆排序進行優化）
【考點】 分治思想； 算法：快排，外排序，歸並排序，堆排序； 計算的時間空間復雜度估算，計算機的內外存特性和組織，文件操作；
3. 分治： 遞歸
A. 掌握遞歸技術的開發人員，相當於掌握了一種強大的編程武器，可以解決一些一般開發人員無法解決的問題。
B. 大自然中遞歸結構比比皆是， 大自然通過遞歸給我們人類何種啟示？
五、演化思維
- 架構是設計出來的？還是演化出來的？基於多年的架構經驗來說，架構既是設計出來的，同時也是演化出來的，對於互聯網系統，基本上可以說是三分設計，七分演化，而且是在設計中演化，在演化中設計，一個不斷迭代的過程。
- 在互聯網軟件系統的整個生命周期過程中，前期的設計和開發大致只占三分，在后面的七分時間里，架構師需要根據用戶的反饋對架構進行不斷的調整。
- 架構師除了要利用自身的架構設計能力，同時也要學會借助用戶反饋和進化的力量，推動架構的持續演進，這個就是演化式架構思維。
- 優秀的架構師深知，能夠不斷應對環境變化的系統，才是有生命力的系統，架構的好壞，很大部分取決於它應對變化的靈活性。所以具有演化式思維的架構師，能夠在一開始設計時就考慮到后續架構的演化特性，並且將靈活應對變化的能力作為架構設計的主要考量。
- 社區正在興起一種新的架構方法學~演化式架構，微服務架構就是一種典型的演化式架構，它能夠快速響應市場用戶需求的變化，而單體架構就缺乏這種靈活性。
- 馬丁·福樂曾經在其博客上給出過一張微服務架構的演化路線圖，可以用來解釋設計式思維和演化式思維的差異，如下圖所示：
【設計式思維】----上行路線
【問題】上面的路線是一開始就直奔微服務架構，其實背后體現的是設計式架構的思維 ，認為架構師可以完全設計整個系統和它的演化方向。
【風險分析】馬丁認為這種做法風險非常高，一個是成本高昂，另外一個是剛開始架構師對業務域理解不深，無法清晰划分領域邊界，開發出來的系統很可能無法滿足用戶需求。
【演化式思維】----下行路線
上面的路線是從單體架構開始，隨着架構師對業務域理解的不斷深入，也隨着業務和團隊規模的不斷擴大，漸進式地把單塊架構拆分成微服務架構的思路，這就是演化式架構的思維。
目前大多數大型互聯網公司得系統架構走得都是演化式架構的路線。類似下面的建築的演化史，在每個階段，你可以看到設計的影子：
六、如何培養架構思維【總結】
- 工作中大量高質量項目的實戰鍛煉
- 平時的學習、思考和提煉總結
- 基本的架構設計思維， 可以從數據結構和算法中可以找到影子
- 對於演化設計思維， 更多在實際工作中通過實戰鍛煉和培養
- 一個架構師的成長高度和他大學期間的思維習慣的養成關系密切
- 世界一流的互聯網公司，例如谷歌等，招聘工程師新人時，對數據結構和算法的要求可以用苛刻來形容
- 掌握了抽象、分層、分治和演化這四種基本的武器，你可以設計小到一個類，一個模塊，一個子系統，或者一個中型的系統，也可以大到一個公司的基礎平台架構，微服務架構，技術體系架構，甚至是組織架構，業務架構等等；
- 架構設計不是靜態的，而是動態演化的。只有能夠不斷應對環境變化的系統，才是有生命力的系統。 在設計的同時，借助反饋和進化的力量推動架構的持續演進。
- 架構師在關注技術，開發應用的同時，需要定期梳理自己的架構設計思維，積累時間長了，你看待世界事物的方式會發生根本性變化，你會發現我們生活其中的世界，其實也是在抽象、分層、分治和演化的基礎上構建起來的。
- 對抽象、分層、分治和演化掌握的深度和靈活應用的水平，直接決定架構師所能解決問題域的復雜性和規模大小，是區分普通應用型架構師和平台型/系統型架構師的一個分水嶺。