运维自动化基础建设|配置中心和注册中心

运维自动化基础建设|配置中心和注册中心

在前面的文章中我们依次提到了工件库，代码仓库、分支模型、代码质量管理等基础建设，今天我们聊聊注册中心和配置中心，这个东西的边界有些模糊，不像最开始我们说的网络的规划，主机的规划可以完全交付OPS来管理，尤其是配置中心的日常变更维护管理。

配置中心

配置中心里都会有那些配置(不局限于以下罗列)

•资源类的配置•DB资源•常量•三方的key和secert•其他

资源类的配置

配置信息的来源一般是通过运维平台申请得到的，如果没有运维平台的情况下，可能是由DBA通过小窗交付给相关开发人员，相关开发人员再把对应账号密码等信息录入到配置中心里面去，不难发现这其中存在的问题，资源信息的多次流转有可能会出现多复制一个空格，少复制一个字符的情况，再则就是信息泄漏问题的出现，所以这个时候我们在选择配置中心的时候需要支持继承的功能，比如由DBA手动录入到配置中心(只有DBA知道相关信息),对应项目的配置直接引用对应的DB资源即可，刚才描述的这个场景的前提是大家要有一个统一的key的约定，因为配置中心基本都以k v键值对的形式存储的。

需要注意的是资源类的信息的变更与之对应的服务需要重新获取才能拿到最新的链接信息(也就是需要重启操作)。

常量

这个并不是每个项目配置里都会有的，比如有的项目需要配置黑白名单，由于人员离职或岗位变动等原因，黑白名单里的信息会随之变动。

三方认证信息

这个我个人的理解和DB资源一样，尽可能的配置一次，全局继承引用即可，避免过多的人获取到具体的value信息。

其他

比如邮箱账号密码信息之类的，比如回调的WEBHOOK等资源，非全局模式的，在当前项目的配置里即可。

注册中心

•动态服务发现•实时健康检测•提供接口进行服务的上下线操作(理论上用不到)•本地Cache的支持

其实注册中心这块站在OPS的角度上不需要关注太多，但是在初始选型的时候却是需要考虑的，更多详情可以查看参考文档。

当前主流的可供选型的方案

•disconf•百度开源只支持java•Spring Cloud Config && Spring Cloud Eureka•后端存储支持gitlab•etcd•consul•Apollo•携程框架部门研发•支持多语言•Nacos•阿里开源，1.0之后的版本可用于生产•当下好像还没有支持php

•其他•自研•二开

关于选型

•多语言支持•配置分层支持•基于角色的权限支持•namespace的隔离

多语言支持

多数情况下，一个公司的技术栈并不局限于某一种特定的语言，这个时候为了支撑所有的应用，在选型的情况下需要考虑多语言支持。

配置分层支持

这个也就是刚才上面我们描述的可继承，或者叫做可共享的配置支持，这样的话，我们可以把敏感的数据由专人添加配置，其他的项目直接引用即可，不需要知道具体的VALUE， 调用与之对应的KEY即可。

基于角色的权限支持

前面也有提到，一个项目的配置里，常量这块是变更比较频繁的，比如某个开关，如果配置中心的权限完全管控在OPS手里，那就一天什么都不要干了，全天候的支撑修改配置文件去了，这样于我个人而言我是觉得是浪费生命，所以一个比较完善的基于角色的权限控制显得就特别的重要，对应的人只需要对应项目的权限即可，其他的他也无权查看，做到安全隔离。

namespace的隔离

根据前面我们文章不难看出，公司里的环境并不是只有生产环境，还有开发、测试、预发等环境，这个时候，我们是每套环境各搭建一套，还是采用namespace隔离的方式实现不同环境的区分呢？我是比较倾向于后者，极大程度降低了维护成本，而且为用户提供了统一入口，否则的话，用户编辑一个项目，需要登陆4个系统，都修改一遍，效率过低。

参考文档

开源分布式配置中心选型[1]

关于 Nacos 的整理[2]

总结

配置中心和注册中心是一个公司基础架构中的重中之重，当前生产运行时的所有配置都跟这个息息相关，完善的备份策略和高可用集群架构的选型和设计都要慎重再慎重。另外就是安全层面的考虑，什么角色能看到什么样的信息，都要有一个比较好的规划(虽然很多时候生产环境的集群用户并不能直接登陆)。

引用链接

[1] 开源分布式配置中心选型: http://suo.im/5w0B9j [2] 关于 Nacos 的整理: https://yulei.vip/2018/08/29/hello-nacos/