一、常见的敏感字段 手机号、地址、email、身份证号、银行卡号
二、目前的痛点及解决方案 2.1、目前的痛点 新数据处理： 各个业务系统都是独立连接加密机，如果节点横向扩容，需要进行大量审批，无法实时生效，在实时性要求很高的高并发场景非常危险。 各个业务接入安全组提供的client二方包，一旦安全组升级安全包，各业务都需要改造和测试，维护成本很高。
业务发展很多年，涉及的表很多，部分表数据量达到几亿，刷数是一项比较巨大的工程，那我们如何保证高效刷数不影响业务？
2.2、解决方案： 2.2.1、方案一： 提供统一的client sdk，由平台架构部门封装对接加密机相关的逻辑，对外屏蔽对接细节，各个业务引入sdk即可实现加解密功能。 优点：本地直连的加密机，没网络io消耗，性能高。 缺点：应用节点扩容还是需要申请和审批，实时性差。
适用场景：调用量非常大、性能要求很高、可用性和稳定性要求很强的金融属性业务。
2.2.2、方案二：提供统一的http restful接口或RPC接口，由底层基础服务承接这接口，提供单个和批量加解密服务，各个业务通过调用底层基础服务 提供的接口即可实现加解密功能。 优点：各个业务接入简单，不用引入sdk，只需按照接入文档接入，对业务系统没侵入性。 缺点：业务远程http或rpc调用底层服务提供的加解密接口，有一定的网络io开销，高并发场景调用容易出现超时导致加解密失败。
适用场景：调用量不大（比如内部系统）、非核心业务（有一定的容错性）。
2.2.3：client sdk + restful 接口或RPC远程接口结合使用。业务方自己保证高可用，通过加动态配置开关，例如加一个配置encrypt.type=1,2,3 1、本地调用加密机 2、restful或RPC远程接口调用加密机 3、默认值。优先restful或RPC远程接口调用，如果调用失败， 本地加密机兜底二次加密，从而保证加解密功能的高可用。 优点：融合了方案一和方案二，业务方可以自由选择加密方案，另外针对方案二的缺点，补齐了高可用的能力。 缺点：业务方使用比较繁琐，需要自己加配置开关进行额外处理。
适用场景：适用各种场景 不同的业务场景，可以选择不同的方案，互联网项目比较推荐方案一和方案三。
三、代码示例
使用开源的加密算法
加密手机号：
A
AesUtil即为对Aes加密算法的封装。
存储到数据库中的数据如下：
调用同一套sdk提供的解密接口，可以对加密串进行解密。
