我认为“编排”一词不符合您的要求。从我目前在微服务领域所遇到的情况来看，当涉及复杂的业务流程而不是服务发现时使用术语“编排”。您需要的是 Service registry 与 Load balancer 的组合。您可以找到here 您需要的所有信息。以下是这篇精彩文章的一些相关附加内容：
有两种主要的服务发现模式：客户端发现和服务器端发现。我们先来看看客户端发现。
客户端发现模式
当使用客户端发现时，客户端负责确定可用服务实例的网络位置以及它们之间的负载平衡请求。客户端查询服务注册表，它是可用服务实例的数据库。然后客户端使用负载平衡算法来选择一个可用的服务实例并发出请求。
服务实例的网络位置在启动时向服务注册表注册。当实例终止时，它会从服务注册表中删除。服务实例的注册通常使用心跳机制定期刷新。
Netflix OSS 提供了一个很好的客户端发现模式示例。 Netflix Eureka 是一个服务注册中心。它提供了一个 REST API 来管理服务实例注册和查询可用实例。 Netflix Ribbon 是一个 IPC 客户端，它与 Eureka 一起在可用服务实例之间对请求进行负载平衡。我们将在本文后面更深入地讨论 Eureka。
客户端发现模式有很多优点和缺点。这种模式相对简单，除了服务注册表之外，没有其他活动部分。此外，由于客户端知道可用的服务实例，它可以做出智能的、特定于应用程序的负载平衡决策，例如一致地使用散列。这种模式的一个重要缺点是它将客户端与服务注册表耦合在一起。您必须为服务客户端使用的每种编程语言和框架实现客户端服务发现逻辑。
服务器端发现模式
客户端通过负载均衡器向服务发出请求。负载均衡器查询服务注册表并将每个请求路由到可用的服务实例。与客户端发现一样，服务实例在服务注册表中注册和注销。
AWS Elastic Load Balancer (ELB) 是服务器端发现路由器的示例。 ELB 通常用于负载平衡来自 Internet 的外部流量。但是，您也可以使用 ELB 对虚拟私有云 (VPC) 内部的流量进行负载平衡。客户端使用其 DNS 名称通过 ELB 发出请求（HTTP 或 TCP）。 ELB 负载平衡一组已注册的弹性计算云 (EC2) 实例或 EC2 容器服务 (ECS) 容器之间的流量。没有单独的服务注册表。相反，EC2 实例和 ECS 容器注册到 ELB 本身。
HTTP 服务器和负载平衡器（例如 NGINX Plus 和 NGINX）也可以用作服务器端发现负载平衡器。例如，this blog 帖子描述了使用 Consul Template 动态重新配置 NGINX 反向代理。 Consul Template 是一个工具，它可以从Consul service registry 中存储的配置数据中定期重新生成任意配置文件。每当文件更改时，它都会运行任意 shell 命令。在博客文章描述的示例中，Consul Template 生成一个 nginx.conf 文件，该文件配置反向代理，然后运行一个命令告诉 NGINX 重新加载配置。更复杂的实现可以使用 its HTTP API or DNS 动态重新配置 NGINX Plus。
Kubernetes 和 Marathon 等一些部署环境在集群中的每个主机上运行一个代理。代理扮演服务器端发现负载平衡器的角色。为了向服务发出请求，客户端使用主机的 IP 地址和服务分配的端口通过代理路由请求。然后，代理将请求透明地转发到集群中某处运行的可用服务实例。
服务器端发现模式有几个优点和缺点。这种模式的一大好处是发现的细节从客户端抽象出来。客户端只需向负载均衡器发出请求。这消除了为服务客户端使用的每种编程语言和框架实现发现逻辑的需要。此外，如上所述，某些部署环境免费提供此功能。然而，这种模式也有一些缺点。除非部署环境提供负载均衡器，否则它是另一个需要设置和管理的高可用性系统组件。