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猪齿鱼中，开发者遵循下面的一些原则。

1. 所有可能要修改的配置，都不应该采取硬编码的方式。
2. 程序中的配置文件，均使用yaml文件进行管理。
3. 引入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

1. 将服务运行中需要的配置添加在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

1. 开发阶段，每个开发人员自己的本地配置，添加在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

1. 配置的优先级遵循：环境变量>配置文件。通过Chart在部署时根据环境的不同，修改具体的环境变量值，来实现不同环境配置的不同，如下图所示：

1. 对于紧要的配置修改通过配置中心修改，动态生效。对于实时性要求不高的配置，通过修改部署时的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，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅 Release Notes 和 官网 。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网： http://choerodon.io
• 论坛： http://forum.choerodon.io
• Github： https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

本篇文章出自 Choerodon猪齿鱼社区 董凡。