在網際網路應用領域，服務的動態性需求十分常見，這就對服務的自動發現和可動態擴充套件提出了很高的要求。

微服務系統動輒上萬個服務，而且還要動態伸縮。以人工寫好的IP、Port 硬編碼指令碼的方式無法做到大規模自動化，稍微多點服務運維就傻了。微服務必然要做到ip和port自動分配，減少人工干預。我們需要讓每個服務能動態的建立地址，同時呼叫方要能感知地址變化。

這就需要有一個服務註冊與發現的機制，這篇檔案就是討論如何實現這個機制。

1. 服務註冊發現的流程

我們做這個事情要達到的目的是：

註冊發現模式	傳統模式
服務啟動後自動被發現	手動註冊
動態變更負載均衡	人工寫入靜態配置
自動伸縮規模	運維較長時間的手動調整

1.1 服務 “自注冊” 與 “第三方註冊”。

按註冊源分

1.自注冊：服務內部啟動客戶端，連線註冊中心，寫入服務資訊。

好處：

沒有引入第三方，程序數量少，少依賴。

問題：

服務程式碼對註冊中心進行了硬編碼，若更換了註冊中心，服務程式碼也必須跟著調整；
註冊中心必須與每個服務都保持通訊，來做心跳檢測。如果服務很多時，對註冊中心也是一種額外的開銷；

2.第三方註冊（本文采用方式）：採用協同程序的方式，監聽服務程序的變化，將服務資訊寫入註冊中心。

好處：做到了服務與註冊中心的解耦，對服務而言，完成了服務的自動化註冊；
問題：協同程序本身也要考慮高可用，否則將成為單點故障的風險點；

1.2 自注冊的實現

自注冊不是我們本篇要討論的，可以自己寫程式碼實現，我們討論第三方註冊的實現。

1.3 第三方註冊的實現

Docker 的出現，以及微服務架構的興起，讓眾多開源專案開始關注在鬆耦合的架構前提下，如何基於 Docker 實現一套真正可動態擴充套件的服務架構。

這裡我們使用 Registrator + Consul + Consul-template + Nginx 這幾個開源元件來實現可動態擴充套件的服務註冊與發現機制，當然，毫無疑問他們都跑在docker上。

首先看看流程：

這裡寫圖片描述

服務註冊中心：作為整個架構中的核心，要支援分散式、持久化儲存，註冊資訊變動實時通知消費者。

服務提供者：服務以 docker 容器化方式部署（實現服務埠的動態生成），並以 docker-compose 的方式來管理，通過 Registrator 可以檢測到docker程序資訊以完成服務的自動註冊。

服務消費者：要使用服務提供者提供的服務，和服務提供者往往是動態相互轉位置的。

服務註冊：服務提供者到註冊中心註冊；
服務訂閱：服務消費者到註冊中心訂閱服務資訊，對其進行監聽；
快取：本地快取服務列表，減少與註冊中心的網路通訊；
服務呼叫：先查詢本地快取，找不到再去註冊中心拉取服務地址，然後傳送服務請求；
變更通知：服務節點變動時（新增、刪除等），註冊中心將通知監聽節點，更新服務資訊。

2. 工具介紹

2.1 Registrator

Registrator：一個由Go語言編寫的，針對docker使用的，通過檢查本機容器程序線上或者停止執行狀態，去註冊服務的工具。所以我們要做的實驗，所有的工具都是在docker上執行的，就是因為registrator是通過檢查docker容器的狀態來判斷服務狀態的，這樣就和我們的程式碼實現完全解耦了，對上層透明化，無感知。它有如下特點

通過docker socket直接監聽容器event，根據容器啟動/停止等event來註冊/登出服務
每個容器的每個exposed埠對應不同的服務
支援可插拔的registry backend，預設支援Consul, etcd and SkyDNS
自身也是docker化的，可以容器方式啟動
使用者可自定義配置，如服務TTL（time-to-live）、服務名稱、服務tag等

2.1 consul

我們上圖所說的服務註冊中心，就是這玩意。Consul 是一個分散式高可用的服務發現和配置共享的軟體。由 HashiCorp 公司用 Go 語言開發。

