微服務注冊中心怎麼配置

1. 基於DNS搭建高可用Eureka注冊中心

按Alt + 回車鍵，將會生成eureka-server.zip，解壓縮後得到一個maven 項目，將該項目錄入IDE。

我們首先來看一下pom文件，可以看出項目中引用了spring-cloud-starter-netflix-eureka-server, 並且springboot 的版本號為：2.1.2.RELEASE, Spring Cloud的版本號為：Greenwich.RC2RC2 表示還沒有正式發布，只是第二個Release Candidate。
接下來我們只需要兩個步驟，
a、修改EurekaServerApplication, 在@SpringBootApplication的註解上面，加入一個新的註解：@EnableEurekaServer
b、在resources 目錄中加入application.yml 文件， 並配置以下信息：

一個簡單的Eureka 注冊中心就已經可以使用了，我們運行一下這個spring boot 應用，找開瀏覽器：localhost:8761，即可看到我們的注冊中心就已經運行啟來了。並且EUREKA-SERVER也注冊到自己的注冊中心了。

單節點的注冊中心已經搭建完畢，但單節點的注冊中心存在單點故障的可能，不能用於生產環境。生產環境的Eureka一般採用集群方式進行部署。

通過client.serviceUrl.defaultZone配置多個peer節點，因為是在單機上測試，所以修改了host文件，並且使用不同的埠號來啟動注冊中心。正式的生產環境請根據自己的實際情況進行配置，比如：第一台Eureka的IP地址為：192.168.0.100，則defaultZone配置其他三台注冊中心http://192.168.0.101:8761/eureka/,http://192.168.0.102:8761/eureka/,http://192.168.0.103:8761/eureka/
依次啟動4台注冊中心，打開網頁:http://localhost:8764

可以看到其它三台注冊中心已經出現在已注冊的replicas和可用的replicas列表裡邊。

如上圖所示，4台注冊中心，每台注冊中心需要配置其他三台伺服器，以Eureka 1為例，其配置如下：

注冊中心是本應該是無狀態的，可以橫向擴展。但由於每台注冊中心的配置都不一樣，所以擴展起來比較麻煩，需要修改配置文件，這樣就無法做到快速的擴容。

微服務客戶端需要配置注冊中心的地址，使用的是如下的配置：

由於配置的是固定的IP地址，如果我們要擴容注冊中心，增加新的注冊中心節點，那我們就需要修改微服務客戶端的配置文件，將新的注冊中心節點進入的伺服器列表中。試想一下，如果有幾十個微服務，每個微服務有4個節點，那將會要修改上百個配置文件。很顯然這種方式不太可取，從軟體設計角度來說，違反了開閉原則。

其實Eureka 注冊中心還有另一種高可用配置方式，基於DNS。Eureka天生就可以部署在像AWS這樣的公有雲上，並且可以跨Region，跨Available Zone部署。雖然我們不用部署在雲端，依然可以利用這一特性，我們可以把Region看作我們數據中心的機房，Avaiable Zone 看作是機房中的網路區域，結合內部DNS服務來實現高可用的注冊中心。

畫重點：
a. region: default，配置地區
b. useDnsForFetchingServiceUrls，表示基於DNS獲取服務信息
c. eurekaServerDNSName: eureka.txzq.com.cn，配置域名伺服器名稱

鍵：txt.default.eureka.txzq.com.cn 值：shenzhen.eureka.txzq.com.cn
鍵：txt.shenzhen.eureka.txzq.com.cn 值：172.18.10.1 172.18.10.2 172.18.10.3 172.18.10.4

第一條記錄表示，default 區域，包含了哪些可用區，我們用shenzhen表示是深圳機房，txt記錄的值就設置為：shenzhen.eureka.txzq.com.cn
第二第記錄表示 , shenzhen機房有哪些伺服器，多台伺服器使用空格格開。
如果在本地測試，需要搭建一台自己的DNS伺服器，可以參考我的另一篇文章： 基於Docker快速搭建DNS Server

Client View是指DNS服務應用到哪一個網段，比如：172.18.10.0/24網段的IP連接到BIND伺服器，才會解析指定的域名。

在添加域名的時候，需要指定Client View，這里我們選擇我們剛剛創建的View_172.18.10.0，指的是只有在這個網段的IP訪問這台DNS伺服器，才能解析。

