在 DevOps 中以 API 看待共享数据库

在 WinOps 2017 大会上，Sabin.io 首席顾问 Simon Sabin 做了一个演讲，介绍如何将数据库更改加入到持续部署模型中。从数据库所有者的角度看，要实现在多个服务或应用间共享数据库，关键之一就是将这些共享数据库看成是API。

Sabin 建议考虑使用视图、触发器和存储过程等机制。它们可以更改数据库的内部结构，并同时保持向后兼容的应用数据操作。他举了一个例子，一个存储信用卡号的数据库表已经从纯文本改为被加密的，但要保证应用依然以纯文本方式检索卡号。例子中是通过查询视图实现的，而实际的数据库表通过触发器实现信息的加密和解密。处理结构如下图所示：

数据库向应用提供隐式的合约和接口，其中数据库的内部更改（通常出于性能、安全和其它一些改进的需要）不应该影响到应用。这一原则可以类比为 API，突破性更改同样遵循最小化原则，并应给出大量的通知信息，保证应用在实际数据更改之前采纳和部署前向兼容更改。对数据库应用消费者驱动合约，这样的方法是可延展的。

按Sabin 的说法，需要这一方法去调和对共享数据库的不同视角。应用开发人员总是将数据库看成是“沉默的存储”，而数据库管理员（DBA）则将数据库看成是关键业务数据的仓储之所。理想情况下，每个应用团队会有自己的数据库，团队中也应具有DBA 角色，但这通常难以达到。

当应用本身就需要模式或其它更改时，Sabin 建议降低批处理的规模（因为在数据库中实现可靠性和一致性是一个复杂的任务），一次应用一个小更改，并更改相应的应用代码。选取何种迁移机制，是金模式（Gold Schema）还是迁移脚本方式，依赖于更改的具体类型。在Sabin 看来，相比于对抗式的，这一机制更多是补充式的。对于模式更改，适用于金模式机制。金模式定义了目标模式（期望状态），并使用类似于 SQLCompare 这类的工具做了当前状态和期望状态间的“差异比较”。迁移脚本包括 DBDeploy 、 Flyway 或 ReadyRoll 等，该机制可能更适用于更复杂的修改。

Sabin 还推荐了其它一些方法，包括：指定数据库去适合自身工具而非其它方法，将部署信息添加到数据库自身中以便于追踪和诊断问题，将数据库更改作为交付流水线一部分看待以提升可审校性和合规性。演讲的最后，Sabin 建议使用区分在“私有”和“公开”的方法极大地改进数据安全（在持续发生关键数据泄漏时）。例如，让一个可访问（“公开”）的小型数据库中提供对较大规模的安全（“私有”）数据库的视图，而“私有”数据库是不应被应用本身直接访问的。

正如 DevSecOps 运动是经过一段时间后才得以确立，将数据库更改加入到集成持续部署过程中的理念业已存在一段时间了，并被冠以各种称法。Sabin 将其称为“Data DevOps”，也有人将其称为“数据库生命周期管理”（DLM，Database Lifecycle Management）。另一位WinOps 2017 大会演讲者， Eduardo Piairo ，指出：

DevOps 并非是要定义一个处理数据库更改的新过程，而是将数据库更改和应用及架构代码一并集成到服务生命周期中。

查看英文原文： Treating Shared Databases Like APIs in a DevOps World