Apollo配置加解密-基于Apollo—client的封装支持配置动态解密的巧思与探索

随着公司业务线不断壮大和发展，项目种类不断增多，对于配置的统一管理和监控以及支持动态发布等一些特性变成越来越重要的事情。所以需要引入配置中心进行与公司业务流程的适配。方向选型主要是Nacos和Apollo，二者区别这边不做赘述，最终落地选择了Apollo。在信息安全要求中，包含这么一条规则，要求放在配置中心的一些关键配置，比如数据库密码，各种中间件，MQ、以及服务器地址之类的数据，需要进行加密存储，以确保安全性。

Apollo本身是没有提供加解密的特性的，所以需要我们进行一些改造。

改造的方向有两点：1应用自身进行配置解密的动作 2在Apollo-client统一实现。

基于第一点，我在springboot和Mvc项目中都分别做了实现，但是业务代码耦合相对比较严重，并且加解密的动作最好还是做一个统一的地方处理，符合一种服务化的思想。

所以基于第二点，做了如下探索和改造。

其实网络上可以搜索到对应的一些改造方式，不亚于就是在DefaultConfig的updateConfig方法中添加上自己的解密逻辑。

那么为什么要在这个地方加上解密的逻辑呢？

其实很简单，这个类是Apollo启动流程中默认注入的类，并且在两个地方有所调用

其一：初始化的时候调用

其二：远程配置中心有变更监听到配置变更消息的时候调用

所以我们在这个方法中加入解密逻辑是没有问题的。我本地也进行了对应的测试实现。

但是做完之后我们思考一个逻辑，我们在引入一个框架解决某些问题的时候，本质上应该本着不去修改它源代码的角度上去进行扩展功能的实现，这样有利于我们后期做一些框架升级的动作，因为无论随着公司人员流转调动或者历史因素，总会有一些代码是没有人维护的，所以我们应该将后期的升级成本尽可能的缩小。所以这时候基于这样的思考点，我们应该想想能不能自己基于Apollo-client做一层封装，去实现加解密的功能呢？答案自然是可以的。

这时候我们应该从研究一个客户端在启动并且调用Apollo-client获取配置的流程性上去考虑。

基于这种流程，我们在IDE工具中进行对应的debug调试和源码跟踪，其实可以比较方便的跟踪到各个调用类。Apollo源码中提供了很多demo类给我们进行测试，这边不做过多赘述。