添加完一級域名後我們刷一下這個ZONE，然後設置一下本地DNS伺服器

DNS域名伺服器驗證通過後，我們接下來就可以在為這個域名添加我們所需要的txt 記錄了。

到這里我們的准備工作就已經基本完成了。使用Maven將注冊中心編譯成，輸出jar包。新建一個Eureka的docker鏡像，並啟動4個容器。基於DNS的注冊中心就搭建完畢了。

你只需要對DNS記錄進行變更，就可以實現動態的、快速擴容/縮容了。

關於如何將Eureka部署到Docker，請參考另一篇文章：

2. 微服務SpringCloudAlibaba配置匯總

在 pom.xml 中添加 spring-cloud-alibaba-dependencies 統一管理版本:

Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務元數據及流量管理。

通過 @EnableDiscoveryClient 註解表明是一個 Nacos 客戶端，該註解是 Spring Cloud 提供的原生註解

註：server-addr為Nacos Server 網址

Sentinel 以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

Sentinel 以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。

使用 Spring Cloud Alibaba Nacos Config，您可以在 Nacos Server 集中管理你 Spring Cloud 應用的外部屬性配置。

注意：Spring Boot 配置文件的載入順序，依次為 bootstrap.properties -> bootstrap.yml -> application.properties -> application.yml ，其中 bootstrap.properties 配置為最高優先順序

RocketMQ 是一款開源的分布式消息系統，基於高可用分布式集群技術，提供低延時的、高可靠的消息發布與訂閱服務。

配置 Output(Source.class) 的 Binding 信息並配合 @EnableBinding 註解使其生效

運行成功後即可在 RocketMQ 控制台的 消息 列表中選擇 test-topic 主題即可看到發送的消息

配置 Input(Sink.class) 的 Binding 信息並配合 @EnableBinding 註解使其生效

RPC框架分為提供方和消費方，提供方提供服務，消費方消費服務。這里採用nacos注冊中心和Dubbo框架配置。

3. 微服務架構之服務注冊與發現(一)

一、服務注冊中心的由來

假如沒有服務注冊中心，我們會幹些什麼事情呢？

在傳統行業的項目架構中以下的方案最為常見了：

這種架構開發、部署都是最簡單的，一般適用於中小企業訪問量並不是太多的情況下，各個系統服務一台機器就搞定了。系統之間的調用也是拿到對方的IP+PORT直接連接。

接下來可能因為應用B開始訪問量大了，單台機器已經不能滿足我們的需求，於是一些反向代理工具應運而出，其中比較常見的有Apache、Nigix，架構演變為：

相比之前的應用B的單台機器訪問，這種nginx代理的方式減輕了伺服器的壓力，但是可能會出現Nginx掛了，那麼整個服務也不可用，於是又來了這么一套架構：

這樣看方案算是完美了吧。然後事情並不是想像的那麼一帆風順，這還只是應用A調用一個應用B，如果應用A調用的可能是應用B、C、D、E...，這種完全就不知道他後面到底還想幹嘛，這種架構看似可以，但是絕對會累死運維的（nginx的配置將會非常混亂，直接導致運維不幹了）。

服務注冊中心幹些什麼事情呢？

上面提到的那種靠人力（主要是運維乾的事情）比較繁瑣，還不好維護，有這么幾點不方便：應用服務的地址變了、雙十一搞活動伺服器新增等等。那麼我們可以有這么的一種架構：

    服務注冊中心主要是維護各個應用服務的ip+port列表，並保持與各應用服務的通訊，在一定時間間隔內進行心跳檢測，如果心跳不能到達則對服務IP列表進行剔除，並同時通知給其它應用服務進行更新。同樣要是有新增的服務進來，應用服務會向注冊中心進行注冊，服務注冊中心將通知給其它應用進行更新。每個應用都有需要調用對應應用服務的地址列表，這樣在進行調用時只要處理客戶負載雜均衡即可。

二、微服務注冊中心

1.Zookeeper

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。

上面的話直接摘抄網路的內容，國內很多公司做分布式開發最初的選型大部分都是採用bbo框架。bbo框架注冊中心主要使用zookeeper。zookeeper服務端與客戶端的底層通訊為netty。zookeeper採用CAP理論中的CP，一般集群部署最少需要3台機器。

2.Euraka

