微服务架构涉及许多可能具有分层依赖关系的服务。例如，服务 A 依赖于服务 B，而服务 B 又依赖于服务 C，依此类推。同样，每个服务可能有多个实例，并且它们的部署位置可能会动态变化。例如，服务 C 的点击次数过多，您可以动态扩展/缩减此服务。
通常，最终用户无法直接访问这些微服务中的任何一个。它只能通过位置固定的边缘服务访问，例如 www.microservice.com/apis，并将负责进行身份验证、速率限制等。因此，所有服务调用都将通过边缘服务并加载此阶段的平衡主要使用硬件负载平衡器或 Amazon ELB 来实现。
现在，假设用户想要访问服务 A。他必须通过边缘服务，将请求委托给服务 A。服务 A 必须调用服务 B 以获取一些信息。在这种情况下，服务 A 是服务 B 的客户端，服务 A 需要找到 B 的所有可用实例，然后调用这些实例之一。这就是像Consul、Eureka等微服务注册表出现的地方。每个服务实例都会不断地向注册表更新其状态（IP、端口、启动/关闭等）。边缘服务还将使用此注册表来查找服务 A 的实例位置。
服务 A 还应确保对服务 B 的所有调用都是负载平衡的。在这里使用 ELB 进行负载均衡是不可行的，因为这意味着如果您有 50 个服务，则需要有 50 个 ELB。有一些软件负载平衡器可以更有效地做到这一点。例如：Ribbon是一个很好的 Http 客户端库，具有用 Java 编写的负载平衡器支持。