微服務架構優點
-
解決了代碼臃腫的復雜問題。它把可能會變得龐大的單體應用程序分解成一套服務。雖然功能數量不變，但是應用程序已經被分解成可管理的塊或者服務，個體服務能被更快地開發，並更容易理解與維護。
-
分割明確，使得保持團隊之間的界限變得容易。微服務架構使整個系統的分工更加明確，責任更加清晰，每個人專心負責為其他人提供更好的服務。在單體應用的時代，公共的業務功能經常沒有明確的歸屬。最后要么各做各的，每個人都重新實現了一遍；要么是隨機一個人做到他負責的應用里面。
-
服務可以獨立部署。如果你的應用由單個進程中的多個庫組成，則對單個組件的任何更改都將導致不得不重新部署整個應用。但是，如果將應用分解為多個服務，你可以期望單個服務的更改只需要重新部署該單個服務即可。
微服務架構缺點
-
微服務架構整個應用分散成多個服務，定位故障點非常困難。
-
穩定性下降。服務數量變多導致其中一個服務出現故障的概率增大，並且一個服務故障可能導致整個系統掛掉。事實上，在大訪問量的生產場景下，故障總是會出現的。
-
服務數量非常多，部署、管理的工作量很大。
-
服務拆分后，幾乎所有功能都會涉及多個服務。原本單個程序的測試變為服務間調用的測試。測試變得更加復雜。
微服務架構四大問題
-
客戶端如何訪問這么多的服務器
通過API網關
-
服務與服務之間如何通信
同步通信-HTTP/RPC
異步通信-消息隊列 kafka RabbitMQ RocketMQ
-
這么多服務，如何管理
服務治理
服務注冊與發現
-
基於客戶端的服務注冊與發現 Apache Zookeeper
-
基於服務端的服務注冊與發現 Netflix Eureka
-
-
服務掛了，怎么辦
-
重試機制
-
服務熔斷
-
服務降級
-
服務限流
-
