Choerodon 的微服务之路（四）：深入理解微服务配置中心
▌文章的主要内容包括： - 配置是什么 - 为什么需要微服务配置中心 - Choerodon的配置中心
在早期单体应用的时代，监控等系统配置管理可能并不是什么困难的问题。但是在微服务架构中，和安全、日志、非功能需求一样，配置管理也是一种非功能需求。配置中心也是整个微服务架构体系中的一个重要组件，即使它的功能看上去并不起眼，无非就是简单配置管理和存取，但它是整个微服务架构中不可或缺的一环。
在Choerodon的微服务体系中，如何通过更加高效的配置管理方式，帮助微服务系统进行配置规划，推动项目的持续交付，动态调整和控制系统的运行状态，这些问题都值得深入思考和研究。
配置是什么
在讲配置中心之前，首先提到一个核心的概念，就是服务的“配置”。配置可能各位都不陌生，一个配置项大多是key-value的形式，value可能是一个有限值的集合。Choerodon通过这些配置项，来控制系统的运行状态，可以说，配置其实是独立于程序的可配变量，同一份程序在不同配置下会有不同的行为。
常见的配置有如下几种：
- 程序内置的硬编码：在开发过程中将配置写死，这种形式几乎不具备任何的扩展性可动态修改的能力。通常是不建议的！
- 程序配置文件：Springboot提供了一种方式将配置放在application.properties或者application.yaml文件中，系统运行时的大部分配置，都可以通过这种格式进行配置。不同环境会有各自的配置文件。
- 环境变量：将配置预制在操作系统的环境变量中，在程序运行时读取。尤其在docker容器中，不同容器间相互隔离，环境变量不会受到影响。
- 启动参数：可以在程序启动时制定参数，修改时需要重新启动。
- 数据库存储：易变化的配置存储在数据库中，这样在运行期可以灵活的调整。
而微服务的配置中心，将散落在各处的应用系统配置信息收集起来，进行集中式的统一管理，并且提供额外功能，如动态刷新，版本控制，功能开关等。
举一个简单的例子，有这样的一个配置：logging.level。在生产环境上的日志级别通常为error级别，但是在一些测试环境，或者当系统出问题时，开发人员会期望日志的级别为debug，此时则需要一种机制来帮助实现。
为什么需要微服务配置中心
既然已经有了这么多种形式来管理配置，又为什么要引入配置中心呢？
在传统单体应用中，开发者将系统打成一个包，并在包里提供一些配置，当需要修改配置时，只需要登录到服务器上将配置修改，然后reload一下就可以了。
在微服务体系中，服务的数量以及配置信息日益增多，比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等，显然开发者已经不可能登录到一台台虚拟机中，对配置进行修改重启，并且，传统的配置管理可能会带来如下的一些问题：
- 配置的格式不一致：有的使用xml，有的使用properties，还有一些存在数据库中，不同项目对于配置的管理方式五花八门。
- 失效性低：配置大多使用静态文件的格式，再通过打包放入容器中运行。当实例过多时，需要修改完配置重新打包，周期较长。
- 不安全：配置跟随源代码保存在代码库中，容易造成配置泄漏。同时不同环境的配置不同，稍不注意，可能会将测试环境的配置带入生产环境，引发事故。
- 功能局限：不支持动态调整。
同时，随着“微服务+容器化+DevOps”落地，对于服务的配置管理也提出了更高的要求。
- 代码与配置分离：遵循“一次打包，多处部署”的原则。将代码和配置分离。配置单独管理。
- 配置抽象：屏蔽后台实现，提供页面管理功能。
- 跨环境跨集群：支持对多环境和多集群应用配置的集中式管理。
- 实时性：配置更新需要尽快通知到客户端。
- 可治理：配置审计、版本管理、权限控制。
所以，一个能够方便用户进行自助式的配置管理，标准化的配置中心服务，是Choerodon社区里的开发者急切所需的。
Choerodon的配置中心
配置分类
在Choerodon猪齿鱼中，将服务的配置按照不同的功能，大致分为3类。
- 静态配置：程序打包前一次配置好，一般不会修改。这些配置通常在服务启动之前生效。如：服务的端口，名称，配置中心的地址等。
- 部署时配置：程序在部署时添加的配置，一般和环境相关，每个环境不同。如：数据库配置，其他中间件配置，或者一些服务相关的配置。
- 运行时配置：程序运行时可能会修改的配置，一般用来调整应用的行为和功能。如：日志级别，功能开关，线程池大小等等。
服务配置设计原则
对配置进行分类之后，还需要一种设计原则，来指导开发者对服务的配置进行划分。在Choerodon猪齿鱼中，开发者遵循下面的一些原则。
- 所有可能要修改的配置，都不应该采取硬编码的方式。
- 程序中的配置文件，均使用yaml文件进行管理。
- 引入spring-cloud-config-client，将服务名，端口号，管理端口，等不会修改的配置，添加在src/main/resources/bootstrap.yml，如下所示：
# bootstrap.yml
server:
port: 8080
spring:
application:
name: iam-service
cloud:
config:
failFast: true
retry:
maxAttempts: 6
multiplier: 1.5
maxInterval: 2000
uri: localhost:8010
enabled: false
management:
port: 80381
security:
enabled: false
security:
basic:
enabled: false
- 将服务运行中需要的配置添加在src/main/resources/application.yml。包括注册中心的地址，数据库连接，并为这些配置添加默认值，如下所示：
# application.yml
spring:
datasource:
url: jdbc:mysql://localhost/iam_service?useUnicode=true&characterEncoding=utf-8&useSSL=false
username: choerodon
password: 123456
eureka:
instance:
preferIpAddress: true
leaseRenewalIntervalInSeconds: 10
leaseExpirationDurationInSeconds: 30
metadata-map:
VERSION: v1
client:
serviceUrl:
defaultZone: http://localhost:8000/eureka/
registryFetchIntervalSeconds: 10
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 15000
ribbon:
ReadTimeout: 5000
ConnectTimeout: 5000
mybatis:
mapperLocations: classpath*:/mapper/*.xml
configuration: # 数据库下划线转驼峰配置
mapUnderscoreToCamelCase: true
- 开发阶段，每个开发人员自己的本地配置，添加在src/main/resources/application-default.yml文件中，并且该文件不应该上传到代码库中，例如本地的数据库连接配置。
# application-default.yml
spring:
datasource:
url: jdbc:mysql://127.0.0.1:3307/iam_service?useUnicode=true&characterEncoding=utf-8&useSSL=false
username: username
password: pwd
- 配置的优先级遵循：环境变量>配置文件。通过Chart在部署时根据环境的不同，修改具体的环境变量值，来实现不同环境配置的不同，如下图所示：
- 对于紧要的配置修改通过配置中心修改，动态生效。对于实时性要求不高的配置，通过修改部署时的values重新部署生效。
配置中心实现
首先来看Spring Cloud自带的配置中心是怎么样的，如下图所示：
Spring Cloud Config将不同环境的所有配置存放在git 仓库中，服务启动时通过接口拉取配置。遵循{ServiceID}-{profile}.properties的结构，按照profile拉取自己所需的配置。
当开发者修改了配置项之后，需要结合spring config bus将配置通知到对应的服务，实现配置的动态更新。
可以看到，Spring Cloud Config已经具备了一个配置中心的雏形，可以满足小型项目对配置的管理，但仍然有着很多局限性。配置使用git库进行管理，那么git库的权限如何来判断？不同环境的安全性也得不到保障。配置的添加和删除，配置项的汇总，也只能通过git命令来实现，对运维人员也并不友好。
Choerodon猪齿鱼在Spring Cloud Config的基础上，将配置由git库存储改为由db存储。并且添加单独的manager-service来对配置进行管理。config-server则专注于将配置传递给服务。
同时，服务在部署的时候，通过猪齿鱼提供的工具包choerodon-tool-config将服务中的application.yml文件初始化到数据库中。在服务运行时通过前端来对配置进行操作，及时更新配置到各服务上，流程如下图所示：
同时可以在页面上依据已有的配置创建新的配置，并将配置应用给正在运行的服务实例。对于失效的配置文件，也可以在页面中删除。如下图所示：
Choerodon猪齿鱼通过配置中心管理服务配置的创建，生效，乃至销毁，并结合Chart来管理服务部署时的配置，通过这样的一种机制，满足了对服务配置整个生命周期管理的基本要求和配置版本、动态生效等进一步的需求。
总结
回顾一下这篇文章，整体介绍了配置中心在微服务架构中的作用，并提出了Choerodon对于配置管理的一些心得和规范。服务配置是服务运行起来的基础，而配置中心是整个微服务技术体系中的关键基础保障，如何做好服务配置规划，并推动项目的持续交付，则是Choerodon仍需持续考虑的问题。
关于猪齿鱼
Choerodon 猪齿鱼是一个全场景效能平台，基于 Kubernetes 的容器编排和管理能力，整合 DevOps 工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的平台，同时提供 IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：
作者：董凡
出处：Choerodon
欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文链接。