当前位置: 首页 > 知识库问答 >
问题:

基于 Akka 集群的微服务 API 网关模式实现

糜帅
2023-03-14

我尝试基于Akka创建一些使用CQRS的微服务。所以我的微服务有Httpendpoint的写端(向集群发送命令)和读端(从数据库读取投影),但这不是主要问题。由于许多微服务,问题出现了为客户端收集复杂的API。我找到了答案:API网关模式。但我还有下一个问题:如何实现它?

> < li>

我可以创建单独的项目,该项目将实现API网关模式(在简单的情况下,它是一个反向代理)。完整堆栈将:

Load balancer     
  -> API Gateway project 
    -> Load balancer 
      -> Microcervice read part
        -> Database 
      -> Microcervice write part
        -> Akka cluster 

赞成的意见:

API网关独立项目,具有自己的抽象

缺点:

API Gateway项目中的两个平衡器和不那么快的代理

API网关(认证等)在微服务部分实现,负载平衡器将收集复杂API中的endpoint。完整堆栈将:

Load balancer
  -> Microcervice read part (with public API)
    -> Database 
  -> Microcervice write part (with public API)
    -> Akka cluster 

赞成的意见:

  1. 直接访问集群和数据库
  2. 快速响应

缺点:

复杂的微服务部件,混合层

哪个变体更可取或者是另一个最好的?

共有1个答案

袁高明
2023-03-14

查看Kong项目,在他们的github页面上有一个很好的图表,显示了你想如何考虑API网关。此外,您可能想考虑在您的实现中使用它们。

 类似资料:
  • 让我们说,我正在开发博客平台,用户可以注册帐户,支付订阅和创建自己的博客。平台由以下微服务组成: 帐户-服务 auth-service 订阅-服务 博客-服务 API-网关 我正在考虑实现api-gw模式,其中除了api-gw之外的所有微服务都将部署到专用网络中(在那里,它们将能够通过message broker直接以同步或异步方式相互通信),并且它们将只通过api-gw公开可用。 null 我的

  • 我正在使用Akka(特别是远程和集群包)构建一个开源的分布式经济模拟平台。这类仿真中的一个关键瓶颈是参与者之间的通信模式在仿真过程中不断演变,并且参与者最终通常会通过集群中节点之间的线路发送消息负载。 我正在寻找一种机制来检测某些节点上的参与者,这些参与者正在与其他节点上的参与者进行大量通信,并将它们移动到其他节点。是否可以使用现有的Akka集群分片功能?也许这就是罗兰·库恩所说的“自动演员树划分

  • 我们能在Spring Cloud API网关和没有服务发现的情况下生存吗?

  • 我正试图理解API网关和微服务聚合器模式之间的区别。 目前,从我对聚合器模式的理解来看,它是通过从各种微服务收集数据片段并返回一个聚合进行处理来实现的。 现在,API网关是聚合对单个微服务的调用的单一入口点。虽然这听起来可能与聚合器模式非常相似,但也有一些不同的特性。最重要的是,这个新服务不存储数据,而是负责API组合、请求路由和身份验证等新功能 我很想知道我的推理是否正确。 提前谢谢你!

  • 在微服务架构中,建议: > 客户端应用程序到API网关的通信应该是同步的(就像http上的REST一样)。 API网关到微服务的通信也应该是同步的 但是服务到服务的通信应该是异步的。 您应该尽可能遵循的另一个规则是,只使用内部服务之间的异步消息传递,只使用从客户端应用程序到前端服务(API网关加上第一级微服务)的同步通信(如HTTP)。 现在,如果我理解正确的话,当用户向API gateway请求

  • 我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处,比如:负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是,我应该在网关层还是在每个微服务endpoint单独实现授权?例如,在网关上验证用户,并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的,并且节省了处理时间。然而,授权逻辑实际上是单个服务