原文地址：https://microservices.io/patterns/self-registration.html
背景
假設你採用了客戶端服務發現或者服務端服務發現，服務啓動時需要向註冊中心註冊實例，在關閉時向註冊中心註銷，以便其他服務感知。
問題
服務實例如何向註冊中心註冊或註銷？
考慮因素
- 服務在啓動時必須向註冊中心註冊實例，並且在關閉時在註冊中心註銷實例
- 必須從註冊中心註銷崩潰的服務實例
- 正在運行但是無法正常提供服務的實例，也需要在註冊中心註銷
解決方案
引入一個第三方註冊代理，負責服務實例在服務註冊中心註冊和註銷。當服務實例啓動時，註冊代理將實例註冊到註冊中心。當服務實例關閉時，註冊代理負責註銷實例。
舉例
第三方註冊模式的例子包括：
- Netflix Prana，用於非 JVM 註冊到 Eureka 上，已不再更新，參考:Towards being better about open source personally
- AWS 自動擴容組，自動註冊 EC2 實例到 AWS 負載均衡器上。
- ContainerPilot，作爲服務的父進程在Docker容器中運行，並將其註冊到註冊中心中。
- Registrator，負責 Docker 容器向各種不同的註冊中心的註冊與註銷
- Kubernetes 和 Marathon這種容器編排框架的服務實例都有內置的隱式服務註冊
結果分析
第三方註冊模式的好處包括：
- 服務的代碼比使用自注冊模式更加簡單，因爲它不負責註冊
- 註冊代理可以對服務實例執行健康檢查，並根據健康狀態註冊/註銷實例。
也有一些缺點：
- 註冊代理只對服務實例的狀態有模糊的理解，例如只有 UP 和 DOWN，因此可能不知道它是否能夠正常處理請求。上面提到的 Netflix Prana 等一些 註冊代理 利用健康檢查，以確定服務實例的可用性。
- 需要額外維護一個 註冊代理 服務，而且需要高可用。
相關模式
- 註冊中心 - 服務發現的核心
- 客戶端服務發現 與 服務端服務發現
- 微服務基礎框架 - 一般微服務基礎框架都有自注冊的功能實現
- 自注冊 - 另一種可替代的設計模式