Consul在這裡用來做 docker 例項的註冊與配置共享。

特點：

一致性協議採用 Raft 演算法，比Paxos演算法好用. 使用 GOSSIP 協議管理成員和廣播訊息, 並且支援 ACL 訪問控制.
支援多資料中心以避免單點故障，內外網的服務採用不同的埠進行監聽。而其部署則需要考慮網路延遲, 分片等情況等.zookeeper 和 etcd 均不提供多資料中心功能的支援.
健康檢查. etcd 沒有的.
支援 http 和 dns 協議介面. zookeeper 的整合較為複雜, etcd 只支援 http 協議.
還有一個web管理介面。

2.3 consul-template

一開始構建服務發現，大多采用的是zookeeper/etcd+confd。但是複雜難用。consul-template，大概取代了confd的位置，以後可以這樣etcd+confd或者consul+consul-template。

consul template的使用場景：consul template可以查詢consul中的服務目錄、key、key-values等。這種強大的抽象功能和查詢語言模板可以使consul template特別適合動態的建立配置檔案。例如：建立apache/nginx proxy balancers、haproxy backends、varnish servers、application configurations。

consul-template提供了一個便捷的方式從consul中獲取儲存的值，consul-template守護程序會查詢consul服務，來更新系統上指定的任何模板，當更新完成後，模板可以選擇執行一些任意的命令，比如我們這裡用它來更新nginx.conf這個配置檔案，然後執行nginx -s reload命令，以更新路由，達到動態調節負載均衡的目的。

consul-template和nginx必須裝到一臺機器，因為consul-template需要動態修改nginx配置檔案

2.4 nginx

這個耳熟能詳的名字，不用過多介紹了，它在這裡就是做負載均衡，轉發請求用的。當然最擅長負載均衡的是直接用硬體，軟體做效能比不上。但軟體成本低、維護方便。

3. 單機實驗

首先看一個簡單的傳統負載均衡web服務

load balance web servers

這個很好理解吧，client訪問nginx，然後被轉發到後端某一個web server上，傳統的負載均衡。如果後端有新增/刪除web server，運維手動改下nginx.conf，然後重新載入配置，就可以調整負載均衡了。

再看看我們基於微服務自動註冊和發現模式下的負載均衡：

Servies register and find

負載均衡的方式沒有變，只是多了一些外圍的元件，當然這些元件對client是不可見的，client依然只能看到nginx入口，訪問方式也沒變化。

其中，我們用registrator來監控每個web server的狀態。當有新的web server啟動的時候，registrator會把它註冊到consul這個註冊中心上。由於consul_template已經訂閱了該註冊中心上的服務訊息，此時consul註冊中心會將新的web server資訊推送給consul_template，consul_template則會去修改nginx.conf的配置檔案，然後讓nginx重新載入配置以達到自動修改負載均衡的目的。同樣當一個web server掛了，registrator也能感知到，進而通知consul做出響應。

整個過程不需要運維人工的干預，自動完成。接下來我們找一臺機器上實踐下這個方案

3.1 環境

header	header
作業系統	ubuntu：16.04 x86_64，核心：4.8.0-58-generic
主機ip	10.111.152.136
docker	Docker version 1.12.6, build 78d1802
docker-compose	docker-compose version 1.8.0, build unknown

首先安裝 docker 和 docker-compose

$ apt-get install docker docker-compose -y

隨便找個目錄，建立模板檔案 docker-compose.yml

#backend web application, scale this with docker-compose scale web=3
web:
  image: liberalman/helloworld:latest
  environment:
    SERVICE_80_NAME: my-web-server
    SERVICE_TAGS: backend-1
    MY_HOST: host-1
  ports:
  - "80"

#load balancer will automatically update the config using consul-template
lb:
  image: liberalman/nginx-consul-template:latest
  hostname: lb
  links:
  - consulserver:consul
  ports:
  - "80:80"

consulserver:
  image: progrium/consul:latest
  environment:
    SERVICE_TAGS: consul servers
  hostname: consulserver
  ports:
  - "8300"
  - "8400"
  - "8500:8500"
  - "53"
  command: -server -ui-dir /ui -data-dir /tmp/consul -bootstrap-expect 1

