背景
假設你采用了客戶端服務發現或者服務端服務發現，服務啟動時需要向注冊中心注冊實例，在關閉時向注冊中心注銷，以便其他服務感知。
問題
服務實例如何向注冊中心注冊或注銷？
考慮因素
- 服務在啟動時必須向注冊中心注冊實例，並且在關閉時在注冊中心注銷實例
- 必須從注冊中心注銷崩潰的服務實例
- 正在運行但是無法正常提供服務的實例，也需要在注冊中心注銷
解決方案
服務實例負責在注冊中心注冊自己。在啟動時，服務實例向服務注冊中心注冊自己(主機和IP地址)，使自己可以被發現。客戶端通常必須定期發送心跳，以便注冊中心知道它仍在運行。在關閉時，服務實例從注冊中心注銷自己。
一般微服務基礎框架都會有這個機制。
舉例
我們用 Scala 編寫一個例子，使用 SpringBoot 和 SpringCloud 作為微服務框架，以 Netflix Eureka服務注冊中心。在@Configuration Spring 框架配置類上使用@EnableEurekaClient 這個注解，將會讓實例在啟動后注冊到 Eureka 上面
@Configuration
@EnableEurekaClient
class EurekaClientConfiguration {
復制代碼結果分析
自注冊這個設計模式的好處有：
- 服務實例知道自己真正的狀態，所以可以實現相對於僅 UP/DOWN 這兩種狀態來說更加復雜的狀態機制，例如：STARTING、AVAILABLE 等等
這種設計也有一些不好的地方需要小心考慮予以避免：
- 與注冊中心耦合，換一個注冊中心就要寫新的實現
- 如果你的微服務系統中不同的微服務使用了不同的編程語言或者框架體系，那么針對這些都需要實現統一的注冊邏輯。
- 運行的但是無法正常處理請求的實例，一般無法自己感知到，從而在注冊中心自行注銷。
相關模式
- 注冊中心 - 服務發現的核心
- 客戶端服務發現 與 服務端服務發現
- 微服務基礎框架 - 一般微服務基礎框架都有自注冊的功能實現
- 第三方注冊 - 另一種可替代的設計模式