Service Mesh and Load balancing

Consul
1

Hello,

I got to read some about Service Mesh and about Consul Connect.
There is something I still did not figure out and I was hoping you can help me with that.

Lets say I got 3 instances of Service A and 3 instances of Service B.
If I create a simple service mesh for those, how do i do the “load balancing” part?
Since from my understanding unlike the regular discovery, here you got a proxy attached for each service.
So if I want to send a request from Service B Instance 2 to any of Service A instances, can I use a similar way to how regular discovery works in Consul? and get something like 3 randomized addresses to choose from?

Hope I managed to explain myself and thank you in advance!

2

Hi @kresa3333,

In a service mesh the load balancing is handled by the application’s sidecar proxy. The application does not need to perform any service discovery itself. That part is entirely offloaded to the proxy.

A list of endpoints for Service B will be programmed into Service A’s sidecar proxy. When Service A initiates a connection to its proxy to reach an upstream instance of Service B, the connection will be load balanced across one of the available upstream instances. By default, the algorithm used by Envoy is Weighted round robin.

See the Understand Consul Service Mesh for more information on Consul service mesh’s architecture.

I hope this helps. Let me know if you have any other questions.

3

Thank you for the reply!

So if I understand this correctly,
For every service which I attach a sidecar proxy to I will need to maintain the list of services which it needs to know about?
So if I need to add a new instance of service B then all the services who needs to be able to connect to this new service will need to add this new instance address to their sidecar proxy?

4

Hi,

You only need to declare upstream service dependencies in a service’s proxy registration.

For example, lets say we have a service called Dashboard which communicates with a backend service called Counting. You will first need to register the Dashboard service in Consul and declare Counting as an upstream dependency.

service {
  name = "dashboard"
  # Local port where Dashboard service is listening
  port = 9002

  connect {
    sidecar_service {
      proxy {
        upstreams = [
          {
            destination_name = "counting"
            # Local port where sidecar proxy receives connection
            # requests to route to any available instance of the
            # counting service
            local_bind_port  = 5000
          }
        ]
      }
    }
  }
}

When you add a new instance of Service B (in this example, counting) you will register this instance with Consul and also start the service’s sidecar proxy.

# Example counting service registration file
service {
  name = "counting"
  id = "counting"
  # The counting service is accessible by the proxy on port 9003
  port = 9003

  # This declares the counting service as being Connect-enabled.
  # It does not have any upstream dependencies itself.
  connect {
    sidecar_service {}
  }
}

$ consul services register counting.hcl
Registered service: counting

You will also start the service’s associated sidecar proxy.

consul connect envoy -sidecar-for=counting > counting-proxy.log &

(If you’re running in Kubernetes, the process of registering a service & starting its sidecar can be automated using annotations. See Connect Service Mesh on Kubernetes).

Once the new counting instance is registered and the sidecar is started, Consul will automatically notify the downstream services sidecar proxies of this new instance. No manual updates are necessary.

I hope this is a bit more clear. Check out Secure Service Communication with Consul Service Mesh and Envoy for a more complete guide which walks through this upstream & downstream service registration process.

1 Like