微服務和單體架構的區別

煙囪式系統建設的弊端：

1.重複功能的建設和維護帶來的重複投資

2.煙囪式系統交互集成和協做成本高

3.不利於業務的沉澱和持續發展

 

 

1.重複功能的建設和維護帶來的重複投資

這一條很好理解就是當咱們公司內部擁有多套子系統的時候，勢必會帶來一些重複性的工做，好比說公司內部OA系統和報表系統、兩個系統按照單獨的設計都會存在用戶管理功能，若是某一天公司須要在加一套管理系統的話，那麼在管理系統中還須要添加一套用戶管理的邏輯，該重複功能的建設工做和維護勢必會帶來時間、資源上的浪費。

 

2.煙囪式系統交互集成和協做成本高

隨着公司內部系統業務不斷的增長以及完善，多個系統之間的集成和交互也將變得困難，多系統之間的協做、溝通成本較高，例如公司有一套mes系統（生產製造系統）該系統當中有wip模塊、alm模塊當有一天我新建了一個報表系統去統計使用人數，那我須要從兩個系統當中分別去獲取用戶，帶來的時間成本和溝通成本是比較高昂的

3.不利於業務的沉澱和持續發展

不利於產品的快速跟新和迭代，當今互聯網項目每週每個月都在不停的變化、市場的反饋根業務上的須要都須要獲得快速的響應，而傳統系統的迭代週期長對業務響應不及時。

爲何要微服務化

1.協做成本高，業務響應慢 傳統單體架構若是功能模塊100個以上通常的公司內部按照功能模塊進行劃分工做，每一次新版本上線總會出現各類問題，例如分支合併衝突、代碼不一致、等各類問題也會帶來很大的協做成本，溝通成本。

2.系統複雜度增長難以維護

單體架構隨着業務量不斷的增長和擴展以及隨着組織人員的變化，業務代碼也會變得愈來愈難以維護，一次小小的改動可能會帶來災難行的風險！

3.錯誤不能隔離

當全部的業務功能模塊都彙集在一個程序集當中，若是其中的某一個小的功能模塊出現問題，那麼都有可能會形成整個系統的崩潰

4.數據庫鏈接能力很難擴展

數據庫集羣的鏈接數量是有限的，當數據庫的鏈接數量資源隨着實例的增長將難以保證

5.應用擴展能力差

單體架構不可以按需擴展，例如某一天咱們的網站當中部分業務模塊訪問量暴增，若是咱們要對服務擴展只能把整個系統進行打包、發佈而不能針對特定的模塊進行擴容

 

綜合上述煙囪式建設模式帶來的一些弊端接下來說到了soa方法，SOA的主要特色有以下幾種：

• 面向服務的分佈式計算
• 服務間鬆耦合
• 支持服務的組裝
• 服務註冊和自動發現
• 以服務契約方式定義服務交互方式

 

SOA架構帶來的真正核心意義價值：服務重用。

舉例公司內部有多個系統進行維護，WIP、ALM、報表等系統，採用SOA架構思想把用戶管理單獨拿出來做爲一個服務提供給上述幾個系統使用、此時咱們發現該架構的設計可以最大程度的避免了「重複建設工做」，從這方面也體現出來了SOA的核心價值：服務重用

 

 

 

1.傳統單體架構

 

  優勢

1. 易於開發
   1. 單體應用程序開發相對簡單，容易理解。
2. 易於測試
   1. 單體架構全部功能都聚合在一塊兒，啓動集成開發環境一旦啓動該進程，就能夠當即開始系統測試或者功能測試
3. 易於部署
   1. 單體架構部署的話直接把環境發佈部署到iis便可

 缺點

1. 開發成本高
   1. 代碼重複率高，需求變動困難，沒法知足新業務快速上線和敏捷交付
2. 代碼維護成本高
   1. 本地代碼不斷迭代、變動代碼難以維護和理解，關鍵性的代碼改動一處多處會受影響
3. 部署成本高
   1. 每次小的改動都得須要部署整個程序
4. 測試成本高
   1. 同部署成本高
5. 可靠性差
   1. 某個bug，例如死循環、事務死鎖等會致使整個系統沒法運行，宕機。
6. 可伸縮性差
   1. 水平擴展只能對整個系統進行擴展，沒法針對某一個功能模塊進行擴展

 

微服務

   

 

 

   優勢

1. 單個微服務都很小，可以根據實際的訪問量按需擴展
2. 微服務可以被小團隊獨立開發便於理解和維護
3. 可伸縮彈性架構、當服務器壓力太高的時候可動態註冊服務，分攤服務器壓力。
4. 統一鑑權中心，單點登陸、降級、熔斷、限流策略避免重複造輪子
5. 微服務是鬆耦合，是有功能意義的服務，不管是開發階段、或者是部署和測試階段都是獨立的
6. 微服務能使用不一樣的語言開發
7. 每一個微服務都有本身的存儲能力，能夠有本身的數據庫，也能夠統一數據庫
8. 減小重複開發

    容器部署優勢

1. 傳統的部署方法可能致使本地測試沒問題，可是發佈線上會出現各類問題
2. 容器化服務便於安裝部署、節省內存空間、後期可集成ci cd
3. 容器化服務啓動快捷方便一般可達到秒級啓動和銷燬

   先後端分離優勢

  缺點

1. 微服務架構可能帶來過來的操做
2. 鏈路變長，排查問題難度增長，分佈式系統複雜很差管理
3. 中心化的微服務架構可能會帶來若是某臺服務及宕機或者出現異動那麼有可能致使整個架構所有癱瘓

 

中心化的微服務

    註冊中心的好處是，若是在作服務集羣負載均衡的時候例如wip多個服務器都得寫到配置文件，首先方式很low其次不利於擴展，採用服務註冊的方式調用服務實例名 ，而且提供健康檢測、異常宕機反饋給api網關

穩定性是網關很是重要的一環，監控、告警須要作的很完善才能夠，好比接口調用量、響應時間、異常、錯誤碼、成功率等相關的監控告警，還有線程池相關的一些，好比活躍線程數、隊列積壓等，還有些系統層面的，好比CPU、內存。

   網關是全部服務的入口，對於網關的穩定性的要求相對於其餘服務會更高，最好可以一直穩定的運行，儘可能少重啓，但當新增功能、或者加日誌排查問題時，不可避免的須要從新發布，所以能夠參考Zuul的方式，將全部的核心功能都基於不一樣的攔截器實現，攔截器的代碼採用Groovy編寫，存儲到數據庫中，支持動態加載、編譯、運行，這樣在出了問題的時候可以第一時間定位並解決，而且若是網關須要開發新功能，只須要增長新的攔截器，並動態添加到網關便可，不須要從新發布。