Spring Cloud 學習 –服務治理實現原理
需要JAVA Spring Cloud大型企業分佈式微服務雲構建的B2B2C電子商務平臺源碼：壹零叄八柒柒肆六二六
如圖爲eureka的結構圖，其中包括三個部分，服務註冊中心（Eureka Server）,服務提供者（Eureka Client），服務消費者（Eureka Client）
Eureka Server -1 和Eureka Server -2 組成了高可用集羣，任何一個client註冊其中的一個Server,都會根據配置的時間同步到另一個Server.
服務註冊中心（Eureka Server）
作爲一個註冊中心，每個微服務（Client）在啓動後將會把自己的主機，端口號，通信協議等信息發送給註冊中心進行註冊，註冊中心會存儲微服務的ip地址、端口等信息。
服務消費者可以從服務發現組件查詢服務提供者的網絡地址，並使用該地址調用服務提供.者的接口.
各位服務與服務組件使用統一的心跳機制，如果服務發現組件長時間無法與某微服務實例通信，就會被註銷。
微服務網絡地址發生變更時，會重新註冊到服務發現組件，避免人工修改提供者的網絡地址。
服務發現組件核心功能：
服務註冊表：記錄微服務信息的服務的名稱、ip、端口等，服務註冊表查詢API和管理API。
服務註冊與服務發現：服務註冊是微服務啓動時，件自己的信息註冊到服務發現組件上的過程。服務發現是指查詢可用微服務列表及其網絡地址的機制。
服務檢查：服務發現組件使用過一定機制定時檢測已註冊的服務。
服務同步：當多個註冊中心Server組成集羣的時候，如果其中一個註冊中心註冊了一個Client,那麼這個Client就會自動同步到其他集羣中的Server.
服務提供者（Eureka Client）
啓動的時候通過REST請求將自己註冊到Eureka Server 上，同時帶上自身服務的元數據信息。通過eureka:
instance:metadata-map: 進行設置。其他的消費者就可以從Server獲取。eureka: client: register-with-eureka參數控制自己是否能夠被註冊默認爲true.
在註冊完成後，服務提供者會維護一個心跳（發送通信包）來持續告訴Server是否存活，如果超過一定時間沒有心跳，那麼就會被Server判斷該Cliebt失效，將其狀態設置爲“DOWN”，並將其從服務列表中去除。
服務消費者（Eureka Client）
啓動服務消費者後，定期發送REST請求去獲取服務列表。
獲取到服務列表後，通過服務名可以獲得具體提供服務的實例名和該實例的元數據信息。
消費者可以通過Ribbon或者Feign來使用服務提供者。
服務提供者和服務消費者從配置上沒有區別，只是可能需要配置metadata元數據信息來提供給消費者。兩者只有行爲上的區別，一個提供服務（低層的業務），一個消費服務（高層的業務，通過http請求去請求調用提供者中的相關方法）。
Regin和Zone
region：可以簡單理解爲地理上的分區，比如亞洲地區，或者華北地區，再或者北京等等，沒有具體大小的限制。根據項目具體的情況，可以自行合理劃分region。
zone：可以簡單理解爲region內的具體機房，比如說region劃分爲北京，然後北京有兩個機房，就可以在此region之下劃分出zone1,zone2兩個zone
一個region中可以有多個zone,每個服務需要註冊到一個zone中，所以每個client對應一個regin和一個zone.在進行服務調用的時候，優先訪問同一個zone中的服務提供方，若訪問不到，再訪問其他zone.不過這個可以參數控制，eureka.client.prefer-same-zone-eureka控制，默認爲true,也就是優先找同一個zone中的。
@EnableDiscoveryClient和@EnableEurekaClient區別
SpringCLoud中的“Discovery Service”有多種實現，比如：eureka, consul, zookeeper。
1 @EnableDiscoveryClient註解是基於spring-cloud-commons依賴，並且在classpath中實現；
2 @EnableEurekaClient註解是基於spring-cloud-netflix依賴，只能爲eureka作用；
Java B2B2C多用戶商城 springboot架構