微服务革命-如何打破传统应用的数据库？

福布斯报告曾经说过，“现在，每个公司都是软件公司”，软件正在改变我们的生活。而微服务目前是每个企业的正在转型，或者是将来转型的方向，但现有的工具在没有历史包袱的项目中可以轻松的应用，但是在传统巨石应用中使用起来，并没有那么容易。实现一个应用很容易，但是维护应用的状态缺很难，这里的状态指的是数据的持久化信息。Edson Yanaga, 红帽软件（Red Hat) 的 Developer Experience 部门总监，在 DEVOX Belgium 大会上进行了如何打破巨石应用数据库的分享。

如何打破巨石应用的数据库?

企业实现价值的方式，是快速的发布软件，降低响应时间，缩短用户体验到新功能的时间，从而实现软件的价值，从宏观的角度来看，我们所使用的各种 DevOps 工具，本质上都是为了实现缩短响应时间这个目的。那么从一个传统巨石应用来看，如何缩短这个响应时间呢？

a. 减少每次发布的内容

传统应用大约每个月发布一次，每次发布的内容通常较多，导致一旦某个模块部署出现了问题，整个发布都需要回滚，再次发布时，可能又会因为另一个模块的发布失败，导致整个发布过程受到拖延，耗时长达几个小时甚至几天。

DevOps 提出的概念叫做 Batch Size。DevOps 和微服务所做的事情，就是要减少你在部署的时刻所需要部署的内容。 并不是所有人都需要做到像谷歌，Netflix 一样实时部署，实时评估商业价值。对于大多数企业来说，一周一次的发布是能够满足商业价值评估的周期的。Batch Size 即使是3个月，1个月也没关系，只要你持续改进，一定能够找到适合自己的 Batch Size。

b. 蓝绿部署

实现蓝绿部署的最大好处，是让你拥有0宕机时间的升级。有什么好处？这意味着可以白天工作时间升级，而不需要等到凌晨熬夜升级，这是众多运维同学的梦想。即使上线失败，也不影响线上的服务。部署两套应用也许不难，难的是维护数据库的状态，以及做数据库 Schema 的迁移，目前比较流行的工具是 Flyway 和 LiquiBase，这两个工具都是基于 Java 的开源工具，大家可以去 Github 上自行比较二者的优劣，选择合适自己的工具进行使用。

c. 分片执行更新语句

当数据库的行数变得多的时候，这意味着你执行更新语句需要很长的锁表时间。如何解决？举例说明，假设我需要修改重命名一个用户表的字段，通常的做法是：

在用户数据量非常大的时候，这样直接执行会需要很长的锁表时间，而且这种做法是不向下兼容的，应用无法回滚。推荐的做法如下：

我们先增加一列，然后分片的每次更新100条记录，更新完之后，带程序运行没有问题之后，再执行列的删除。其中的理念是：“绝对不对数据库做破坏性的操作”，任何时候都能够实现轻松回滚，有了这样的保障，我们才能够在上线的时候更加轻松和自信。

从上图可以得出如何修改表的某列的最佳实践。

d. 为每个服务提供独立的数据库

经历这个过程，从理论上来说，你经历的是从 CRUD (Create, Retrieval, Update and Delete) 到 CQRS (Common Query Responsibility Segregation) 的变化，在单数据库的时代，你只需要对一个数据库执行 CRUD。在微服务的时代，你的数据源来自不同的数据库，如下图所示：

你需要执行的是 CQRS，通常，这样带来的架构变更代价是巨大的，如何避免架构的变更而实现数据库的微服务化呢？有下面几种方面：

· View

使用数据库视图，来屏蔽复杂的跨表查询，对于开发者来说，会降低他实现跨表查询的复杂度。这是最容易的方法，当然它也带来一些缺点，例如数据库之间必须之间能够通信，而且由于它是强一致性的实现，所以会带来潜在的性能问题，而这一点是非常致命的。

· Material View

View 不会存储任何数据，可以理解为它是一系列虚拟的表，Material View 是会将 View 执行的结果存储在实际的表里，数据在需要的时候可以被更新。这种做法会得到更好的性能，可以支持强一致性或者最终一致性的实现。

· Event Sourcing

分布式数据库的状态使用一些列事件来保证。它的优点是不会丢失任何一个数据库的变更记录，即使数据库宕机，当它恢复的时候，也会继续执行数据库变更，达到最终一致性，这种方法非常容易去做日志审计。

在这里强烈推荐一个数据库 Event Sourcing 的开源工具：Debezium（//debezium.io），这个工具的目的，是帮助传统应用数据库通过 Event Sourcing 的方式，发布每个数据库的变更事件，供其他微服务消费，而不需要做任对何现有数据库的修改。

Debezium 的应用场景在于：假设我需要实现一个报表的查询，在微服务的架构下，我不得不使用 HTTP 调用另外一个服务从而获得数据，通常这样的查询很慢，尤其在不同用户同时进行多个数据库进行联合查询时会变得更慢。如果使用 Event Sourcing 的方式，例如 Debezium，我只需要在本地建立一个独立的数据表，通过 Debezium 的数据库事件队列，我可以只存储我关心的字段，这样在做联合查询的时候效率会非常高。

Debezium 使用 Kafka 作为数据库变更记录的消息队列工具，用 Kafka 的好处是它的服务器端非常的轻量级，因为 Kafka 的客户端能够自行维护消息的状态，知道哪条消息是最新的，且不会丢失任何一条消息。

从上图可以看到，Debezium 的消息体会以 Json 的方式记录每个数据库的变更记录，你可以将数据库变更的消息做一些优化，比如某条记录的最后操作是删除，那么之前对他的修改操作都可以不执行，从而提高执行效率。

目前 Debezium 支持 Mysql，MongoDB，Postgre，Oracle，Redhat 已经是 Debezium 的用户。

总结

每个公司都在实现快速发布，传统的应用由于技术和各种原因难以实现快速发布，但是又不可能推倒一切重来，上新的技术，那么我们应该思考如何引入工具，实现对传统应用的迁移，Debezium 可以在不改变现有数据库的情况下，实现对微服务的数据库支持，希望能够给大家带来新的思路。

参考资料：

https://youtu.be/6dfBd-2Oq1M

//debezium.io/

作者：王青

目前任职 JFrog 中国首席架构师，之前在 IBM，HPE，爱奇艺，新浪，VIPKID 等公司做过研发和架构，是有十多年开发经验的互联网老兵，专注于软件生命周期管理，微服务架构，云原生应用，容器化等领域。