# listen on local docker sock to register the container with public ports to the consul service
registrator:
  image: gliderlabs/registrator:master
  hostname: registrator
  links:
  - consulserver:consul
  volumes:
  - "/var/run/docker.sock:/tmp/docker.sock"
  command: -internal consul://consul:8500

注意： liberalman/helloworld和liberalman/nginx-consul-template這兩個映象我已經實現了，可以pull下來，大家可以直接使用。想要看他們怎麼寫的，訪問https://github.com/liberalman

3.2 啟動

進入模板所在目錄，執行

$ docker-compose up

沒問題的話就啟動成功了，其中的映象自動被下。訪問 http://localhost 可以看到一個 web 頁面：

Hello World! I’m host-1 addr:172.17.0.2. I saw that you are 172.17.0.6:35612.

這個內容實際是後端web伺服器helloworld所反饋的頁面，它告訴我們它自己的地址是172.17.0.2(docker的內網地址)，它所看到的前端訪問過來的ip是172.17.0.6，實際上這個前端是我們的nginx的負載均衡的代理轉發的，所以它看到的實際是nginx的地址。

這裡的host-1是我自己設定的物理機的名稱，註釋不是作業系統那hostname，純粹是為了在頁面上好顯示，以及後期多個物理機實驗的時候好區分不同物理機器，所以自定義了一個臨時名稱。它對應docker-compose.yml中的MY_HOST環境變數，會通過docker容器傳遞到helloworld的執行環境中。

要停止服務Ctrl + C就行了，如果有些沒有停止，則

$ docker-compose down

如果要在後臺執行

$ docker-compose up -d

3.3 負載均衡

回到正題，在瀏覽器上多次重新整理，可以看到後端地址沒有變化，這是因為只有一個 web 後端伺服器。

如果要測試一下nginx負載均衡的效果，則調整後端為 3 個伺服器。先停掉服務，然後

$ docker-compose scale web=3
$ docker-compose up

再次訪問 http://localhost ，多次重新整理，可以看到頁面的實際目標地址發生了變化，有3個ip輪換。新啟動的 web 後端伺服器被自動註冊，並且 nginx 也把新的路由新增上了：

Hello World! I’m host-1 addr:172.17.0.2. I saw that you are 172.17.0.6:36710.
Hello World! I’m host-1 addr:172.17.0.3. I saw that you are 172.17.0.6:35210.
Hello World! I’m host-1 addr:172.17.0.4. I saw that you are 172.17.0.6:58678.

3.4 檢視服務狀態

consul ui

點選SERVICES這個按鈕，列出所有被註冊的服務。

consul server，看到有多個是因為監聽多個埠，還有udp埠的。
my-web-server就是後端web服務，這個名稱是要在docker-compose模板中設定SERVICE_80_NAME這個變數的，針對80埠，詳情見registrator 使用者指導手冊
https://gliderlabs.com/registrator/latest/user/services/。
nginx-consul-template就是nginx和consul-template的合體服務。

點選my-web-server，可以看到它右側的服務節點數，這裡只有一個，有多個的話會依次列出

host-1 my-web-server

4. 兩臺物理機

以上都是在單臺物理機上完成的，下面我們要測試下多臺物理機情況下，真正分散式的效果。

host name	real ip	services
host-1	10.111.152.136	registrator、helloworld、consul-server、consul-template、nginx
host-2	10.111.152.135	registrator、helloworld

第一臺物理機host-1的docker-compse.yml

#backend web application, scale this with docker-compose scale web=3
web:
  image: liberalman/helloworld:latest
  environment:
    SERVICE_80_NAME: my-web-server
    SERVICE_TAGS: backend-1
    MY_HOST: host-1
  ports:
  - "80"

#load balancer will automatically update the config using consul-template
lb:
  image: liberalman/nginx-consul-template:latest
  hostname: lb
  links:
  - consulserver:consul
  ports:
  - "80:80"

