容器云服务配置中心设计

作者：汪照辉 王作敬 中国银河证券股份有限公司 信息技术部IT研发中心

摘要

容器云平台仅仅是个基础设施，在其上基于容器部署运营的服务或微服务才是客户关注的重点：业务应用。容器化、微服务化、分布式化下的应用服务配置是业务应用服务生态中重要的一环。实现服务配置的解耦合、独立部署，是构建服务、微服务生态的重要基础。容器云服务配置中心设计从不同需求场景分析潜在需求，提出服务配置中心可行设计方案。

采用容器云后，面对的一个问题就是应用的服务化或微服务化。服务在容器中运行，服务的配置和服务配置的运行时更新成为一个需要面对的问题。这里的服务配置，我们指的是应用服务的参数配置。服务参数配置是容器云服务化管理中重要的内容之一。

在交流过程中，我们也谈到了这个问题，目前大多数使用配置文件，部署时上传到容器中的文件目录下，再由容器中的服务读去这个配置文件。这种方式简单，但无法实现运行时配置参数的动态更新。

在我们ESB服务化的过程中，我们也设计实现了一个服务参数全局配置中心。基于我们ESB的实践经验，把我们ESB服务配置中心的设计思想，在此与大家分享，来设计实现容器云服务配置中心。

一、服务配置中心场景需求

首先我们还是来看有哪些需求场景：

（一）解耦合需求

容器云平台是一个基础设施，其上部署运行的应用和服务是独立的个体，他们之间不能耦合在一起。所以配置中心最好把容器云平台配置和其上部署运行的应用服务配置隔离。这是两个完全不同的层次。

其实这也是我们在实现产品化时需要认真考虑的问题。就象微服务拆分一样。容器云平台的功能和实际的业务应用是两个独立的部分，这个一定要分清楚。不要把容器云配置和微服务配置糅合在一起。容器云平台的参数配置，在容器云平台提供配置选项即可，如果想提供一个UI，也未尝不可，这个UI是提供给容器云平台管理员的，租户用户是不可以访问的，所以不能和业务应用服务配置放在一起或者放在一个组件里。另外平台的配置很少频繁修改，和应用服务的配置放在一个组件不合适。

所以，我们这里的需求就是，应用服务的参数配置中心是独立于容器云平台的一个独立组件，不仅可以服务于容器云平台，也可以服务于其他服务化甚至是非服务化平台。

（二）中心化管理需求

采用容器化，一个服务的服务实例可能有几个、几十个、甚至几百个，同一服务的所有服务实例应该共享一套配置数据。这个配置数据需要做到唯一来源。不管是通过配置文件，或者通过etcd，或者JMS，或者其他，必须有一个中心化的管理终端，比如提供一个UI，由这个配置管理UI来统一配置管理下发配置参数数据给所有的服务实例。

我们ESB使用一个xml配置文件来管理所有的配置选项，没有提供一个UI界面。每个ESB服务也会涉及多个服务实例的问题，配置中心会监控这个xml配置文件的更新，然后统一下发给所有相关的服务实例。

（三）运行时动态更新需求

实际的业务应用运营过程中，往往要求不能重启应用服务，在运行时修改配置参数，实现业务流程的动态变化。最简单的比如日志级别的改变需求。业务运行中如果有什么异常，如果想调整日志级别，比如打开debug日志，查看更详细的日志，你很难说把这个服务停掉，修改日志配置参数，然后再启动。不但麻烦，也往往难以重现异常，重启之后问题可能就消失了。再比如一些开关配置，容错保护机制等，都可以通过这样的配置调整来实现。所以我们需要在运行时支持应用服务配置参数的动态更新。

（四）延迟需求

支持运行时动态更新，这里涉及到更新的延迟下发问题。服务能够容忍多长的延迟，是我们在实现服务配置中心时需要重点考虑的一个问题。不同业务需求对延迟时间的长短要求是不一样的，要满足这个延迟性需求，就需要考虑最小的延迟需求。通常毫秒级的延迟足以满足大部分业务需求。我们ESB的服务配置中心设计支持毫秒级的延迟需求，同时可以方便的切换到其他平台以支持微妙级的需求。但是，实际使用过程中，我们调整为秒级的延迟支持。由于我们使用的是配置文件，未提供统一的UI管理，对配置文件的更新做到秒级响应，足以满足我们的需求。适用就好，性能要求越好，付出当然也需要越多。

（五）服务多版本支持需求

这可能是灰度发布、发布回滚、历史配置查询等方面的需求。这一块在我们看来，并不是我们关心的重点，和我们整个服务配置中心的设计也不矛盾，但并不保存历史记录，愿意保存的话可以自己扩展，也很简单。

我们ESB把同一服务的不同版本做为不同的服务来看待，所以他们的配置选项是独立的。每个服务有一个唯一的ID标示，这个ID可以包含服务的版本信息。ID的规则可以定义根据实际的需求来确定。目的是简化服务的版本管理问题。

（六）本地备份，配置中心宕机不能影响服务运行、重新启动需求

应用服务第一次启动时，需要连接到服务配置中心，接收服务配置中心对于本应用服务的配置参数数据。然后需要把这些配置数据备份到本地（比如磁盘文件），这样，即便时配置中心服务器维护、宕机、网络故障等原因导致应用服务不能连接到服务配置中心，也可以检查使用本地配置来正常启动。

