微服务的数据库设计

无

读写业务数据访问

1，拥有数据库完整的控制权，更有利于业务的整体接口设计，更有利于业务的整体接口设计，无需考虑他方操作数据库影响自己的业务设计，为微服务自身业务完整性设计提供了保障。2，拥有数据库完整的控制权，更有利于错误排查，排除他方一切干扰，因为微服务架构风格复杂性，错误排查本身就是一键难事。3，拥有数据库完整的控制权，更有利于微服务性能调优，而性能的调优首先依赖于快速找到性能瓶颈点，如果没有绝对控制权，调优瓶颈点在他方，更为困难；另外由于有了控制权我们的业务设计完全掌握在自己手中，性能瓶颈点定位会更快。4，拥有数据库完整的控制权，微服务独立性更好，体现了微服务“独、松”的特点，能更可靠的计算数据链接，更有利于服务节点扩展。

✅ 简单计算和数据拼接优先考虑服务调用方式解决。

只读业务数据访问

给每一个字段分配一个唯一可以更改的服务，其他服务接收源头发出的更改消息后同步

有

增加表或字段：如果字段可取空值，这个操作是向后兼容的。如果是非空值就要插入一个缺省值。

基本原则是每个服务都有自己单独的数据库

向后兼容，数据更新几种类型

建只读表，做数据同步。表数据特点和静态表相反，另外数据容量和数据外泄的问题

向后兼容的数据库更新的好处是，当程序部署出现问题时，如需进行回滚。只要回滚程序就行了，而不必回滚数据库。回滚时一般只回滚一个版本。凡是需要删除的表或字段在本次部署时都不做修改，等到一个或几个版本之后，确认没有问题了再删除。它的另一个好处就是不会对其他微服务中的共享表产生立刻的直接影响。当本微服务升级后，其他微服务可以评估这些数据库更新带来的影响再决定是否需要做相应的程序或数据库修改。

性能瓶颈

可以接受表结构问题稳定；数据更新少；

修改字段类型：与修改字段名几乎相同，只是在拷贝数据时，需要做数据类型转换。

🚫 禁止直接访问其它数据库

修改字段名：新增加一个字段，把数据从旧字段拷贝到新字段，用数据库触发器(或程序)同步旧字段和新字段(供过渡时期使用)。 然后再在几个版本之后把原来的字段删除。

修改表名：如果数据库支持可更新视图，最简单的办法是先修改表的名字，然后创建一个可更新视图指向原来的表。如果数据库不支持可更新视图，使用的方法与修改字段名相似，需要创建新的表并做数据同步。

删除表或字段：可先暂时保留被删除表或字段，经过几个版本之后再删除。

共享数据

静态表