在從程式設計小白到架構師的修煉過程中，所需要學習的知識是非常龐雜的。
我最開始學習架構設計的時候，一直搞不清楚系統如何實現從無序到有序，網上也找不到系統的資料。
所謂架構設計，就是用於指導大型軟體系統各個方面的設計。而架構師要做的，就是用最小的人力成本滿足需求開發和需求變更，用最小的執行成本來保障軟體的執行。
常用的方法有：
1.使用微服務架構，把複雜系統拆分成一系列小的服務，再拆成功能模組，讓人員更好地分工協作
2.前後端分離，讓程式設計師專注某個知識領域，降低開發難度
3.分層設計，隔離業務邏輯，減少需求變更帶來的影響
原因無他，就是複雜。
1.需求讓技術變複雜。小**與大**的技術複雜度不是乙個等級，想想你自己搭建的個人站和谷歌**的差別；
2.人員讓技術複雜。成員水平不等、擅長技術也不一樣，有效協作是考驗；
3.技術本身複雜。使用的語言、框架、元件、資料庫、大資料等技術，都有學習成本
4.軟體穩定執行也複雜。軟體上線並不是軟體專案的終點，那才是真正考驗的開始，因為充滿了各種不確定性。比如某明星發個微博可能造成系統癱瘓，又比如有人刪庫跑路了（參考年初某盟的刪庫事件）。
正因為存在以上原因，我們才需要架構設計去降低這些複雜性，進而降低開發成本、提公升協作效率、保障服務穩定執行。
一般分為四步：
1.分析需求。對產品的需求進行抽象，分析用例，了解各種使用者角色和其使用的場景。這是後續工作得以實施的大前提。
2.選擇相似的成熟架構設計方案。例如我們前面提到的，微服務架構、前後端分離、分層設計等。
3.自頂向下層層細化。好的實踐是自頂向下的，不過早陷入技術細節中，從整體到區域性規劃，設計好部署架構、分層和分模組、api設計、資料庫設計等。
4.驗證和優化架構設計方案。這個是貫穿整個設計始終的，乙個完整的架構設計方案，是需要有多次的評審，收集多方反饋，反覆修改後確定的。
1.單體架構
適用場景：適合小專案，使用者數，業務處理還比較簡單，一兩台伺服器能支撐起正常的業務處理。
優點：開發簡單直接，集中式管理；基本不會重複開發；功能都在本地，沒有分布式的管理開銷和呼叫開銷
不足：開發效率低、**維護難、部署不靈活、穩定性不高、擴充套件性不夠
2.水平分層架構
單體架構進行水平拆分，就形成了水平分層架構。水平分層是基於功能性的。
適用場景：需要快速構建的新應用程式，需要嚴格的可維護性和可測試性標準的應用
優點：降低系統的複雜度，同時滿足單一職責、高內聚、低耦合、提高可復用性和降低維護成本
缺點：分層過多會導致請求路徑變長、平均響應延遲變高、定位問題變的複雜化、運維成本增加
3.面向服務架構（soa）
soa架構，即面向服務架構，是單體架構垂直拆分的結果
適用場景：適合於龐大、 複雜、異構的企業級系統
優點：更易維護、更高的可用性（低耦合）、更好的伸縮性
不足：每個服務還是單體架構，對esb嚴重依賴
4.微服務架構
微服務架構即按照水平方向去拆分，又按照垂直方向去拆分。
適用場景：適合於快速、輕量級、基於web的網際網路系統，這類系統業務變化快，需要快速嘗試、快速交付。
優點：服務顆粒度更細，有利於資源的重複利用，提高開發效率；更加精確制定單個服務的優化方案；加快部署速度
不足：服務劃分過細，會導致服務間關係複雜、呼叫鏈太長效能下降，問題定位困難；團隊效率下降；沒有自動化支撐，無法快速交付。
談了這麼多理論，來個實戰的（如何拆分分布式架構）。
1.設計module骨架
module骨架的設計是基礎，影響最終拆分結果，拆分成功的嚮導。按照技術，業務，部署打包，測試這幾個維度來規劃設計，下面是乙個參考：
2.拆分技術commons
分離出技術上的commons，把相關的類重構到乙個包裡，再分離出乙個module。
3.拆分entity
很多在業務**上都會共享entity類，通常沒法也沒法把entity類分門別類，最簡單就是把所有的entity類放到乙個module，誰需要誰依賴的原則。
4.公共業務
同commons和entity方法，不再贅述。
5.拆分業務**
新建業務module，加入基礎module的pom依賴，再從源module複製和該業務module相關的**（包括單元測試**）過來，解決編譯錯誤和單元測試錯誤，完成本業務拆分。
從源module複製乙個新業務module，保持**一致，先刪除和本義務無關的**（包括單元測試**），再刪除無關的pom依賴，解決編譯錯誤和單元測試錯誤，完成本業務拆分。
選擇哪種方法，可以根據**整潔度和互相依賴程度，如果**很整潔且相互依賴較弱，可以採取前者，否則就採取後者。
6.拆分微服務
有了以上的拆分基礎，可以在合適的業務迭代將各個微服務module遷移到不同的**倉庫，完成進一步隔離管理。
以上只是架構設計必備知識的冰山一角，還有更多系統的知識點，比如mybatis架構、android架構、rpc框架設計等，都可以在我收藏整理的這個思維導圖資源包裡找到。
架構師之路 架構師思維的培養
公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆，到現在已經幾年沒有架構師了。本來入職時，崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師，因為架構首先是為業務服務的，而工控行業有許多特別的地方，不是普通的軟體技術堆疊就能做出優秀的工控軟體的...
架構師之路 架構師思維的培養
公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆，到現在已經幾年沒有架構師了。本來入職時，崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師，因為架構首先是為業務服務的，而工控行業有許多特別的地方，不是普通的軟體技術堆疊就能做出優秀的工控軟體的...
軟體架構師的「不歸之路「 架構師的職責
軟體架構師的 不歸之路 架構師的職責 架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個專案，使設計的專案盡量效率高，開發容易，維護方便，公升級簡單。架構師的主要責任是提供開發人員和專案經理之間的共用溝通 他們負責讓業務規則及需求與工程實踐及限制相適應，以確保成功。架構師的職責就...