我想在新系统上使用微服务架构模式,但是在弄清楚服务彼此隔离时如何在服务之间共享和合并数据时遇到了麻烦。特别是,我正在考虑返回整合数据以通过HTTP填充Web应用程序UI。
就上下文而言,我打算将每个服务部署到其自己的隔离环境(Heroku)中,在该环境中我将无法在服务之间进行内部通信(例如,通过//localhost:PORT
。我计划使用RabbitMQ进行服务间通信,而Postgres则用于数据库。
服务的解耦对于CREATE操作很有意义:
UserId
的经过身份验证的用户在前端GroupJoinRequest
的新UserId
已添加到RabbitMQ队列Groups
服务获取事件并对其进行处理,并参考用户的UserId
但是,如果我想跨表/方案合并数据,则READ操作要困难得多。假设我想获取特定组中所有用户的详细信息。在单片设计中,我只是在Users和Groups表之间执行SQL
JOIN
,但是却失去了微服务的隔离优势。我的选择似乎如下:
每个服务的数据库,每个服务的 public API
要查看
Users
中的所有Group
,站点访问者将从Groups服务中获取与某个群组相关联的UserID
的列表,然后分别查询Users
服务以获取其名称。优点:
缺点:
每个服务数据库,服务通过HTTP,单个 public API共享数据
public API服务器处理请求端点。 API服务器中的应用程序逻辑通过HTTP通道向每个服务发出请求,而该请求只能由系统中的其他服务访问。
优点:
缺点:
每服务数据库,服务通过消息代理共享数据
鉴于我已经在运行RabbitMQ,我可以使用它对数据请求进行排队,然后发送数据本身。因此,例如:
GetUsersInGroup
的RequestID
事件Groups
服务将其提取出来,并将UserID
添加到队列RequestID
侦听事件,等待响应,将数据合并为正确的格式,然后发送回客户端优点:
缺点:
服务共享一个数据库,由模式分隔,其他服务则从
VIEW
中读取服务被隔离到数据库架构中。模式只能由其各自的服务写入。服务在其架构上公开一个SQL
VIEW
层,其他服务可以查询该层。VIEW
充当API合约;即使基础架构或服务应用程序逻辑发生更改,VIEW
也会公开相同的数据,因此优点:
缺点:
我倾向于最后一种选择,但是希望您对其他方法有任何想法。
最佳答案
为了评估优缺点,我认为您应该专注于微服务架构要实现的目标。在我看来,微服务是旨在构建松耦合应用程序的体系结构样式。它不是为构建高性能应用程序而设计的,因此当我们决定以微服务方式构建应用程序时,我们已经可以接受降低性能和减少数据冗余的问题。
我认为您的服务不应共享数据库。紧密的耦合消除了微服务架构的主要目标。我的建议是创建一个统一的数据服务,该服务将从所有其他服务中获取数据更改事件并更新其背后的数据库。您可能希望以一种针对查询优化的方式(例如数据仓库)设计合并数据服务背后的数据库,因为这将用于所有服务。您可能要考虑使用NoSQL数据库来支持您的统一数据服务。
关于web-services - 在隔离的微服务之间共享数据,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40422613/