consulserver:
  image: progrium/consul:latest
  environment:
    SERVICE_TAGS: consul servers
  hostname: consulserver-node1
  ports:
  - "8300"
  - "8400"
  - "8500:8500"
  - "53"
  command: -server -ui-dir /ui -data-dir /tmp/consul -bootstrap-expect 1

# listen on local docker sock to register the container with public ports to the consul service
registrator:
  image: gliderlabs/registrator:master
  hostname: registrator-1
  volumes:
  - "/var/run/docker.sock:/tmp/docker.sock"
  command: -ip=10.111.152.136 consul://10.111.152.136:8500

我們第二臺機器host-2的yml檔案：

#backend web application, scale this with docker-compose scale web=3
web:
  image: liberalman/helloworld:latest
  environment:
    SERVICE_80_NAME: my-web-server
    SERVICE_TAGS: backend-2
    MY_HOST: host-2
  ports:
  - "80"

# listen on local docker sock to register the container with public ports to the consul service
registrator:
  image: gliderlabs/registrator:master
  hostname: registrator-2
  volumes:
  - "/var/run/docker.sock:/tmp/docker.sock"
  command: -ip 10.111.152.135 consul://10.111.152.136:8500

這是我們將MY_HOST改為host-2了，以便在頁面檢視的時候可以直觀看到。另外的重要改變就是registrator的啟動引數，我們去掉了上報docker內部ip的-internal，轉而使用了外部ip，將自己本機的ip 10.111.152.135上報了。同時要訪問的consul伺服器引數配置成host-1的ip地址 10.111.152.136。還有registrator的hostname要和第一臺機器的區別開，我改成registrator-2了，這樣在註冊到consul中的時候，不會覆蓋掉。hostname一樣consul無法區分是哪個機器的，這樣兩個機器的registrator會相互覆蓋。

host-1啟動方式不變，我們現在到host-2上啟動，看看效果，是否新節點被加上了。

Hello World! I’m host-1 addr:172.17.0.2. I saw that you are 172.17.0.5:41464.

Hello World! I’m host-2 addr:172.17.0.2. I saw that you are 10.111.152.136:41578.

重新整理兩次，發現一會兒是host-1，一會兒是host-2，說明我們host-2物理機上的服務被新增進來了，並且被nginx路由到了。

同時consul ui，看到新的節點果然被新增上了

host-2 my-web-server

不過發現個問題，如果在host-2上先將registrator關閉，再關閉host-2上的後端web，我們的consul伺服器可以感知到，但是那個consul ui介面沒更新，依然顯示兩個節點。

5. Consul Cluster

以上我們的實驗其實是個單點的consul服務，點選consul ui頁面的NODES按鈕可以看到

single node

只有一個consul server節點，也就是在我們host-1上跑的節點consulserver，另外一個物理機上沒有執行consul節點。一旦它掛了整個服務註冊功能就歇菜了。既然是分散式，一定要發揮叢集的優勢以解決單點問題。所以，我們要建立Consul Cluster。

在Consul方案中，每個提供服務的節點上都要部署和執行一個agent，所有執行Consul agent節點的集合構成Consul Cluster。

Consul agent有兩種執行模式：Server和Client。這裡的Server和Client只是Consul叢集層面的區分，與搭建在Cluster之上的應用服務無關。

以Server模式執行的Consul agent節點用於維護Consul叢集的狀態，官方建議每個Consul Cluster至少有3個或以上的執行在Server mode的Agent，Client節點不限。

這裡寫圖片描述

每個資料中心的Consul Cluster都會在運行於server模式下的agent節點中選出一個Leader節點，這個選舉過程通過Consul實現的raft協議保證，多個 server節點上的Consul資料資訊是強一致的。處於client mode的Consul agent節點比較簡單，無狀態，僅僅負責將請求轉發給Server agent節點。

我們這次的架構有些調整，繪製一個伺服器的邏輯上的部署圖來說明下

Services register adn find, consul cluster

