模式:每个服务一个数据库

2024-11-17  本文已影响0人  JavaEdge

Pattern: Database per service。

背景

如用微服务架构模式开发一个在线商店应用程序。大多数服务需要在某种数据库中持久化数据。如,订单服务存储订单信息,而客户服务存储客户信息。

img

问题

微服务应用程序中的数据库架构是什么?

驱动力

解决方案

让每个微服务的持久性数据对该服务私有,并仅通过其 API 访问。服务的事务只涉及其自己的数据库。
下图展示了这一模式的结构。


img

服务的数据库实际上是该服务实现的一部分。它不能被其他服务直接访问。

有几种方法可以让服务的持久性数据保持私有性。你不需要为每个服务配置一个独立的数据库服务器。例如,如果你使用的是关系型数据库,可以选择以下方式:

每服务私有表和每服务一个模式的实现开销最低。使用每服务一个模式较为吸引人,因为它可以更加清晰地划分所有权。一些高吞吐量服务可能需要独立的数据库服务器。

建议创建屏障以强制实现模块化。例如,可以为每个服务分配不同的数据库用户 ID,并通过数据库访问控制机制(如授权)来限制访问。如果没有这些强制手段,开发人员可能会直接绕过服务的 API 访问其数据。

示例

FTGO 应用程序 是一个使用这种方法的示例。每个服务都拥有数据库凭据,这些凭据仅允许其访问自己(逻辑)数据库的权限,数据库位于共享的 MySQL 服务器上。有关更多信息,请参阅这篇博客文章

结果情境

使用每个服务一个数据库具有以下优点:

但这一模式也有以下缺点:

针对跨服务事务和查询的实现,可以采用以下模式或解决方案:

相关模式

关注我,紧跟本系列专栏文章,咱们下篇再续!

作者简介:魔都架构师,多家大厂后端一线研发经验,在分布式系统设计、数据平台架构和AI应用开发等领域都有丰富实践经验。

各大技术社区头部专家博主。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。

负责:

  • 中央/分销预订系统性能优化
  • 活动&券等营销中台建设
  • 交易平台及数据中台等架构和开发设计
  • 车联网核心平台-物联网连接平台、大数据平台架构设计及优化
  • LLM Agent应用开发
  • 区块链应用开发
  • 大数据开发挖掘经验
  • 推荐系统项目

目前主攻市级软件项目设计、构建服务全社会的应用系统。

参考:

本文由博客一文多发平台 OpenWrite 发布!

上一篇 下一篇

猜你喜欢

热点阅读