小伙伴们在平时开发过程中，无论使用什么技术栈，随着中间件接入的越来越多（DB、MySQL、NoSQL、MQ等等等等），配置越来越多，就导致配置文件越来越臃肿，每次新增或者修改配置的时候就得肉眼秒，手动改，还容易出错，简直令人发狂。那么有没有更方便快捷的方法呢？通用解法是什么样的，今天我的这篇文章就告诉你答案。
正文
基于上面的问题，肯定有小伙伴说上配置中心不得了，还有界面配置，维护起来也方便，（其他小伙伴持反对意见。这种方式要你说，我上我也行）。
其实我想说的是你这是相当于把配置挪了个地儿，也没从根本上解决问题呀，不过呢，这些都是小问题，解决问题的方法让我给你细细道来。
理清思路
咱们把问题剖析一下，问题的痛点在哪儿？我们列举下我们在当下使用场景中遇到的问题？
1. 配置太多，维护不方便。（效率问题）
2. 本来我就用用中间件，域名地址、ip、密码这这些其实不是开发关注的问题。（职责边界问题）
3. 敏感配置泄露（数据安全问题）
配置现状
那么我们可以从几个方面去解决问题？
1. 简化配置
2. 职责明确，不该我关注的事儿，让别人干
3. 统一收口，统一流程化管理
问题都理清了，还等什么？干就完了。
解题思路
整体思路就是增加一个代理层，类似的有Nginx，Envoy。
下面提供两个思路：
思路1：
反向代理，对MQ、Redis、DB等地址进行反向代理，但是针对各个中间件的处理还有一些问题？
1. 密码配置如何解决？
2. 敏感数据安全如何脱敏？
如果这些问题不解决，这个代理也是没有什么意义，多此一举。
思路2：
定制代理层，针对思路1的痛点我们继续深入优化，以下是几个优化点：
1. 资源化管理中间件对接、代理层对资源做自动注册发现
2. 中间件client特殊定制，对密码进行自动填充。
可能这样说起来大家比较懵逼，咱们看图说话。
交互
解决问题
从以上的交互思路中我们继续细化我们的设计。
从上面的交互流程中，我们总结一下我们接下来要做的事儿：
1. 资源配置。这是一个配置中心配置的过程，开发者申请带着环境标识、集群标识、应用标识由代理层分发相关的资源标识，完成资源配置这个行为。
2. 中间件client改造。首先从接入client端入手，client端主要做的事儿就是接入代理层，并屏蔽一些密码、端口等差异，根据资源标识、环境标识通过配置中心获取不同中间件的资源配置，通过资源标识就能获取到当前资源的全部配置，在启动过程中注入到应用中，为了提升性能，缓存配置是必不可少的。
3. 代理层逻辑。网络代理，负载均衡（选择实例的过程），健康检查（对下层访问资源进行心跳检测）等。
这样做的优缺点又是什么样的呢？
优点：
·技术研发无需关心维护密码配置、密码脱敏等操作，直接使用资源标识即可。
· 分工明确，边界清晰，这些倒腾接入配置的事儿交给专门的人维护。
· 统一配置资源。
缺点：
· 中间件客户端接入有改造成本。
· 新增了接入层依赖。
总体来说有利有弊，鱼与熊掌不可兼得，不过这些缺点对于开发提效来说，也算是可以接受的。
下面是针对以上的思路梳理出来的业务架构与交互流程图，帮助大家理解其中的原理。
接入层业务架构
交互流程图
配置接入过程：
客户端配置读取、启动应用过程：
从以上的流程中我们可以看出，其实配置工作也是没有少，只是说基于我们的思路流程化、职责划分更明确，对于研发提效是真不戳。
小结
哔哔了这么多，咱们总结一下，从咱们发现痛点，到找到问题的关键点思路，以及解决问题，无论是业务开发、还是技术演进，解决问题的思路很重要，这直接影响我们解决问题的方向，方向错了，其他都是白瞎。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
