认识达内从这里开始

数据库应用是程序员在学习后端编程开发技术需要重点掌握的开发知识之一，下面我们就通过案例分析来了解一下，给微服务定义数据库架构时，我们需要考虑哪些问题。

服务必须是松耦合的。这样它们可以独立开发，部署和扩展

业务事务可能会强制跨越多个服务的不变量

一些业务事务需要查询多个服务的数据

为了可扩展性考虑，数据库有时候必须是可复制和共享的

不同服务存在不同的数据存储要求

1、每个服务一套数据库

为了解决上述问题，必须为每个微服务设计一个数据库。它必须仅专用于该服务。应当只能通过微服务的 API 访问它。其他服务无法直接访问它。比如，针对关系型数据库，我们可以采用每个服务使用单独的专用表(private-tables-per-service)，每个服务单独的数据库模式(schema-per-service)或每个服务单独的数据库服务器(database-server-per-service)。

2、服务之间共享数据库

我们已经说过，在微服务里，为每个服务分配一套单独的数据库是理想方案。采用共享数据库在微服务里属于反模式。但是，如果应用程序是一个单体应用而且试图拆分成微服务，那么反正规化就不那么容易了。在后面的阶段里，我们可以转到每个服务一套数据库的模式，直到我们完全做到了这一点。服务之间共享数据库并不理想，但是对于上述情况，它是一个切实可行的解决方案。大多数人认为这是微服务的反模式，但是对于灰场应用程序，这是将应用程序分解成更小逻辑部分的一个很好的开始。值得一提的是，这不应当应用于绿场应用程序。

3、命令和查询职责分离(CQRS)

一旦实现了每个服务分配单独一套数据库(database-per-service)，自然就会产生查询需求，这需要联合来自多个服务的数据。然而这是不可能的。CQRS 建议将应用程序分成两部分 —— 命令端和查询端。

4、命令端处理创建，更新和删除请求

查询端通过使用物化视图来处理查询部分

这通常会搭配事件驱动模式(event sourcing pattern)一起使用，一旦有任何数据更改便会创建对应的事件。通过订阅事件流，我们便可以让物化视图保持更新。

5、事件驱动

绝大多数应用程序需要用到数据，典型的做法就是应用程序要维护当前状态。例如，在传统的创建，读取，更新和删除(CRUD)模型中，典型的数据流程是从存储中读取数据。它也包含了经常使用事务导致锁定数据的限制。

事件驱动模式[7]定义了一种方法，用于处理由一系列事件驱动的数据操作，每个事件都记录在一个 append-only 的存储中。应用程序代码向事件存储发送一系列事件，这些事件命令式的描述了对数据执行的每个操作，它们会被持久化到事件存储。每个事件代表一组数据更改(例如，AddedItemToOrder)。

这些事件将保留在充当记录系统的一个事件存储里。事件存储发布的事件的典型用途是在应用程序触发的一些动作更改实体时维护这些实体的物化视图，以及与外部系统集成。例如，一个系统可以维护一个用于填充 UI 部分所有客户订单的物化视图。当应用程序添加新订单，添加或删除订单中的项目以及添加运输信息时，描述这些更改的事件将会得到处理并用于更新物化视图。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。