SpringCloud (一) :微服務架構

什麼是微服務架構

簡而言之,微服務架構風格就是將單一應用的開發分為多個小的服務,每個小的服務在自己的進程中運行並使用輕量級機制進行通訊(通常是一個HTTP API源),這些服務圍繞業務性能進行構建,並且通過完全自動化的部署機制獨立的部署。這些只需要最低限度的集中管理的服務,可以使用不同的程式語言編寫,以及使用不同的數據存儲技術。—- Martin Fowler的部落格

( 單體架構 )

單體架構

( 微服務架構 )

微服務架構

 

微服務架構優點

  • 解決了程式碼臃腫的複雜問題。它把可能會變得龐大的單體應用程式分解成一套服務。雖然功能數量不變,但是應用程式已經被分解成可管理的塊或者服務,個體服務能被更快地開發,並更容易理解與維護。

  • 分割明確,使得保持團隊之間的界限變得容易。微服務架構使整個系統的分工更加明確,責任更加清晰,每個人專心負責為其他人提供更好的服務。在單體應用的時代,公共的業務功能經常沒有明確的歸屬。最後要麼各做各的,每個人都重新實現了一遍;要麼是隨機一個人做到他負責的應用裡面。

  • 服務可以獨立部署。如果你的應用由單個進程中的多個庫組成,則對單個組件的任何更改都將導致不得不重新部署整個應用。但是,如果將應用分解為多個服務,你可以期望單個服務的更改只需要重新部署該單個服務即可。

微服務架構缺點

  • 微服務架構整個應用分散成多個服務,定位故障點非常困難。

  • 穩定性下降。服務數量變多導致其中一個服務出現故障的概率增大,並且一個服務故障可能導致整個系統掛掉。事實上,在大訪問量的生產場景下,故障總是會出現的。

  • 服務數量非常多,部署、管理的工作量很大。

  • 服務拆分後,幾乎所有功能都會涉及多個服務。原本單個程式的測試變為服務間調用的測試。測試變得更加複雜。

 

微服務架構四大問題

  1. 客戶端如何訪問這麼多的伺服器

    通過API網關

  2. 服務與服務之間如何通訊

    同步通訊-HTTP/RPC

    非同步通訊-消息隊列 kafka RabbitMQ RocketMQ

  3. 這麼多服務,如何管理

    服務治理

    服務註冊與發現

    • 基於客戶端的服務註冊與發現 Apache Zookeeper

    • 基於服務端的服務註冊與發現 Netflix Eureka

  4. 服務掛了,怎麼辦

    • 重試機制

    • 服務熔斷

    • 服務降級

    • 服務限流

 

我的個人部落格站