携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第14天，点击查看活动详情

前言

现在有一个这样的场景：要在现有的系统基础上，再另外部署一套演示系统，但是需要将所有的真实数据进行数据脱敏，例如：某某公司->公司1、某某人名->员工1、某某地名->地方1。

方案

方案1：完全拷贝

考虑将所有应用服务在新的环境里搭建一套，并把所有数据同步到新的数据库服务器，数据脱敏方面可以在数据同步环节时进行，使用ETL或是其他数据处理的方式。

此方案的优点显而易见，就是复杂度很低，大多的工作都是在运维侧以及DBA侧，开发上不需要任何修改；缺点是对资源的成本很高，因为完全要一比一的复刻一套新的环境，并且需要将所有的应用服务都要新启动一套，因为主业务服务依赖的一级应用服务下，还可能有一级应用服务依赖其他的二级应用服务，所以不能只拷贝直接依赖的一级服务。

方案2：单独网关

在原有的系统基础上，单独新建一个网关，使新环境的域名映射到新的网关上，两套网关相互独立，然后在新网关中做数据脱敏过滤。

此方案的优点是实现难度小，不会使用太多的资源，也可以对单独网关的鉴权或是白名单做一些特殊处理。 缺点是对于网关的配置需要维护两套，并且例如一些路由转发的配置，在原有网关更新的时候，新网关也需同步更新，增加了些微维护成本。

方案2：嵌套网关

考虑在现有网关上，再加一个网关，然后增加一个演示环境的域名映射，新网关只做请求转发和返回数据过滤，请求都会转发到原有网关上，不做任何处理，鉴权和其他白名单等都沿用原有的一套逻辑，在网关中做请求过滤，对每个请求的返回数据都进行校验和脱敏，然后将数据重新设置回请求返回体中。

这种方案下的优点和缺点也很明显了，基本上和方案2是对应起来的，方案2的缺点在方案3得到了补全，但是方案2的优点中 对网关做单独的鉴权或是其他处理在方案3中反而变成了缺点。

总结

最后，这只是一套简单的数据脱敏方案，其他有更复杂或者更高阶的方案暂时还没去做了解，如果大家有更好的建议可以在评论区讨论，互相学习。