使用本地备份，可能存在本地备份和配置中心配置数据不一致的问题。这要求应用服务实例在每次启动时需要首先尝试连接到配置中心，接收配置中心的配置数据，备份到本地。如果无法连接到配置中心，则使用本地备份的配置数据来初始化服务启动服务。如果读去本地配置也失败，则需要告警退出。

（七）容器迁移问题

容器迁移时，其实相当于部署一个新的服务实例。容器迁移时会删除旧的容器，在新的主机上重建新的容器。重新执行服务的初始化启动过程，连接到服务配置中心获取配置数据，备份到本地，启动服务。

（八）租户隔离需求

基于容器云平台的服务化部署，面对着不同租户的隔离需求。这也是我们在租户及权限中心设计中提到的需求。

容器云平台对各组件需要实现统一的权限管理，就是我们所说的集中权限中心。每个租户登录到各组件都只能管理他自己的资源和应用服务，由权限中心统一管控。

（九）Password密码处理需求

密码几乎无处不在。密码安全管理是我们在业务运营过程中一个重要的工作任务。Docker提供了Docker Secret机制。跟阿里的专家交流过程中了解到，Docker Secret是以加密的形式存于系统中，具体什么地方他们也不知道，不过镜像部署之后，密码会以明文的形式存储于容器的目录中。

我们ESB没有docker，所以不是这种方式。密码以加密后的格式存储于文件中，服务在取得密码后在使用前解密，直接映射到接口密码输入参数。明文密码会在内存中（一次解密，不是每次使用时解密），但不会落盘或存于数据库中。密码传输过程中都是加密后的格式。服务调用协议层也可根据实际考虑是否数据密文传输。我们ESB是内部集成，所以未采用协议层加密，采用了其他安全手段。

（十）多环境支持问题

这个可以考虑通过租户隔离方案或者部署不同环境的配置中心实例来实现。我们的开发、测试、UAT等环境都是独立的，都有一套自己的配置中心、日志中心、管理中心、字典中心等组件。这样实现更好的隔离，也简化运维的复杂度。实现方式多种多样，立场不同，观点不同，难以评说好坏之分。根据公司文化、习惯、能力、业务要求等选择适合自己的方式就好。本人观点：四量拨千斤，用最简单的方法解决最复杂的问题！

二、配置中心设计

上面我们讨论了可能的场景需求，这部分我们分享下服务配置中心的设计。容器云服务配置中心由配置UI、配置服务、配置Client组件及配置数据通道（我们使用JMS Server）组成。用户（服务部署运维人员）通过统一的配置UI来配置更新管理其所有的应用服务。所有配置数据存储于配置服务端（可以是文件或数据库），同时在内存中保留一份配置数据，用于服务启动初始化是来查询其配置数据。配置服务通过JMS Topic来分发配置数据，一个服务的所有服务实例监听同一个Topic，当用户更新配置，配置服务下发更新后的配置数据后，服务实例可以适时获取更新（JMS消息事件触发）。

在服务实例端，这里有两个流程：

1． 在服务启动时，初始化流程将使用JMS Queue来通过服务ID来查询服务配置参数数据。从配置服务Server获取到最新的配置数据，保存到内存中（性能效率方面考虑），同时启动一个线程把最新数据备份到本地。初始化完成，实际业务流程从内存中实时获取配置数据进行处理。

2． 启动一个配置监听器，监听JMS Topic上的消息，每个服务分配一个Topic，同一个服务的所有服务实例共同监听一个Topic。如果有配置更新，则更新服务实例内存中配置数据，同时启动一个线程把最新数据备份到本地。

业务服务从内存中读取配置数据。数据格式根据实际来确定，xml、Json、K/V等都可以，也可以同时支持多种格式的数据。

根据服务实例的需求，配置服务也有两个流程：

1．处理配置数据的分发，发布到JMS Topic.

2．处理服务实例的JMS Queue请求，根据服务ID返回服务配置数据。

当然配置服务需要支持UI操作。

JMS Server也可以替换为Kafka，etcd等工具。根据实际选择合适的。我们选择JMS是历史原因。

三、配置中心定位

配置中心组件只是个工具，我们不要期望它能解决所有配置问题，也不应该要求它解决所有配置问题。它只是简化我们应用服务的配置管理。不同的定位，配置中心边界不同，如果你想把服务的管理治理、容器云平台的配置管理等都加进来，也不是不可以，但人为复杂化了。服务API有专业的API管理工具，服务治理更是服务运营管理中是非常大的一个方面，需要结合API management和API Gateway、日志、监控等工具组件来实现。容器云平台配置更是和业务应用配置是两个层面的需求，不建议混为一谈。

最后需要说明一下的是，配置中心的思想并不是我的原创，这是原TIBCO大中华区架构师Vincent Lam的思想，也基于我们的实践，在此整理分享。Vincent教了我们很多东西，我们在此也非常感谢他的指导和帮助。同时也希望给大家一些启发，能够对大家有所帮助。

更多相关文章请点击阅读原文

长按二维码关注公众号