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

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

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

什麼是軟件架構

在軟件的內部，通過綜合各類因素的考量，權衡選擇特定的技術，將系統劃分不一樣的部分並使這些相互分工，彼此寫做，爲用戶提供須要的價值。

• 哪些因素

1. 業務需求
2. 技術棧
3. 成本
4. 組織架構
5. 可擴展性
6. 可維護性

• 以個人我的經歷

1. 一層架構

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

1. MVC

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

1. 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了，老鐵，能夠考慮其餘了，如何考慮下回繼續說。