微服务为什么要配置中心?

一、介绍

在系统架构中，和安全、日志、监控等非功能需求一样，配置管理也是一种非功能需求。配置中心是整个微服务基础架构体系中的一个组件，如下图，它的功能看上去并不起眼，无非就是简单配置的管理和存取，但它是整个微服务架构中不可或缺的一环。另外，配置中心如果真得用好了，它还能推动技术组织持续交付和DevOps文化转型。

本文介绍在分布式微服务环境下，应用配置管理背后的业务需求，配置的各种分类和一些高级应用场景。

二、配置定义和形态

配置其实是独立于程序的可配变量，同一份程序在不同配置下会有不同的行为，常见的配置有连接字符串，应用配置和业务配置等。

配置有多种形态，下面是一些常见的：

• 程序内部hardcode，这种做法是反模式，一般我们不建议！
• 配置文件，比如Spring应用程序的配置一般放在application.properties文件中。
• 环境变量，配置可以预置在操作系统的环境变量里头，程序运行时读取，这是很多PaaS平台，比如Heroku推荐的做法，参考12 factor app[附录9.1]。
• 启动参数，可以在程序启动时一次性提供参数，例如java程序启动时可以通过java -D方式配启动参数。
• 基于数据库，有经验的开发人员会把易变配置放在数据库中，这样可以在运行期灵活调整配置，这个做法和配置中心的思路已经有点接近了。

三、传统应用配置的痛点

在没有引入配置中心之前，一般企业研发都会面临如下痛点：

1. 配置散乱格式不标准

有的用properties格式，有的用xml格式，还有的存DB，团队倾向自造轮子，做法五花八门。

2. 主要采用本地静态配置，配置修改麻烦

配置修改一般需要经过一个较长的测试发布周期。在分布式微服务环境下，当服务实例很多时，修改配置费时费力。

3. 易引发生产事故

这个是我亲身经历，之前在一家互联网公司，有团队在发布的时候将测试环境的配置带到生产上，引发百万级资损事故。

4. 配置缺乏安全审计和版本控制功能

谁改的配置？改了什么？什么时候改的？无从追溯，出了问题也无法及时回滚。

四、现代应用配置核心需求

近年，持续交付和DevOps理念开始逐步被一线企业接受，微服务架构和容器云也逐渐