微服务的数据库设计
|
这种方式是要绝对禁止的。生产环境中的许多程序错误和性能问题都是由这种方式产生的。上面的三种方式由于是另外新建了本地只读数据库表，产生了数据库的物理隔离，这样一个数据库的性能问题不会影响到另一个。另外，当主库中的表结构更改时，你可以暂时保持从库中的表不变，这样程序还可以运行。如果直接访问别人的库，主库一修改，别的微服务程序马上就会报错。 向后兼容的数据库更新： 从上面的论述可以看出，数据库表结构的修改是一个影响范围很广的事情。在微服务架构中，共享的表在别的服务中也会有一个只读的拷贝。现在当你要更改表结构时，还需要考虑到对别的微服务的影响。当在单体(Monolithic)架构中，为了保证程序部署能够回滚，数据库的更新是向后兼容的。需要兼容性的另一个原因是支持蓝绿发布(Blue-Green Deployment)。在这种部署方式中，你同时拥有新旧版本的代码，由负载均衡来决定每一个请求指向那个版本。它们可以共享一个数据库(这就要求数据库是向后兼容的)，也可以使用不同的数据。数据库的更新简单来讲有以下几种类型：
向后兼容的数据库更新的好处是，当程序部署出现问题时，如需进行回滚。只要回滚程序就行了，而不必回滚数据库。回滚时一般只回滚一个版本。凡是需要删除的表或字段在本次部署时都不做修改，等到一个或几个版本之后，确认没有问题了再删除。它的另一个好处就是不会对其他微服务中的共享表产生立刻的直接影响。当本微服务升级后，其他微服务可以评估这些数据库更新带来的影响再决定是否需要做相应的程序或数据库修改。 跨服务事物： 微服务的一个难点是如何实现跨服务的事物支持。两阶段提交(Two-Phase Commit)已被证明性能上不能满足需求，现在基本上没有人用。被一致认可的方法叫Saga。它的原理是为事物中的每个操作写一个补偿操作(Compensating Transaction)，然后在回滚阶段挨个执行每一个补偿操作。示例如下图，在一个事物中共有3个操作T1，T2，T3。每一个操作要定义一个补偿操作，C1，C2，C3。事物执行时是按照正向顺序先执行T1，当回滚时是按照反向顺序先执行C3。 事物中的每一个操作(正向操作和补偿操作)都被包装成一个命令(Command)，Saga执行协调器(Saga Execution Coordinator (SEC))负责执行所有命令。在执行之前，所有的命令都会按顺序被存入日志中，然后Saga执行协调器从日志中取出命令，依次执行。当某个执行出现错误时，这个错误也被写入日志，并且所有正在执行的命令被停止，开始回滚操作。  Saga放松了对一致性(Consistency)的要求，它能保证的是最终一致性(Eventual Consistency)，因此在事物执行过程中数据是不一致的，并且这种不一致会被别的进程看到。在生活中，大多数情况下，我们对一致性的要求并没有那么高，短暂的不一致性是可以接收的。例如银行的转账操作，它们在执行过程中都不是在一个数据库事物里执行的，而是用记账的方式分成两个动作来执行，保证的也是最终一致性。 （编辑：惠州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
