dubbo（一）服務治理介紹

一、服務不采取治理的痛點：

服務不治理，需要在應用rest中調用服務service一般有以下方法：

1、service和rest寫在一個項目中，這樣其他項目也需要調用同樣的service，需要再寫一遍，代碼無法複用；

2、service和rest分開部署，rest的pom中添加service的依賴，這樣如果一個service的實作邏輯需要修改，所有的rest都要重新打包部署；

3、service隻暴露接口（即api），rest隻依賴這個接口，不關心service的邏輯實作，因為在rest的pom中隻引用了api，使用Autowired注解是發現不了服務的。

.......

對于這樣的一系列問題，dubbo和springcloud都是比較成熟的服務治了解決方案架構。

二、服務治理之dubbo部署：

規範：一套系統一般分為api、service、rest三個元件：

api中定義基本的dto和service接口；

serivce（pom）依賴api，實作service接口，并注冊到注冊中心；

rest（pom）依賴api，從注冊中心消費service服務。

部署時，api不用部署，隻需要部署service和rest。

注冊中心、service、rest三者可獨立部署到不同機器上，通過注冊中心去注冊和發現服務。

api和服務一般是一對一的，即一套api對應一套service，service、rest為一對多，一個rest可以調用多個service。