我将在我的应用程序中实现一组微服务的编排。
这是一个很难自己解决的问题。使用现有的编排系统可能会更好（见下文）。
还有其他强大的工具吗？
你应该研究一下kubernetes，它似乎是当今编排的标准。它有许多额外的好处（支持可伸缩性、自我修复等），并且在当今的生产中被广泛使用。请参见以下链接：

• Kubernetes webpage
• Article

关于比较Zookeeper、Eureka 和Kubernetes：

• Zookeeper是一个分布式键值存储，可以作为实现服务发现的基础（类似于etcd）。
• Eureka主要是一个服务定位器，用作Netflixes负载平衡器和故障转移的一部分（允许找到正确的服务目标，以便将客户端调用分发到应用程序集群的成员）。
• Kubernetes是一个容器编排解决方案，包括服务的部署、发现和自我修复。有关功能的完整列表，请查看上面的链接。kubernetes中的服务发现基于虚拟网络中的dns，并基于etcd构建。
• Consul（在另一个答案中提到）是一个服务发现框架，具有REST接口和一些附加功能（运行状况检查、服务分段等）。它有自己的内部分布式键值存储，也可以使用。

另一个工具可能是Consul。
Eureka 主要是一个服务发现工具，主要设计用于AWS基础设施内部。
Zookeeper是一种通用的分布式键/值存储，可与curator-x-discovery framework结合用于服务发现
下面是一个简短的overview of service-discovery solutions
您也可以在这里找到Consul vs Eureka vs Zookeeper的比较。
尽管Consul与Zookeeper一样出色-不仅可用于发现，还可用作密钥/价值存储，但Consul的优势是开箱即用的出色服务发现功能
1.开箱即用的DNS
1.方便REST风格API
1.开箱即用的运行状况检查API
同样执政官也具有更分散的性质：代理安装在所有服务虚拟机上，因此系统的可用性高于zookeeper。请注意，consult系统具有low coupling between datacenters。
Zookeeper已经很成熟了，但是过于通用。因此，您不仅可以使用Zookeeper进行服务发现，还可以使用它来存储配置、分布式锁、通知等。同样，使用Curator Framework / Curator Recipes可以方便地使用所有这些功能。
Zookeeper正在群集中的节点之间使用主/从通信架构。主节点由群集成员选举。请注意，当群集中出现多个主节点时，可能会出现边缘情况（例如由于网络问题）。在这种情况下，重新启动群集会有所帮助。
Eureka 与Zookeeper和Consul的不同之处在于Eureka是一个狭义的系统--服务发现和负载均衡系统。
所有3个系统都可以与Spring集成。