Choerodon 的微服务之路（四）：深刻理解微服务配置中心

本文是Choerodon 的微服务系列推文第四篇，上一篇《Choerodon的微服务之路（三）：服务注册与发现》介绍了Choerodon的注册中心，并经过代码的形式介绍了 在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

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

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

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

7. 对于紧要的配置修改经过配置中心修改，动态生效。对于实时性要求不高的配置，经过修改部署时的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的微服务之路(一)：如何迈出关键的第一步
• Choerodon的微服务之路(二)：微服务网关
• Choerodon 的微服务之路（三）：服务注册与发现

关于Choerodon猪齿鱼

Choerodon猪齿鱼是一个开源企业服务平台，是基于Kubernetes的容器编排和管理能力，整合DevOps工具链、微服务和移动应用框架，来帮助企业实现敏捷化的应用交付和自动化的运营管理的开源平台，同时提供IoT、支付、数据、智能洞察、企业应用市场等业务组件，致力帮助企业聚焦于业务，加速数字化转型。

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信：Choerodon猪齿鱼
• 微博：Choerodon猪齿鱼

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