我们计划基于play框架开发一些微服务。他们将提供其余的api,其中许多将在后台使用akka群集/群集分片。
我们希望拥有一个公开我们内部服务的api的api网关,但是我们面临着一个大问题:
-每个服务的多个实例将在某些ip和端口下运行。
-api网关如何知道服务实例在哪里运行?
-也许有类似负载平衡器的玩法可以跟踪所有正在运行的服务?
哪种解决方案可能会填补“ API网关” /“负载均衡器”的空白?
答案 0 :(得分:1)
您要问的问题与游戏框架并没有真正的关系。而且没有一个单一的答案可以解决您的需求。
您可以先阅读阿卡语Service Discovery,然后再根据自己的情况做出选择。
我们正在使用akka-http
构建服务并使用akka-cluster
,但是使用无关的技术来公开和运行服务。
退房
答案 1 :(得分:1)
您正在寻找以下组件,
服务注册表:此组件的全部目的是跟踪“哪些服务在哪些地址上运行”。这可以像保存所有正在运行的服务及其实例的条目的简单数据库一样简单。通常,业务流程服务负责向Service Registry注册新的服务实例。其他选择可以是让实例本身将其存在通知服务注册表。
服务运行状况检查器:该组件主要负责对已注册的服务实例进行定期运行时检查,并告知服务注册表是否其中任何一个不起作用。然后,服务注册表实现可以将这些实例标记为“非活动”,直到以后(如果有)Service Health Checker发现它们正在运行。
服务解决方案:这是概念性组件,负责使客户端能够以某种方式获取正在运行的服务实例。
以上所有组件均称为服务发现。
在您的情况下,您有load-balancers
可以用作ServiceDiscovery的一种形式。
除非您需要非常高级的体系结构,否则我认为load-balancers
不会随时间变化很大,因此您的API网关可以简单地“知道” URL到所有服务的负载均衡器。因此,您不需要确实需要服务注册表层。
现在,您的负载均衡器固有地为实例提供了运行状况检查和隔离机制。因此,您不需要额外的运行状况检查层。
因此,唯一缺少的就是向负载均衡器注册实例。您必须根据负载均衡器的种类以及它们所处的生态系统来确定这一部分。
如果您生活在AWS生态系统中,并且负载均衡器是ELB,那么您应该在这方面进行梳理。
答案 2 :(得分:0)
基于Ivan和Sarvesh的回答,我们进行了一些研究,发现了netflix OSS项目。 Eureka可以用作与Zuul api网关很好集成的服务定位器。遗憾的是,有关该配置的文档并不多,因此我们进行了进一步的研究……
我们现在终于选择了Kubernetes作为Orchestator。