Docker Swarm叢集中的服務發現

banq發表於2016-09-20
DockerSwarm
在舊版本Swarm中需要一個服務註冊器，這樣所有管理者能有一個統一的叢集狀態檢視，因此，在初始化老版本Swarm節點時，我們需要指定服務註冊器的地址，而在新版本Swarm中，也就是Docker 1.12引入的Swarm Mode，除了Docker引擎以外什麼都不需要，無需額外的服務註冊器或key-value儲存庫。

是不是Swarm不需要服務發現嗎?正好相反，服務發現很重要，因此被放入Docker引擎中，Docker引擎現在扮演Swarm 管理器，Swarm工作器和服務註冊器三個角色。Docker Swam Mode一個巨大進步。引擎內部服務註冊器只能提供給內部使用者使用。

只要所有服務在同樣網路中彼此通訊，我們所需要做的是對目標服務進行命名，比如所有go-demo服務需要知道如何發現相關的資料庫，那麼這個目標資料庫的DNS是go-demo-db。

在Swarm叢集情況下(Docker Swarm)，好像擴充套件一個服務非常方便，只要執行:
docker service scale SERVICE_NAME=NUMBER_OF_INSTANCES
這樣，這個服務就會執行在多個自身複製。也即是在叢集多個節點上執行。其實這種方便擴充套件只能說擴充套件無態服務很容易，因為服務沒有狀態，在哪個節點上執行都沒有問題。

但是世界並不是無態的，狀態在工程產品業界是無法避免的，狀態被建立就要儲存，儲存狀態的地方就變成有態了，狀態還會經常變化，擴充套件有態服務需要考慮：
1.我們如何傳播一個服務例項狀態的變化給其他的同樣的有態服務？
2.我們如何建立有狀態的服務一個副本（一個新服務例項），確保狀態複製準確？

我們通常混合無態和有態服務到一個邏輯實體，後端服務能夠是無態的，依賴資料庫服務作為外部狀態儲存，在這種情況下，這些服務在不同生命週期上有一個清晰的分離關注。

以前我們都認為使得有態服務擴充套件和容錯是沒有銀彈的，我們看看Docker Flow:Proxy是如何處理有態服務的，其核心HAProxy就是一個有態服務，從配置檔案載入配置到記憶體，在動態叢集中包含有態服務是一個挑戰，因為我們不知道有多少個有態服務例項在執行，以及執行在哪個節點上。這時我們首先需要儲存有態服務例項的狀態，Docker Flow將有態服務狀態複製儲存在Consul，Consul這是一個分散式資料庫。這樣解決了狀態改變的廣播問題和有態服務例項的狀態複製問題。

Service Discovery Inside A Docker Swarm Cluster |

[該貼被banq於2016-09-20 10:04修改過]

相關文章