微服务的数据库设计

单独的数据库：

微服务设计的一个关键是数据库设计，基本原则是每个服务都有自己单独的数据库，而且只有微服务本身可以访问这个数据库。它是基于下面三个原因。

• 优化服务接口：微服务之间的接口越小越好，最好只有服务调用接口(RPC或消息)，没有其他接口。如果微服务不能独享自己的数据库，那么数据库也变成了接口的一部分，这大大拓展了接口范围。
• 错误诊断：生产环境中的错误大部分都是和数据库有关的，要么是数据出了问题，要么是数据库的使用方式出了问题。当你不能完全控制数据库的访问时，会有各种各样的错误发生。它可能是别的程序直接连到你的数据库或者是其他部门直接用客户端访问数据库的数据，而这些都是在程序中查不到的，增加了错误排查难度。如果是程序中的问题，只要修改了代码，那么这个错误就不会再有。而上面提到的错误，你永远都没法预测它们什么时候还会再次发生。
• 性能调优：性能调优也是一样，你需要对数据库有全权控制才能保证它的性能。如果其他部门一定要访问数据库，而且只是查询的话，那么可以另外创建一份只读数据库，让他们在另一个库中查询，这样才不会影响到你的库。

理想的设计是你的数据库只有你的服务能访问，你也只调用自己数据库中的数据，所有对别的微服务的访问都通过服务调用来实现。当然，在实际应用中，单纯的服务调用可能不能满足性能或其他要求，不同的微服务都多少需要共享一些数据。

共享数据：

微服务之间的数据共享可以有下四种方式。

静态表：

有一些静态的数据库表，例如国家，可能会被很多程序用到，而且程序内部需要对国家这个表做连接(join)生成最终用户展示数据，这样用微服务调用的方式就效率不高，影响性能。一个办法是在每个微服务中配置一个这样的表，它是只读的，这样就可以做数据库连接了。当然你需要保证数据同步。这个方案在多数情况下都是可以接受的，因为以下两点：

1. 静态的数据库表结构基本不变：因为一旦表结构变了，你不但要更改所有微服务的数据库表，还要修改所有微服务的程序。
2. 数据库表中的数据变化不频繁：这样数据同步的工作量不大。另外当你同步数据库时总会有延迟，如果数据变化不频繁那么你有很多同步方式可供选择。

只读业务数据访问：

如果你需要读取别的数据库里的动态业务数据， 理想的方式是服务调用。如果你只是调用其他微服务做一些计算，一般情况下性能都是可以接受的。如果你需要做数据的连接，那么你可以用程序代码来做，而不是用SQL语句。如果测试之后性能不能满足要求，那你可以考虑在自己的数据库里建一套只读数据表。数据同步方式大致有两种。如果是事件驱动方式，就用发消息的方式进行同步，如果是RPC方式，就用数据库本身提供的同步方式或者第三方同步软件。

通常情况下，你可能只需要其他数据库的几张表，每张表只需要几个字段。这时，其他数据库是数据的最终来源，控制所有写操作以及相应的业务验证逻辑，我们叫它主表。你的只读库可以叫从表。 当一条数据写入主表后，会发一条广播消息，所有拥有从表的微服务监听消息并更新只读表中的数据。但这时你要特别小心，因为它的危险性要比静态表大得多。第一它的表结构变更会更频繁，而且它的变更完全不受你控制。第二业务数据不像静态表，它是经常更新的，这样对数据同步的要求就比较高。要根据具体的业务需求来决定多大的延迟是可以接受的。

另外它还有两个问题：

1. 数据的容量：数据库中的数据量是影响性能的主要因素。因为这个数据是外来的，不利于掌握它的流量规律，很难进行容量规划，也不能更好地进行性能调优。
2. 接口外泄：微服务之间的接口本来只有服务调用接口，这时你可以对内部程序和数据库做任何更改，而不影响其他服务。现在数据库表结构也变成了接口的一部分。接口一旦发布之后，基本是不能更改的，这大大限制了你的灵活性。幸运的是因为另外建了一套表，有了一个缓冲，当主表修改时，从表也许不需要同步更新。

除非你能用服务调用(没有本地只读数据库)的方式完成所有功能，不然不管你是用RPC方式还是事件驱动方式进行微服务集成，上面提到的问题都是不可避免的。但是你可以通过合理规划数据库更改，来减少上面问题带来的影响，下面将会详细讲解。

读写业务数据访问：

这是最复杂的一种情况。一般情况下，你有一个表是主表，而其他表是从表。主表包含主要信息，而且这些主要信息被复制到从表，但微服务会有额外字段需要写入从表。这样本地微服务对从表就既有读也有写的操作。而且主表和从表有一个先后次序的关系。从表的主键来源于主表，因此一定先有主表，再有从表。

上图是例子。假设我们有两个与电影有关的微服务，一个是电影论坛，用户可以发表对电影的评论。另一个是电影商店。“movie”是共享表，左边的一个是电影论坛库，它的“movie”表是主表。右边的是电影商店库，它的“movie”表是从表。它们共享“id”字段(主键)。主表是数据的主要来源，但从表里的“quantity”和“price”字段主表里面没有。主表插入数据后，发消息，从表接到消息，插入一条数据到本地“movie”表。并且从表还会修改表里的“quantity”和“price”字段。在这种情况下，要给每一个字段分配一个唯一源头(微服务)，只有源头才有权利主动更改字段，其他微服务只能被动更改(接收源头发出的更改消息之后再改)。在本例子中， “quantity”和“price”字段的源头是右边的表，其他的字段的源头都是左边的表。本例子中“quantity”和“price”只在从表中存在，因此数据写入是单向的，方向是主表到从表。如果主表也需要这些字段，那么它们还要被回写，那数据写入就变成双向的。

直接访问其它数据库：

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!