Janker

V1

2022/09/04阅读:8主题:全栈蓝

大厂是如何做基础配置管理的?

大厂是如何做基础配置管理的?

大家好,我是janker。

小伙伴们在平时开发过程中,无论使用什么技术栈,随着中间件接入的越来越多(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. 代理层逻辑。网络代理,负载均衡(选择实例的过程),健康检查(对下层访问资源进行心跳检测)等。

这样做的优缺点又是什么样的呢?

优点:

  1. 技术研发无需关心维护密码配置、密码脱敏等操作,直接使用资源标识即可。
  2. 分工明确,边界清晰,这些倒腾接入配置的事儿交给专门的人维护。
  3. 统一配置资源。

缺点:

  1. 中间件客户端接入有改造成本。
  2. 新增了接入层依赖。

总体来说有利有弊,鱼与熊掌不可兼得,不过这些缺点对于开发提效来说,也算是可以接受的。

下面是针对以上的思路梳理出来的业务架构与交互流程图,帮助大家理解其中的原理。

接入层业务架构

交互流程图

配置接入过程

客户端配置读取、启动应用过程

从以上的流程中我们可以看出,其实配置工作也是没有少,只是说基于我们的思路流程化、职责划分更明确,对于研发提效是真不戳。

小结

哔哔了这么多,咱们总结一下,从咱们发现痛点,到找到问题的关键点思路,以及解决问题,无论是业务开发、还是技术演进,解决问题的思路很重要,这直接影响我们解决问题的方向,方向错了,其他都是白瞎。

我是janker。我们愈是学习,愈觉得自己的贫乏。感谢各位大佬的点赞评论在看。我们下期再见。

分类:

后端

标签:

Java

作者介绍

Janker
V1