先來看一下euraka的架構圖：

Register：服務注冊

當Eureka客戶端向Eureka Server注冊時，它提供自身的元數據，比如IP地址、埠，運行狀況指示符URL，主頁等。

Renew：服務續約

Eureka客戶會每隔30秒發送一次心跳來續約。 通過續約來告知Eureka Server該Eureka客戶仍然存在，沒有出現問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續約，它會將實例從其注冊表中刪除。 建議不要更改續約間隔。

Fetch Registries：獲取注冊列表信息

Eureka客戶端從伺服器獲取注冊表信息，並將其緩存在本地。客戶端會使用該信息查找其他服務，從而進行遠程調用。該注冊列表信息定期（每30秒鍾）更新一次。每次返回注冊列表信息可能與Eureka客戶端的緩存信息不同， Eureka客戶端自動處理。如果由於某種原因導致注冊列表信息不能及時匹配，Eureka客戶端則會重新獲取整個注冊表信息。 Eureka伺服器緩存注冊列表信息，整個注冊表以及每個應用程序的信息進行了壓縮，壓縮內容和沒有壓縮的內容完全相同。Eureka客戶端和Eureka 伺服器可以使用JSON / XML格式進行通訊。在默認的情況下Eureka客戶端使用壓縮JSON格式來獲取注冊列表的信息。

Cancel：服務下線

Eureka客戶端在程序關閉時向Eureka伺服器發送取消請求。 發送請求後，該客戶端實例信息將從伺服器的實例注冊表中刪除。該下線請求不會自動完成，它需要調用以下內容：

DiscoveryManager.getInstance().shutdownComponent()；

Eviction 服務剔除

在默認的情況下，當Eureka客戶端連續90秒沒有向Eureka伺服器發送服務續約，即心跳，Eureka伺服器會將該服務實例從服務注冊列表刪除，即服務剔除。

自我保護機制：

既然Eureka Server會定時剔除超時沒有續約的服務，那就有可能出現一種場景，網路一段時間內發生了 異常，所有的服務都沒能夠進行續約，Eureka Server就把所有的服務都剔除了，這樣顯然不太合理。所以，就有了 自我保護機制，當短時間內，統計續約失敗的比例，如果達到一定閾值，則會觸發自我保護的機制，在該機制下， Eureka Server不會剔除任何的微服務，等到正常後，再退出自我保護機制。自我保護開關(eureka.server.enableself-preservation: false)

3.Consul

consul推薦的架構圖：

Consul不像Euraka的部署那麼簡單，他是go語言開發的，需要運維單獨部署，有提供java的客戶端連接，採用的是CAP的CP。

4.Nacos

    Euraka是Spring Cloud Netflix早期版本中推薦使用的，後來euraka1.0版本不再維護，euraka2.0已經閉源，導致很多新項目基於Spring Cloud Netflix 開發的選型變遷為Consul.

Nacos是阿里開源的服務注冊中心，它可以與spring cloud aliaba集成使用。

Nacos的官方介紹：

    Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您實現動態服務發現、服務配置管理、服務及流量管理。

    Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平台。 Nacos 是構建以「服務」為中心的現代應用架構(例如微服務範式、雲原生範式)的服務基礎設施。

Nacos 地圖

Nacos 生態圖

如 Nacos 全景圖所示，Nacos 無縫支持一些主流的開源生態，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服務注冊與發現技術選型

以下是來自網上的一個分享：

除了上述的幾種以外，筆者更推薦使用Nacos作為服務注冊中心。

推薦理由：

Nacos服務注冊表結構Map<namespace, Map<group::serviceName, Service>>採用多層次Map結構，控制的顆粒度更細，支持金絲雀模式發布，心跳同步機制也更快速，服務更新更及時。

4. 基於docker部署的微服務架構（二）： 服務提供者和調用者

前一篇 基於docker部署的微服務架構（一）：服務注冊中心 已經成功創建了一個服務注冊中心，現在我們創建一個簡單的微服務，讓這個服務在服務注冊中心注冊。然後再創建一個調用者，調用此前創建的微服務。

新建一個maven工程，修改pom.xml引入 spring cloud 依賴:

在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:

這里eureka的注冊地址為上一篇中設置的defaultZone。
在 java 目錄中創建一個包 demo ，在包中創建啟動入口 AddServiceApplication.java

