微服務和單體架構的區別

煙囪式系統建設的弊端：

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編寫，存儲到數據庫中，支持動態加載、編譯、運行，這樣在出了問題的時候能夠第一時間定位並解決，並且如果網關需要開發新功能，只需要增加新的攔截器，並動態添加到網關即可，不需要重新發布。