微服務java b2b商城系統_java商城源碼100%開源適合2次開發-服務治理實現原理

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 源碼 多級分銷springmvc mybatis多租戶電子商城系統