在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。

在服務注冊中心已經運行的情況下，運行 AddServiceApplication.java 中的 main 方法，啟動微服務。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了 ADD-SERVICE-DEMO 服務。

啟動第二個實例，修改埠為 8101 ，修改 AddController.java 中的輸出信息為

再次運行 AddServiceApplication.java 中的 main 方法。
訪問服務注冊中心頁面 http://localhost:8000 ， 可以看到已經成功注冊了兩個 ADD-SERVICE-DEMO 服務，埠分別為 8100 和 8101 。

新建一個maven工程，修改pom.xml引入 spring cloud 依賴:

在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:

在 java 目錄中創建一個包 demo ，在包中創建啟動入口 RibbonClientApplication.java

這里配置了一個可以從服務注冊中心讀取服務列表，並且實現了負載均衡的 restTemplate 。

在demo包下新建一個子包controller，在controller子包下創建一個controller對外提供介面。

可以看到這里的請求url用了服務注冊中心對應的 Application 。

運行 RibbonClientApplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8200/add?a=1&b=2 ，得到返回結果：

多次訪問，查看 AddServiceApplication 的控制台，可以看到兩個 ADD-SERVICE-DEMO 被負載均衡的調用。
demo源碼 spring-cloud-1.0/ribbon-client-demo

新建一個maven工程，修改pom.xml引入 spring cloud 依賴:

在 resources 目錄中創建 application.yml 配置文件，在配置文件內容:

在 java 目錄中創建一個包 demo ，在包中創建啟動入口 FeignClientApplication.java

在demo包下新建一個子包service，在service子包下創建一個介面 AddService.java 調用之前創建的微服務 ADD-SERVICE-DEMO 。

這里 @FeignClient 註解中的參數為服務注冊中心對應的 Application 。

在demo包下再新建一個子包controller，在controller子包下創建一個 FeignController.java 對外提供介面。

FeignController 里注入了剛才創建的 AddService 介面。

運行 FeignClientApplication.java 中的 main 方法，啟動項目。
在瀏覽器中訪問 http://localhost:8300/add?a=1&b=2 ，得到返回結果：

多次訪問，查看 AddServiceApplication 的控制台，可以看到兩個 ADD-SERVICE-DEMO 被負載均衡的調用。
demo源碼 spring-cloud-1.0/feign-client-demo

以 add-service-demo 為例，
復制 application.yml ，重命名為 application-docker.yml ，修改 defaultZone 為：

這里修改了 defaultZone 的訪問url，如何修改取決於部署docker容器時的 --link 參數， --link 可以讓兩個容器之間互相通信。

修改 application.yml 中的 spring 節點為：

這里增加了 profiles 的配置，在maven打包時選擇不同的profile，載入不同的配置文件。

在pom.xml文件中增加：

選擇 docker profile，運行 mvn install -P docker ，打包項目並生成docker鏡像， 注意docker-maven-plugin中的 <entryPoint> 標簽里的內容不能換行，否則在生成docker鏡像的時候會報錯 。
運行成功後，登錄docker節點，運行 docker images 應該可以看到剛才打包生成的鏡像了。

在前一篇中，已經創建了一個 service-registry-demo 的docker鏡像，這里先把這個鏡像運行起來。

對這條命令做個簡單說明， -d 指定當前容器運行在後台， --name 指定容器名稱， --publish 指定埠映射到宿主機， --volume 這個掛載是為了解決容器內的時區和宿主機不一致的問題，讓容器使用宿主機設置的時區，最後指定使用的docker鏡像，鏡像名稱和標簽需要根據自己的情況做修改。
運行這條命令之後， service-registry-demo 的容器就啟動了。訪問 http://宿主機IP:8000 ，打開注冊中心的頁面。
下邊啟動 add-service-demo 容器，

這條命令和上一條差不多，只是增加了一個 --link 參數， --link 指定容器間的連接，命令格式 --link 容器名:別名 ，這里連接了之前創建的名為 service-registry-demo 的容器，這里的別名和 application-docker.yml 文件中配置的 defaultZone 一致。其實就是通過別名找到了對應的容器IP，進到容器里查看 hosts 文件就明白了，其實就是加了條hosts映射。
add-service-demo 容器啟動成功之後，刷新配置中心的頁面，發現已經注冊到配置中心了。