『高階篇』docker容器來說軟體架構的進化（二）
也工作了10年了，對於軟體的架構也是不斷學習總結，怎麼樣的發展到微服務的架構。
什麼是軟體架構
在軟體的內部，經過綜合各種因素的考量，權衡選擇特定的技術，將系統劃分不同的部分並使這些相互分工，彼此寫作，為使用者提供需要的價值。
- 哪些因素
- 業務需求
- 技術棧
- 成本
- 組織架構
- 可擴充套件性
- 可維護性
- 以我的個人經歷
-
一層架構
2007年在河南本地的一個公司實習，負責的是一個老系統，它用到了jsp和servlet，jdbc的技術，java早期的標準技術，在jsp裡面看到了html，還看到了一大片一大片的java程式碼，直接寫在jsp裡面。在servlet裡面有上千行的程式碼，300，500行都很平常的事情，包含了業務邏輯，返回給jsp的業務內容，業務操作，資料庫操作。維護起來讓你很崩潰，不過才畢業也就忍了，堅持了半年。後來要去濟南。這種在極其簡單的業務裡面還是可行的，但是現在也看不到了。
-
MVC
2008年去了濟南，濟南畢竟要全國知名的公司就進入了。雖然是996，但是感覺還好，至少程式碼不那麼複雜了，雖然是jsp，java程式碼基本沒有，分了很多資料夾，層次清晰分工明確，也學到MVC的三層架構。解決了程式碼呼叫雜亂無章，讓程式碼清晰，通過各層之間定義介面的方式，讓介面和實現分離，可以將原來的實現替換成方案，讓別人理解，降低了溝通成本，維護成本，分工的明確各司其職，很長時間都是軟體的架構經典模式。像SSH 和SSM其實MVC的實現。
-
dubbo
2013年換了一家公司，dubbo那時候才出來1年，公司嘗試用dubbo改造一個核心繫統，為什麼要用dubbo，因為裡面java程式碼加頁面程式碼100多萬行，需求每個月還不斷的新增，牛逼了我的哥！3年以上的人至少2-3個月熟悉都不一定能上手，只能想辦法拆分，拆分的過程也是對老程式碼進行梳理和重構，dubbo的出現可以讓前後端物理上隔離開來，完全變成2個可以單獨維護的模組，從感官上覆雜度就下降了一半，這種開發歷程，在河南這邊可能不太明顯，在北上廣應該都有類似的經歷。多年的開發的人員。
其實上邊的說的都是單體架構，很多目前的公司也都是單體架構，雖然dubbo，分離成了前後2個個體，但他並不是微服務。
什麼是單體架構
功能，業務集中在一個釋出包裡，部署執行在同一個程序中。
- 優勢
- 易於開發（方便開發人員開發）
- 易於測試（準備一臺伺服器，部署下就可以測試了）
- 易於部署（所有程式碼都打在一個包裡面，直接拷貝一個war部署在伺服器上，目錄中）
- 易於水平伸縮（節點的複製，新建伺服器，配置好執行環境，直接拷貝一個war部署在伺服器上）
-
單體面臨的挑戰
>隨著很多傳統行業往網際網路考慮，業務變化瞬息萬變，系統的升級也越來越頻繁，使用者的數量快速增長，單體架構已經無法滿足網際網路的發展了，它有很多致命的硬傷。
- 程式碼膨脹，難以維護（出現bug，分析定位成本都很高，隨著程式碼開發，開發人員對全域性的理解越來越缺失，修復一個bug，可能引入其他bug，惡性迴圈，導致難以維護）
-
構建，部署成本大（程式碼越來越多，構建部署啟動的時間越來越長，專案維護的人越來越多，大家都在構建，都在部署，難免互相影響，難免造成一個bug的修復，提交給測試驗證的時間拉的很長，效率越來越底下）
3.新人上手困難（現在的網際網路公司，都是鐵打的營盤流水的兵，過於複雜新人還沒完全理解上手的時候，就已經離職了） - 創新困難（成功引入新框架困難，就算成功引入學習成本極高）
- 可擴充套件性差（程式碼都執行在同一個程序裡面，一個程序只能執行在一天機器上，給這個機器加多少記憶體，加多少cpu才能夠我們這個專案用呢，有的框架對CPU要求高，有的框架對記憶體要求高，有的框架對硬碟要求高，其實最終選擇了一個各方面都好的機器，是不是增加了成本的開支）
PS：綜上所述，單體架構已經out了，老鐵，可以考慮其他了，如何考慮下回繼續說。
>>原創文章，歡迎轉載。轉載請註明：轉載自，謝謝！>>原文連結地址：