當(dāng)我們在Spring Cloud應(yīng)用中使用Consul來實現(xiàn)服務(wù)治理時蜂大，由于Consul不會自動將不可用的服務(wù)實例注銷掉（deregister），這使得在實際使用過程中蝶怔，可能因為一些操作失誤奶浦、環(huán)境變更等原因讓Consul中存在一些無效實例信息，而這些實例在Consul中會長期存在踢星，并處于斷開狀態(tài)澳叉。它們雖然不會影響到正常的服務(wù)消費過程，但是它們會干擾我們的監(jiān)控沐悦，所以我們可以實現(xiàn)一個清理接口成洗，在確認(rèn)故障實例可以清理的時候進(jìn)行調(diào)用來將這些無效信息清理掉。
開始以為只要簡單的調(diào)用注銷接口就能輕松完成藏否，但是實際實踐的發(fā)現(xiàn)并非如此瓶殃。因此，分享一下整個實現(xiàn)過程以及中間遇到的一些坑秕岛。
借鑒Spring Cloud Consul
在實現(xiàn)之初碌燕，先參考了Spring Cloud Consul在關(guān)閉程序時候?qū)崿F(xiàn)的注銷方法，具體如下：
public class ConsulLifecycle extends AbstractDiscoveryLifecycle {
...
private void deregister(String serviceId) {
if (!this.properties.isRegister()) {
return;
}
if (ttlScheduler != null) {
ttlScheduler.remove(serviceId);
}
log.info("Deregistering service with consul: {}", serviceId);
client.agentServiceDeregister(serviceId);
}
...
}
我們可以看到继薛，當(dāng)應(yīng)用關(guān)閉時候的注銷操作是通過調(diào)用client.agentServiceDeregister(serviceId)來實現(xiàn)的修壕。其中client是consul-api的com.ecwid.consul.v1.ConsulClient實例。而agentServiceDeregister方法則是對/v1/agent/service/deregister/<serviceID> 接口的實現(xiàn)遏考，該接口主要用來從Consul Agent中根據(jù)serviceId來注銷實例慈鸠。
以此實現(xiàn)為范例，于是開始的思路是這樣的：
- 先通過
consulClient.getHealthServices(serviceId, false, null)根據(jù)serviceId來獲取服務(wù)實例清單 - 遍歷實例清單中有不是PASSING狀態(tài)的實例灌具，就調(diào)用
client.agentServiceDeregister(serviceId)來剔除
具體實現(xiàn)如下：
@RestController
public class ApiController {
@Autowired
private ConsulClient consulClient;
@RequestMapping(value = "/unregister/{id}", method = RequestMethod.POST)
public String unregisterServiceAll(@PathVariable String id) {
List<HealthService> response = consulClient.getHealthServices(id, false, null).getValue();
for(HealthService service : response) {
service.getChecks().forEach(check -> {
if(!check.getStatus().name().equals(Check.CheckStatus.PASSING.name())) {
logger.info("unregister : {}", check.getServiceId());
consulClient.agentServiceDeregister(check.getServiceId());
}
});
}
return null;
}
}
但是青团，在測試后發(fā)現(xiàn)該方法只能剔除同一個agent上的非PASSING實例。
Catalog誤區(qū)
繼續(xù)搜索了一下Consul的文檔咖楣，發(fā)現(xiàn)了這個接口：/v1/catalog/deregister : Deregisters a node, service, or check督笆。于是，嘗試了用該接口來替換之前的consulClient.agentServiceDeregister(check.getServiceId());實現(xiàn)诱贿。
CatalogDeregistration catalogDeregistration = new CatalogDeregistration();
catalogDeregistration.setDatacenter("dc1");
catalogDeregistration.setNode(check.getNode());
catalogDeregistration.setServiceId(check.getServiceId());
catalogDeregistration.setCheckId(check.getCheckId());
consulClient.catalogDeregister(catalogDeregistration);
經(jīng)過測試娃肿，該方法可以實現(xiàn)短暫的剔除，但是過一段時間之后這些被剔除的實例又都恢復(fù)回來了……也就是說這個接口完全沒有什么卵用珠十！
那么為什么會出現(xiàn)這種情況呢料扰？我們可以在Github中找到這個維持了一年多的問題討論：https://github.com/hashicorp/consul/issues/1188 。整個討論過程非常曲折焙蹭，雖然當(dāng)前該問題還依然在open狀態(tài)晒杈，但是一些回復(fù)也基本夠我們?nèi)ダ斫馑脑蛄恕１热缦旅孢@條評論：
You cannot deregister a service from the agent on a different node, service only exists on the agent you have registered with. It also exists in the catalog on all nodes, but that is not related to the agent itself. And to be honest I don't understand why there is a catalog/deregister endpoint at all, in my opinion catalog should be a read-only service list.
從該評論中孔厉，我們可以知道一個重要信息：服務(wù)實例只能在注冊的Agent上進(jìn)行注銷拯钻！另外帖努，對于/v1/catalog/deregister接口，目前還是有不少爭議的说庭，因為根本沒啥用然磷。
最終實現(xiàn)
既然服務(wù)實例只能在注冊的Agent上進(jìn)行注銷，那么我們的實現(xiàn)完全可以按照該思路來實現(xiàn)刊驴，方法很簡單，只需要對一開始實現(xiàn)的內(nèi)容做一些調(diào)整寡润，依然使用client.agentServiceDeregister(serviceId)方法捆憎，只是我們需要調(diào)整client連接的agent必須是serviceId注冊的agent。所以梭纹，最終的修改結(jié)果如下：
List<HealthService> response = consulClient.getHealthServices(id, false, null).getValue();
for(HealthService service : response) {
// 創(chuàng)建一個用來剔除無效實例的ConsulClient躲惰，連接到無效實例注冊的agent
ConsulClient clearClient = new ConsulClient(service.getNode().getAddress(), 8500);
service.getChecks().forEach(check -> {
if(check.getStatus() != Check.CheckStatus.PASSING) {
logger.info("unregister : {}", check.getServiceId());
clearClient.agentServiceDeregister(check.getServiceId());
}
});
}
