『高級篇』docker容器來說軟件架構的進化（二）

原創文章，歡迎轉載。轉載請注明：轉載自IT人故事會，謝謝！
原文鏈接地址：『高級篇』docker容器來說軟件架構的進化（二）

也工作了10年了，對于軟件的架構也是不斷學習總結，怎么樣的發展到微服務的架構。

什么是軟件架構

在軟件的內部，經過綜合各種因素的考量，權衡選擇特定的技術，將系統劃分不同的部分并使這些相互分工，彼此寫作，為用戶提供需要的價值。

• 哪些因素

  1. 業務需求
  2. 技術棧
  3. 成本
  4. 組織架構
  5. 可擴展性
  6. 可維護性
• 以我的個人經歷
  1. 一層架構

     2007年在河南本地的一個公司實習，負責的是一個老系統，它用到了jsp和servlet，jdbc的技術，java早期的標準技術，在jsp里面看到了html，還看到了一大片一大片的java代碼，直接寫在jsp里面。在servlet里面有上千行的代碼，300，500行都很平常的事情，包含了業務邏輯，返回給jsp的業務內容，業務操作，數據庫操作。維護起來讓你很崩潰，不過才畢業也就忍了，堅持了半年。后來要去濟南。這種在極其簡單的業務里面還是可行的，但是現在也看不到了。

2. MVC

   2008年去了濟南，濟南畢竟要全國知名的公司就進入了。雖然是996，但是感覺還好，至少代碼不那么復雜了，雖然是jsp，java代碼基本沒有，分了很多文件夾，層次清晰分工明確，也學到MVC的三層架構。解決了代碼調用雜亂無章，讓代碼清晰，通過各層之間定義接口的方式，讓接口和實現分離，可以將原來的實現替換成方案，讓別人理解，降低了溝通成本，維護成本，分工的明確各司其職，很長時間都是軟件的架構經典模式。像SSH 和SSM其實MVC的實現。

3. dubbo

   2013年換了一家公司，dubbo那時候才出來1年，公司嘗試用dubbo改造一個核心系統，為什么要用dubbo，因為里面java代碼加頁面代碼100多萬行，需求每個月還不斷的添加，牛逼了我的哥！3年以上的人至少2-3個月熟悉都不一定能上手，只能想辦法拆分，拆分的過程也是對老代碼進行梳理和重構，dubbo的出現可以讓前后端物理上隔離開來，完全變成2個可以單獨維護的模塊，從感官上復雜度就下降了一半，這種開發歷程，在河南這邊可能不太明顯，在北上廣應該都有類似的經歷。多年的開發的人員。

其實上邊的說的都是單體架構，很多目前的公司也都是單體架構，雖然dubbo，分離成了前后2個個體，但他并不是微服務。

什么是單體架構

功能，業務集中在一個發布包里，部署運行在同一個進程中。

• 優勢

  1. 易于開發（方便開發人員開發）
  2. 易于測試（準備一臺服務器，部署下就可以測試了）
  3. 易于部署（所有代碼都打在一個包里面，直接拷貝一個war部署在服務器上，目錄中）
  4. 易于水平伸縮（節點的復制，新建服務器，配置好運行環境，直接拷貝一個war部署在服務器上）
• 單體面臨的挑戰

  隨著很多傳統行業往互聯網考慮，業務變化瞬息萬變，系統的升級也越來越頻繁，用戶的數量快速增長，單體架構已經無法滿足互聯網的發展了，它有很多致命的硬傷。

1. 代碼膨脹，難以維護（出現bug，分析定位成本都很高，隨著代碼開發，開發人員對全局的理解越來越缺失，修復一個bug，可能引入其他bug，惡性循環，導致難以維護）
2. 構建，部署成本大（代碼越來越多，構建部署啟動的時間越來越長，項目維護的人越來越多，大家都在構建，都在部署，難免互相影響，難免造成一個bug的修復，提交給測試驗證的時間拉的很長，效率越來越底下）
3. 新人上手困難（現在的互聯網公司，都是鐵打的營盤流水的兵，過于復雜新人還沒完全理解上手的時候，就已經離職了）
4. 創新困難（成功引入新框架困難，就算成功引入學習成本極高）
5. 可擴展性差（代碼都運行在同一個進程里面，一個進程只能運行在一天機器上，給這個機器加多少內存，加多少cpu才能夠我們這個項目用呢，有的框架對CPU要求高，有的框架對內存要求高，有的框架對硬盤要求高，其實最終選擇了一個各方面都好的機器，是不是增加了成本的開支）

PS：綜上所述，單體架構已經out了，老鐵，可以考慮其他了，如何考慮下回繼續說。