feat: As a user, I want the consul plug-in to call the serviceID of the health api for deduplication.

[theweakgod]

Description

According to member blake of consul, the best way to implement consul is to register it on each node, but apisix starts from the api: v1/health/checks/ takes serviceID to get the data of each node, so there will be duplicate data here, for example

[{"Node":"consul-01","CheckID":"service:192.168.11.2:8001","Name":"Service 'test' check","Status":"passing","Notes": "","Output":"TCP connect 192.168.11.2:8001: Success","ServiceID":"192.168.11.2:8001","ServiceName":"test","ServiceTags":[],"Type": "tcp","Interval":"5s","Timeout":"5s","ExposedPort":0,"Definition":{},"CreateIndex":12014,"ModifyIndex":12015},{"Node" :"consul-03","CheckID":"service:192.168.11.2:8001","Name":"Service 'test' check","Status":"passing","Notes":"","Output ":"TCP connect 192.168.11.2:8001: Success","ServiceID":"192.168.11.2:8001","ServiceName":"test","ServiceTags":[],"Type":"tcp"," Interval":"5s","Timeout":"5s","ExposedPort":0,"Definition":{},"CreateIndex":10366,"ModifyIndex":12020}]

If node A is registered but node B is not, then the serviceID obtained by apisix will not be balanced, and the weight of the serviceID will be offset, but the user does not know it. So, I want to deduplicate serviceID

By the way, I want to add a scheduling based on the minimum IP load. I still use roundrobin, but when polling the upstream, the polling is based on the minimum IP schedule, because we currently encounter a scenario where one machine has multiple service, but at a certain point in time, many requests hit the machine at the same time, causing the CPU to skyrocket. We hope to design an optional plug-in parameter. If this parameter is selected, the IP will be sorted first, and then the port will be sorted.

[theweakgod]

I can handle this. What do u think of this design? @shreemaan-abhishek @monkeyDluffy6017

[shreemaan-abhishek]

then the serviceID obtained by apisix will not be balanced

what do you mean by this?

The consul deployment architecture suggested by the official documentation can still be followed when using with APISIX, isn't it? Then I don't understand why we would need this feature. Unless the user deploys/configures consul inappropriately.

[theweakgod]

then the serviceID obtained by apisix will not be balanced

what do you mean by this?

The consul deployment architecture suggested by the official documentation can still be followed when using with APISIX, isn't it? Then I don't understand why we would need this feature. Unless the user deploys/configures consul inappropriately.

apisix will get duplicate serviceIDs. I don’t think it should get duplicate serviceIDs.

[theweakgod]

then the serviceID obtained by apisix will not be balanced

what do you mean by this?

The consul deployment architecture suggested by the official documentation can still be followed when using with APISIX, isn't it? Then I don't understand why we would need this feature. Unless the user deploys/configures consul inappropriately.

The problem occurs exactly as per the official configuration. The Service Registration data for each node in Consul does not synchronize, requiring services to register on each node. However, the Service Registration data that APISIX retrieves from Consul is the sum of the Service Registration data for each node in Consul. This can lead to duplicate data.

The duplicate Service IDs may appear in a list as follows. For example, if I have three services (ABC) and three nodes (Nodes1, Nodes2, Nodes3), and I register the services on all three nodes, the APISIX service list might look like [A, B, C, C, B, A, A, B, C]. This may not result in a very effective round-robin, as there are instances of CC and AA.

[shreemaan-abhishek]

Okay I understand now. You may work on this if you want to.