20200107_微服务架构下的数据库设计原则

微服务架构下的数据库设计原则

对于为服务而言，每一个微服务专注于某个功能，对外提供清晰的服务边界；由于体积小、复杂度低、高内聚、易于维护等特点，很多信息化平台都采用微服务架构。微服务设计中一个很重要的部分就是数据库的设计。

一对一数据库

基本原则是微服务与数据库是一对一的关系。这样主要是出于以下三点考虑：

• 服务调用清晰，同意通过REST接口或者RPC（或者消息）形式对外提供接口，如果数据库共享后，那么数据库也就成了接口，且根本没法控制接口的职责，性能、安全等因素也随着失控。
• 有利于问题的定位，大多数问题都是由于数据库数据造成的，如果数据库无法完全掌控，则可能会出现各种各样的问题，毕竟无法预知别人会往数据库插入/删除什么样的数据。
• 便于性能调优和应用的弹性伸缩，数据库完全掌控了才有可能做这些优化，否则根本无法预知你的扩展和调优，会不会对调用数据库的第三方应用造成什么样的影响。

共享数据

在实际项目中，为了性能和可维护性，可能会打破这种一对一的关系，出现共享数据库。例如一些码表

• 当一些数据变动不频繁，例如码表之类的，可以通过在各个为服务中单独维护一个这样的数据库表，通过同步的方式进行更新同步，当然这里有很多前提条件，例如变化不频繁。

• 只读业务数据的访问，最佳方式是通过服务调用，将SQL 层面的操作通过程序来完成，如果性能达不到要求，可考虑采用同步方式，数据库同步有多种，常见的有事件驱动消息形式，还有主动定时抽取的形式。

• 禁止直接访问其他数据库。

数据库向下兼容

• 增加表或字段：如果字段为空，可以直接向下兼容，如果不为空，需要设置之前数据一个缺省值
• 删除表或者字段： 可暂时保留待删除的字段，不急着删除，等若干版本后影响已经没有了，再删除
• 修改字段名和类型，新增加一个字段，把数据从旧字段拷贝到新字段，如果是类型的话， 还要做类型转换。再对后面的数据库表操作中新增触发器，保证新老字段的数据是一致的，若干版本后影响已经没有了，再删除旧字段。
• 修改表名称： 如果数据库支持可更新的视图，则通过建视图来维持之前的表名称。如果不支持，则跟修改字段一样，通过触发器进行两张表的数据拷贝同步，等到若干版本后影响已经没了，再删除旧的表名称。

分布式事务

​ 被一致认可的方案是saga，它的原理是为事物中的每个操作写一个补偿操作（Compensating Transaction），然后在回滚阶段挨个执行每一个补偿操作。在一个事物中共有3个操作T1，T2，T3。每一个操作要定义一个补偿操作，C1，C2，C3。事物执行时是按照正向顺序先执行T1，当回滚时是按照反向顺序先执行C3。