微服务的数据库设计
|
这种方式是要绝对禁止的。生产环境中的许多程序错误和性能问题都是由这种方式产生的。上面的三种方式由于是另外新建了本地只读数据库表，产生了数据库的物理隔离，这样一个数据库的性能问题不会影响到另一个。另外，当主库中的表结构更改时，你可以暂时保持从库中的表不变，这样程序还可以运行。如果直接访问别人的库，主库一修改，别的微服务程序马上就会报错。 向后兼容的数据库更新： 从上面的论述可以看出，数据库表结构的修改是一个影响范围很广的事情。在微服务架构中，共享的表在别的服务中也会有一个只读的拷贝。现在当你要更改表结构时，还需要考虑到对别的微服务的影响。当在单体(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)，因此在事物执行过程中数据是不一致的，并且这种不一致会被别的进程看到。在生活中，大多数情况下，我们对一致性的要求并没有那么高，短暂的不一致性是可以接收的。例如银行的转账操作，它们在执行过程中都不是在一个数据库事物里执行的，而是用记账的方式分成两个动作来执行，保证的也是最终一致性。 Saga的原理看起来很简单，但要想正确的实施还是有一定难度的。它的核心问题在于对错误的处理，要把它完全讲明白需要另写一遍文章，我现在只讲一下要点。网络环境是不可靠的，正在执行的命令可能很长时间都没有返回结果，这时，第一，你要设定一个超时。第二，因为你不知道没有返回值的原因是，已经完成了命令但网络出了问题，还是没完成就牺牲了，因此不知道是否要执行补偿操作。这时正确的做法是重试原命令，直到得到完成确认，然后再执行补偿操作。但这对命令有一个要求，那就是这个操作必须是幂等的(Idempotent)，也就是说它可以执行多次，但最终结果还是一样的。 另外，有些操作的补偿操作比较容易生成，例如付款操作，你只要把钱款退回就可以了。但有些操作，像发邮件，完成之后就没有办法回到之前的状态了，这时就只能再发一个邮件更正以前的信息。因此补偿操作不一定非要返回到原来的状态，而是抵消掉原来操作产生的效果。 微服务的拆分： 我们原来的程序大多数都是单体程序，但现在要把它拆分成微服务，应该怎样做才能降低对现有应用的影响呢?  我们用上面的图来做例子。它共有两个程序，一个是“Styling app”，另一个是“Warehouse app”，它们共享图中下面的数据库，库里有三张表，“core client”，“core sku”，“core item”。  假设我们要拆分出来一个微服务叫“client-service”，它需要访问“core client”表。第一步，我们先把程序从原来的代码里拆分出来，变成一个服务. 数据库不动，这个服务仍然指向原来的数据库。其他程序不再直接访问这个服务管理的表，而是通过服务调用或另建共享表来获取数据。  第二步，再把服务的数据库表拆分出来，这时微服务就拥有它自己的数据库了，而不再需要原来的共享数据库了。这时就成了一个真正意义上的的微服务。 上面只讲了拆分一个微服务，如果有多个需要拆分，则需一个一个按照上面讲的方法依次进行。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
