微服务架构之「 配置中心 」

在微服务架构的系列文章中，前面已经经过文章《微服务架构之「服务网关 」》介绍过了在微服务中服务网关的原理和应用，今天这篇文章咱们继续来聊一聊微服务中另一个重要模块：「 配置中心 」。后面还会继续介绍 服务框架、服务监控、服务治理等。仍是那句话，只有将这些基础设施弄清楚了，微服务实践的道路才能走的稳、走的远。

「配置中心」，顾名思义，就是用来统一管理项目中全部配置的系统。虽然听起来很简单，但也不要小瞧了这个模块。若是一个中型互联网项目，不采用配置中心的模式，一大堆的各种配置项，各类不定时的修改需求，必定会让开发同窗很是头疼且管理十分混乱。我认为甚至能够直接用 “一个项目中是否有无采用「配置中心」” 这一粗略的条件，来判断一个互联网研发团队是否规范和成熟。

1、为何须要「配置中心」？

咱们先来看看在没有「配置中心」的传统项目中，咱们是怎么处理各种配置参数问题的：

1. 通常是静态化配置。大多数在项目中单独写一个配置文件，例如 "config.conf"，而后将各种 参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中须要使用配置的时候，就从这个配置文件中读取。这种作法虽然简单，但若是参数须要修改，就很是的不灵活，甚至须要重启运行中的项目才能生效。相信大多数开发同窗都深有体会。

2. 配置文件没法区分环境。因为配置文件是放在项目中的，可是咱们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每个环境所使用的配置参数理论上都是不一样的，因此咱们在配置文件中根据不一样环境配置不一样的参数，这些都是手动维护，在项目发布的时候，极其容易因开发人员的失误致使出错。

3. 配置文件过于分散。若是一个项目中存在多个逻辑模块独立部署，每一个模块所使用的配置内容又不相同，传统的作法是会在每个模块中都放一个配置文件，甚至不一样模块的配置文件格式还不同。那么长期的结果就是配置文件过于分散混乱，难以管理。

4. 配置修改没法追溯。由于采用的静态配置文件方式，因此当配置进行修改以后，不容易造成记录，更没法追溯是谁修改的、修改时间是什么、修改前是什么内容。既然没法追溯，那么当配置出错时，更没办法回滚配置了。

上面只是拿配置文件的形式来举例，有的项目会采用数据库配置，虽然灵活一点，可是依旧不能彻底解决上述问题。既然传统的项目配置有这么多弊端，那咱们看看「配置中心」的方案是如何解决这些痛点的：

「配置中心」的思路就是把项目中各类配置、各类参数、各类开关，所有都放到一个集中的地方进行统一管理，并提供一套标准的接口。当各个服务须要获取配置的时候，就来「配置中心」的接口拉取。当「配置中心」中的各类参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

那么，按照上述思路，咱们理想中的「配置中心」应该具有以下特色：

• 配置集中管理、统一标准

• 配置与应用分离

• 实时更新

• 高可用

具备上述特性的「配置中心」是如何解决上面传统配置所面临的问题的呢？

1. 采用“配置集中管理”，能够很好的解决传统的“配置文件过于分散”的问题。全部的配置都集中在配置中心这一个地方管理，不须要每个项目都自带一个，这样极大的减轻了开发成本。

2. 采用“配置与应用分离”，能够很好的解决传统的“配置文件没法区分环境”的问题，配置并不跟着环境走，当不一样环境有不一样需求的时候，就到配置中心获取便可，极大的减轻了运维部署成本。

3. 具有“实时更新”的功能，就是用来解决传统的“静态化配置”的问题。线上系统须要调整参数的时候，只须要在配置中心动态修改便可。

4. 既然配置都统一管理了，那配置中心在整个系统中的地位就很是重要了，一旦配置中心不能正常提供服务，就可能会致使项目总体故障，所以“高可用”就是配置中心又一个很关键的指标了。

2、「配置中心」的原理与应用？

经过上面的介绍，其实就能够了解到「 配置中心 」的原理不是很复杂。其核心功能也很少，主要是：

1. 实现配置的记录

2. 实现配置的读取、更新、取消

3. 实现配置的查看

可是围绕着这几个核心功能，咱们还须要保障高可行、要实现实时更新、要能方便的使用，还但愿有权限管理的功能、操做审计的功能等等，加上这些周边辅助功能以后，一个完善的「 配置中心 也就不那么简单了。

咱们再来看一下在实际项目中如何去选型和应用：

虽然配置中心的核心原理并不复杂，咱们能够根据原理本身去实现一个配置中心，可是若是没有特殊需求，仍是不建议重复造轮子了，毕竟业内已经有不少成熟的开源方案能够直接选用了。下面就列举几个比较热门的配置中心开源组件给你们参考：

• Apollo

  Apollo是由携程开源的分布式配置中心。

  Apollo的特色有不少，好比：配置更新以后能够实时生效，还能够支持灰度发布功能。而且能对全部的配置进行版本管理、操做审计等功能，提供开放平台API。另外因为Apollo使用的人不少，因此网上的资料也很是的丰富，而且github上资料也写的很详细。

  上面便是Apollo的基础模型，看结构很简单。可是其功能不少，以前说过配置中心对高可用的要求很高。下面能够继续看一下Apollo的架构：

• 更多的Apollo资料能够直接去github上查看，能够说官方文档是很是体贴的。

• Spring Cloud Config

  看名字就知道，这是Spring Cloud中带的配置中心组件。也正是这个缘由，因此它和Spring是无缝集成，使用起来很是方便。而且它的配置存储支持Git，不过它没有可视化的操做界面，配置的生效也不是实时的，须要重启或去刷新。因此比较适用于小型项目快速上手。

  Spring Cloud Config包含了Config Client和Config Server两部分，Config Server 实现配置文件的存储，对外以接口的形式提供获取配置文件，而后Config  Client经过这些接口获取数据。

• Disconf

  Disconf是由百度开源的分布式配置中心。其实不少一线大厂都有开源本身的配置中心组件，这里挑出百度的Disconf也是由于网上比较火热，易用性也还不错，项目也是托管在github上很容易找到。它是基于Zookeeper来实现配置变动后实时通知和生效的。

以上，就是对微服务架构中「 配置中心」的一些思考。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。😊

本文原创发布于微信公众号「 不止思考 」，欢迎关注。涉及 思惟认知、我的成长、架构、大数据、Web技术 等。