由於Spring Cloud對Etcd的支持一直沒能從孵化器中出來，所以目前來說大多用戶還在使用Eureka和Consul，之前又因爲Eureka 2.0不在開源的消息，外加一些博眼球的標題黨媒體使得Eureka的用戶有所減少，所以，相信在選擇Spring Cloud的用戶羣體中，應該有不少用戶會選擇Consul來做服務註冊與發現。
本文就來說一下，當我們使用Spring Cloud最新的Finchley版 + Consul 1.2.x時候最嚴重的一個坑：多實例註冊的問題。
問題解讀
問題：該問題可能在開發階段不一定會發現，但是在線上部署多實例的時候，將會發現Consul中只有一個實例。
原因：造成該問題的主要原因是Spring Cloud Consul在註冊的時候實例名（InstanceId）採用了：“服務名-端口號”（即：{spring.application.name}-{server.port}）的值，可以看到這個實例名如果不改變端口號的情況下，實例名都是相同的。如果熟悉Spring Cloud Consul的讀者，可能會問老版本也是這個規則，怎麼沒有這個問題呢？。主要是由於Consul對實例唯一性的判斷標準也有改變，在老版本的Consul中，對於實例名相同，但是服務地址不同，依然會認爲是不同的實例。在Consul 1.2.x中，服務實例名成爲了集羣中的唯一標識，所以，也就導致了上述問題。
解決方法
既然知道了原因，那麼我們要解決它就可以有的放矢了。下面就來介紹兩個具體的解決方式：
方法一：通過配置屬性指定新的規則
下面舉個例子，通過spring.cloud.consul.discovery.instance-id參數直接來配置實例命名規則。這裏比較粗暴的通過隨機數來一起組織實例名。當然這樣的組織方式並不好，因爲隨機數依然有衝突的可能，所以您還可以用更負責的規則來進行組織實例名。
spring.cloud.consul.discovery.instance-id=${spring.application.name}-${random.int[10000,99999]}
方法二：通過擴展ConsulServiceRegistry來重設實例名
由於通過配置屬性的方式對於定義實例名的能力有限，所以我們希望可以用更靈活的方式來定義。這時候我們就可以通過重寫ConsulServiceRegistry的register方法來修改。比如下面的實現：
public class MyConsulServiceRegistry extends ConsulServiceRegistry {
public MyConsulServiceRegistry(ConsulClient client, ConsulDiscoveryProperties properties, TtlScheduler ttlScheduler, HeartbeatProperties heartbeatProperties) {
super(client, properties, ttlScheduler, heartbeatProperties);
}
[@Override](https://my.oschina.net/u/1162528)
public void register(ConsulRegistration reg) {
reg.getService().setId(reg.getService().getName() + “-” + reg.getService().getAddress() + “-” + reg.getService().getPort());
super.register(reg);
}
}
上面通過拼接“服務名”-“ip地址”-“端口號”的方式，構造了一個絕對唯一的實例名，這樣就可以讓每個服務實例都能正確的註冊到Consul上了。