這是一張邏輯上服務部署的圖，我們找3臺機器來實驗。每臺機器上部署幾個web server，一個registrator和一個consul client，這是基本需求。另外再建立一個consul cluster叢集，用來當我們的註冊中心。當web server啟動後，被registrator感知，進而將註冊資訊傳送給consul client，consul client則訪問註冊中心的leader節點，上報新加入的服務資訊。consul cluster會將新的服務資訊推送給已經到它這裡訂閱了服務訊息的consul-template，consul-template再去修改和自己同一臺機器上的nginx，以達到動態調整負載均衡的目的。

注意：由於資源有限，我們沒有單獨使用機器去搭建consul叢集，所以圖中的consul client和consul server節點其實是同一個節點，因為server模式同時可以提供client的功能嘛。那個consul cluster叢集其實是分佈到3個host中建立起來的，我們就在3個host中分別啟動一個consul程序，每個都同時擔任server和client的功能。

5.1 配置

host name	real ip	services	note
host-1	10.111.152.136	registrator、helloworld*n、consul-server、consul-template、nginx	放置consol web ui和nginx負載均衡
host-2	10.111.152.135	registrator、helloworld*n、consul-server
host-3	相關推薦微服務註冊發現叢集搭建——Registrator + Consul + Consul-template + nginx 在網際網路應用領域，服務的動態性需求十分常見，這就對服務的自動發現和可動態擴充套件提出了很高的要求。微服務系統動輒上萬個服務，而且還要動態伸縮。以人工寫好的IP、Port 硬編碼指令碼的方式無法做到大規模自動化，稍微多點服務運維就傻了。微服務必然要做到ip和p 小白入門微服務(5) - 服務註冊發現實戰(docker+registrator+consul+nodejs+python) 概述前言原始碼 registrator API gateway web 服務執行後記前言這篇文章真是等了挺久才寫，讓小夥伴們久等了。這篇文章旨在帶你走一下微服務的流程，真實的微服務遠不止這些東西。詳細的介紹敬請關注 SpringCloud服務註冊中心叢集搭建（二） springcloud學習總結 2、服務註冊中心叢集搭建一、新建服務註冊中心eureka7002模組，拷貝eureka7001模組的pom以及yml 修改yml檔案 server: port: 7002 eureka: instance: hos 白話講解微服務註冊發現及負載均衡一、公益圖書館例子筆者不想直接用專業的術語來說明“微服務註冊與發現”，所以我們來看生活中的一個案例：“公益圖書館”。隨著人們生活水平的不斷提高，追求精神食糧的朋友也越來越多。筆者曾經在一些城市看見過公益圖書館，其執行邏輯是：一些公益組織和個人提供一塊場所，然後由組織內的人向圖書館內捐書。捐出的書越多，一微服務之:從零搭建ocelot閘道器和consul叢集介紹微服務中有關鍵的幾項技術，其中閘道器和服務服務發現，服務註冊相輔相成。首先解釋幾個本次教程中需要的術語閘道器 Gateway（API GW / API 閘道器），顧名思義，是企業 IT 在系統邊界上提供給外部訪問內部介面服務的統一入口，簡化了外部由於多服務協同完成微服務學習筆記（2）——使用Consul 實現 MagicOnion(GRpc) 服務註冊和發現我會 names uid red mes tar art ret public 原文:微服務學習筆記（2）——使用Consul 實現 MagicOnion(GRpc) 服務註冊和發現1.下載打開Consul 筆者是windows下面開發的（也可以使用Docker）。官 .Net Core微服務入門全紀錄（二）——Consul-服務註冊與發現（上） # 前言上一篇【[.Net Core微服務入門全紀錄（一）——專案搭建](https://www.cnblogs.com/xhznl/p/13071260.html)】講到要做到服務的靈活伸縮，那麼需要有一種機制來實現它，這個機制就是服務註冊與發現。當然這也並不是必要的，如果你的服務例項很少，並且很穩定，那 .Net Core微服務入門全紀錄（三）——Consul-服務註冊與發現（下） # 前言上一篇【[.Net Core微服務入門全紀錄（二）——Consul-服務註冊與發現（上）](https://www.cnblogs.com/xhznl/p/13091750.html)】已經成功將我們的服務註冊到Consul中，接下來就該客戶端通過Consul去做服務發現了。 # 服務發現 - 同從零開始搭建系統3.2——微服務註冊中心開發及部署註冊 cnblogs 開始 htm www post 服務註冊 logs get 從零開始搭建系統3.2——微服務註冊中心開發及部署從零開始搭建系統3.2——微服務註冊中心開發及部署《SpringCloud與Docker微服務架構實戰》第四五六章服務註冊發現與呼叫 Spring Cloud實戰(一)：微服務註冊與微服務發現沒有Spring Cloud，Spring Boot的實用性要大打折扣。單個微服務雖然開發簡單、維護方便，但是沒有協作功能的微服務，其實在企業裡並沒有顯著的競爭力，跟NodeJS比起來，JAVA開發微服務並沒有多大的優勢。但是有了Spring Cloud，將多個微 spring cloud系列教程（4）--eureka註冊中心叢集配置，微服務註冊資訊完善給大家推薦個靠譜的公眾號程式設計師探索之路，大家一起加油 1.Eureka是什麼 Eureka是Netflix的一個子模組之一，AP設計原則。Eureka是一個以及Rest的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。服務註冊與發現對於微服務架構來微服務之:從零搭建ocelot網關和consul集群分享 p地址 node response sin internet server2 ont opp 原文:微服務之:從零搭建ocelot網關和consul集群介紹微服務中有關鍵的幾項技術，其中網關和服務服務發現，服務註冊相輔相成。首先解釋幾個本次教程中需要微服務註冊與發現 —— eureka 微服務　　在微服務系統中，服務的註冊和發現是第一步，常用的有：　　　　Eureka：https://github.com/Netflix/eureka 　　　　Zookeeper：https://zookeeper.apache.org/ 　　　　Consul：https://www.consul 微服務註冊與發現目錄簡介實現服務註冊元件設計服務登錄檔資料結構搭建應用程式框架定義服務登錄檔介面使用 ZooKeeper 實現服務註冊服務註冊模式實現服務發現元件搭建應用程式框架實現服務發現服務發現優化方 SpringCloud 使用consul作為微服務註冊中心 eureka宣佈閉源，使用consul作為服務註冊中心。 1、parent pom檔案 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" 搭建SpringCloud微服務註冊中心詳解我們在使用SpringCloud微服務的時候，首先要建立一個服務註冊中心，什麼是服務註冊中心呢，就好比老師手上的一張同學名單，上面寫著所有的同學名字和座位等資訊。廢話不多說，下面我們來做微服務的第一步：搭建註冊中心。我們用開發工具idea進行搭建。第一步：File-New-P 微服務-註冊與發現-zookeeper bydasn cfg stop col serve das 說明 java語言開發 dir net 目錄一、微服務註冊的概述二、zookeeper2.1 zookeeper基本操作2.2 zookeeper集群搭建一、微服務註冊概述在微服務中，有這麽一個東西叫服務註冊發現、配置中心集一體的 Spring Cloud Consul 前面講了 Eureka 和 Spring Cloud Config，今天介紹一個全能選手「Consul」。它是 HashiCorp 公司推出，用於提供服務發現和服務配置的工具。用 go 語言開發，具有很好的可移植性。被 Spring Cloud 納入其中，Eureka 停止新版本開發，更多的想讓開發者使用 ASP.NET Core gRPC 使用 Consul 服務註冊發現一. 前言 gRPC 在當前最常見的應用就是在微服務場景中，所以不可避免的會有服務註冊與發現問題，我們使用gRPC實現的服務可以使用 Consul 或者 etcd 作為服務註冊與發現中心，本文主要介紹Consul。二. Consul 介紹 Consul是一種服務網路解決方案，可跨任何執行平臺以及公共或私有云搜尋基礎教學 Mysql入門 Sql入門 Android入門 Docker入門 Go語言入門 Ruby程式入門 Python入門 Python進階 Django入門 Python爬蟲入門最近訪問首頁前端設計程式設計免費資源實用技巧資料庫資訊字典 Copyright © 2002-2020 程式人生 796T.COM All rights reserved.

微服務註冊發現叢集搭建——Registrator + Consul + Consul-template + nginx