由於采用的是多server的註冊方式，存在壹個問題，當我們向consul集群的壹個agent註冊服務的時候，會出現相同的instanceid會在不同的節點上重復註冊。這就是壹個大坑了，這意味著有多少個節點就有可能出現多少個重復的服務實例。當然實際上需要用到的只有壹個，那意味著多余的實例需要刪除，但真實操作起來就沒有想象中那麽簡單了。
consul的官方文檔上有這麽壹段描述：
The agent is responsible for managing the status of its local services, and for sending updates about its local services to the servers to keep the global catalog in sync.
大致的意思是每個agent都維護著其自己節點上註冊的服務，並將其發送到其他的服務上使其在全局的catlog上同步。
這意味著其實每個agent維護的都是自己節點註冊的服務，當同壹個servername和instanceid在不同節點上進行註冊的時候會被認為是不同的服務，而不是想當然的認為每個instanceid都是唯壹的，當重復註冊的時候會進行覆蓋，實際上consul集群不是這麽處理的。只有當在同壹個節點註冊的時候才會出現覆蓋操作。這描述真的是很隱晦，就不能直白壹點嘛，關鍵網上找不到什麽相關的資料，全靠意會，真的是非常坑爹！
所以consul其實提供了兩個註冊的接口，/agent/service/register和/catlog/register，其需要的參數都是不壹樣的，具體的可以去看下consul的文檔。
這個想法沒問題，但實際操作起來是壹堆的坑。
首先來看下consul提供的刪除服務的API接口
1、/agent/service/deregister/:service_id
2、/catalog/deregister
第壹個看著沒啥問題，但是實際上是有問題的，由於考慮到高可用，在k8s裏面我們會用壹個service代理所有的所有的consul，所以是負載均衡的，這個接口實際上只會刪除當前consul server節點上的該服務，其他節點的是不會刪除的，所以這個接口不能直接使用
第二個接口看著就正常了，是通過catlog的方式進行刪除，調用之後確實把對應節點的服務刪掉了，正當妳暗自竊喜的時候，這個被刪除的服務過了壹會兒就又冒出來了，其實他只是刪除了緩存在catlog裏面的數據，真實節點上的服務並沒有刪除，過了壹會兒節點有把這個服務的信息同步上來了
我這時候已經想罵娘了，這不是個坑爹玩意兒嘛！！！！！直接刪的想法只能先放棄了，看看有沒有其他的方式來解決。
主要思路還是兩種：
1、多了就刪
在看了壹遍consul提供的接口之後我的第壹反應其實就是需要自己造輪子來解決了，其實通過consul提供的API接口確實也是可以解決的，具體的流程如下，如果妳真的最後只能通過這種方式來解決的話也可以借鑒壹下，邏輯其實也是比較簡單的
2、註冊之前先檢查
由於我使用的是springcloud，直接重寫註冊接口就完事兒
此方法有壹個局限性，由於是直接調用對應agent的接口進行服務的註銷，那就意味著該服務必須能直接訪問到agent，否則就無法實現。
如上文所說其實consul提供了兩個註冊的接口，默認使用的是/agent/service/register這個接口而沒有使用/catlog/register這個接口，由於時間問題我就沒有進行嘗試，後續有時間的話會測試壹下通過catlog的接口是否就不會存在這個問題。