背景

微服务系统通常包含多个微服务，部分业务或服务的显著改动，会影响系统的全链路调用流程以及整个产品给用户带来的体验。此外，线下测试很难覆盖线上的所有场景，需要还原配置、依赖、负载、数据的有效性以实现真实验证。

此时服务发布会引入灰度发布策略，新版本的软件会被逐步地推送给一小部分用户，以在真实环境中测试新版本的稳定性和性能。通过灰度发布，软件开发团队可以在控制范围内逐步扩大新版本的受众群体，发现问题并及时修复，保障安全生产和达成项目迭代。而如何控制灰度中问题的影响，避免污染系统稳态，是灰度发布过程中的关键。

问题

微服务的通信可以通过流量特征进行路由，已有成熟的方案基于流量策略进行灰度验证。对于数据库层面，开发人员希望让灰度过程数据保持一致或者在灰度发布同时对数据割接处理，在不同版本间兼容。如果数据库层面存在差异，在灰度发布中，不一致的数据很可能会导致问题的产生。

目前常见的数据库灰度方式是将灰度流量加入特征，路由到灰度服务，同时将灰度服务涉及的数据库操作至独立搭建的数据库灰度实例中进行。但这种使用简单的灰度数据库实例方案难以适配复杂的业务变更和回退过程的数据修订需求。

目前对于灰度数据的处理，没有通用的解决方案，对于期间产生的脏数据，只能考虑通过新增数据的流量标记，在灰度过程后，对数据进行恢复或者清除，通过数据割接保证数据的正确性，在此过程中对于生产的影响是难以评估的，非常容易出现意想不到的问题。

MSE中的数据库灰度

那怎么解决呢？

微服务架构中特有的全链路灰度场景，即通过构建从网关到后端服务的环境隔离，来对多个不同版本的服务进行灰度验证。流量在调用链路上流转时，由流经的网关、各个中间件以及各个微服务来识别灰度流量，并动态转发至对应服务的灰度版本。一般通过数据库灰度解决数据隔离的问题，msgc的数据库灰度功能提供以影子表实现数据层面的流量隔离的方案。

影子表方案，是在同一个实例上的同一个数据库上建立对应的影子表。我们在执行 SQL 的过程中，对灰度流量的 SQL 进行解析与修改，实现不同环境流量的 SQL 分别访问对应的表，假设基线环境的表的名称为 mse_demo_table，那么 gray 环境的流量可以映射到 mse_demo_table_gray 的表中，从而无需搭建灰度数据库，实现灰度数据和基线环境数据表隔离的效果。

对于数据库灰度的更多使用说明，可以参考MSE产品文档。