「微服務」 關於微服務的幾點老闆關心問題

回答關於微服務的幾點老闆關心問題

單體系統在初期可以實現比較方便地開發與使用，但是隨著系統的發展，維護成本變大，且難以控制（當一個系統業務複雜且架構設計不合理，同時以前的開發者之間沒有什麼規範的時候，後續新人對於功能的修改、維護、完善都必須建立在對系統整體業務的把握上，這也對開發人員提出了更高要求）。

引進微服務架構體系作為後續主體架構，將不同的模塊拆分成多個不同的服務，服務能夠實現獨立的部署與擴展，且不同的服務都運行在自己的進程中，由於部署存在穩定的邊界，這樣每個服務的更新都不會影響到其他服務的運行，也更方便後續整體架構的水平擴展。同時平衡需求的多變和軟體工程本身的技術複雜性的矛盾，從而在應用開發小團隊中推行敏捷開發開發模式。

1、開發效率能提高嗎？

• 在單體架構中，隨著業務的發展，代碼會越來越多，變得臃腫，編譯、啟動、打包、發布會變得越來越慢。
• 一個小功能的改動，重啟都需要等待幾分鐘，導致很多的時間會浪費在這個過程中。
• 由於業務的變化性較高，使得各個業務的代碼交互變得複雜，如果維護不當，會導致這些代碼難以維護。 如果進行維護，就算只改動了一個小功能，也可能會影響到N個模塊業務。
• 在微服務的體系下，將不同的業務層劃分成各個不同的業務模塊，使得模塊間的耦合度降低，方便維護。
• 每個業務模塊獨立成一個微服務，由不同的人員（團隊）來維護，達到可以獨立開發和獨立部署。
• 分工明確，代碼邏輯清晰、代碼量小，可維護性高，整體提高開發效率。

2、產品質量能提高嗎？

單體架構是將所有業務功能全部集中在一個系統服務中，如果某個業務突發請求，或者異常，可能會導致整個系統宕機。

微服務體系中，會將不同的業務劃分成不同的服務，各個服務會使用多個服務進行負載、容錯、隔離。如果某個服務宕機，不會影響到整個系統的正常運行。

3、代碼的執行效率能提高嗎？

代碼的執行效率與算法和設計有關係。微服務只解決了業務的劃分之後服務治理與服務調用，對業務代碼的執行效率不會有明顯的改善，但是在改造的過程中，會逐步修復算法與設計的問題。

4、可擴展性如何？支持靈活的二次開發嗎？以什麼形式來支持呢？

微服務可以根據業務情況，對高並發業務或者需要高保障的業務進行快速的橫向擴容。

微服務以組件化的形式存在，可以根據公司不同的業務場景，滿足各種定製化需求，快速交付。

微服務對後續PaaS平臺的研發和支持提供了基礎技術保障。

5、伺服器成本如何？與現在是持平還是更節省？還是更高？

由於微服務都是運行在獨立的容器中，相比ECS，大大節約了CPU與內存的使用率。

對資源的要求相對單體系統來說整體降低。

單體架構只需要一個獨立的pod容器，但是在微服務中，每個獨立服務都需要一個獨立的pod容器。

獨立服務的容錯、負載（一個業務服務運行在多個進程/容器中），則需要消耗更多的系統資源。

在微服務體系中，資源與容錯能力是成正比的。容錯能力越強，則消耗的資源越多。

6、後續的運維成本如何？

微服務體系物理架構在後續水平擴展方面可減少伺服器數量和降低對伺服器配置要求（高頻/高可用微服務和低頻/低可用微服務可分別部署至不同配置的伺服器上。

微服務體系中每個服務都可以獨立部署（高內聚低耦合），這樣每個服務的更新都不會影響到其他服務的運行或影響範圍可控，也更方便後續整體架構的水平擴展。

對於運維人員的要求： 掌握全鏈路監測、灰度發布，掌握基礎微服務知識等相關能力。

對於測試人員的要求： 混沌測試（全鏈路測試）。

微服務架構體系加持續集成方案帶來的預期收益主要有：

• 系統水平擴展能減少應用伺服器需求數量和降低對伺服器的性能要求；
• 快速響應業務部門的需求（系統短周期開發，測試，發布迭代的敏捷開發模式）；
• 相對單體系統降低開發人員的開發成本（微服務功能原子化）及管理成本（持續構建，靜態代碼檢測，部署自動化）；
• 系統水平擴展更便捷（子系統以微服務熱發布集成）；
• 系統穩定性更好（前後端分離，服務流量控制，服務健康檢查，服務調度可監控及可追溯）。