1.前言配置中心的诞生与项目架构的演变密切相关。传统单体应用存在部署效率降低、团队协作效率差、系统可靠性差、维护困难、随着规模扩大新功能上线周期长等潜在缺陷。因此，迫切需要一种新的架构来解决这些问题，微服务（microservices）架构是当下比较流行的解决方案。然而，在解决一个问题的同时，我们往往会面临很多新的问题，所以微服务化的过程中伴随着很多挑战，其中之一就是服务（应用）配置。(1)当系统从单个应用拆分成分布式系统中的各个服务节点时，配置文件也必须迁移（拆分），这样配置就分散了，每个服务都有自己的配置。随着项目需求的不断增长和发展，配置也会越来越多。最后，繁琐的配置文件会让你越来越崩溃。如果不注意配置错误，还得修改配置，重新打包部署，很麻烦。(2)在集群部署的情况下，如果新版本的配置会对系统产生很大的影响，我们往往会选择灰度发布，即先发布部分服务器，进行测试，然后再同步配置到所有如果服务器还是使用传统的方式，那么我们需要一个一个地修改配置文件，然后重启服务。虽然不用我们自己开发做，但是有运维，还是挺烦的。运维发布后，我们还要检查他改的是否正确，费时费力。(3)而且，在系统不断迭代的过程中，一些配置在多个服务之间是相同或相似的，会存在很大的冗余。因此，在分布式、微服务的大环境下，传统项目配置方式的弊端逐渐凸显。这个问题变得非常棘手，急需管理配置和治理配置的解决方案。这时候，配置中心就应运而生了。2、配置中心v1（Config）哔哩哔哩从2017年开始着手配置中心的研发。希望能解决配置的统一管理、配置的订阅和热更新、服务透明接入等问题。2.1统一管理页面配置中心v1提供统一的配置管理后台，对不同环境、不同应用进行权限隔离，实现操作配置方便、安全。在功能上，它提供了公共配置、配置搜索等功能。2.2高可用Config采用Admin广播的形式，在可用性方面同步集群内各节点的数据；在性能方面，它采用了两种存储方式：MySQL存储和磁盘存储。MySQL用于持久化存储，磁盘主要是加快访问速度。读取配置时，服务先读取本地磁盘数据，如有遗漏，则直接读取数据库缓存到内存中。2.3配置订阅配置中心v1在配置订阅时采用长轮询（longpolling）的方式实时监听配置变更通知。如果没有变化，30秒后返回304，有变化则立即返回。具体流程如下：2.4业务透明配置中心对外提供统一的SDK，用户可以通过SDK直接访问配置中心。同时还提供了SDK订阅和阅读接口，用户可以根据自己的需要实现各个接口。2.5限制v1通过Redis记录客户端请求信息，供用户查看用户订阅状态。由于一些业务客户的客户较多，如果请求数量较多，会增加返回时间；OpenAPI对外开放，导致很多不在管理范围内的SDK不受管控，给后续的接口升级带来很大的阻力；v1的配置采用广播方式发布数据，任何一个节点宕机，很难保证节点间数据的一致性；配置中心v1为集中式集群，不支持多活部署，无降级方案，可靠性低；v1不验证配置，经常出现用户配置格式问题，导致版本发布后解析错误，无法启动业务服务。3、配置中心v2（Paladin）已经在配置中心v1上使用了很多年。随着公司规模和业务的不断扩大，越来越多的业务形态出现，原有的配置中心已经不能满足当前的需求。业务需求，而配置中心v1版本也有一定的局限性，于是配置中心v2应运而生。v2主要解决以下问题：3.1配置生命周期管理和配置简化Config独立管理配置和版本，导致变更发布和管理困难，配置生命周期管理困难，新用户学习成本高。Paladin将配置直接绑定到组中，配置不再有独立版本。配置变更只有发布后才会有变更记录。版本的迭代和回滚都是在group维度进行的，不在group版本的配置就是生命周期的结束。同时大大简化了配置变更和发布的流程，降低了用户的成本。3.2配置隔离在Config中，配置的隔离性不明显，很容易因为改变一个区域的配置而改变所有区域的配置。Paladin中的配置隔离分为租户（Tenant）隔离、命名空间（Namespace）隔离和组（Group）隔离。用户可以根据自己的业务维度对租户进行配置和隔离，比如：直播业务、电商业务、游戏业务等都可以作为独立的租户。命名空间隔离是业务基于不同环境、地域、功能的租户隔离的第二级隔离。用户只需保证同一租户下的命名空间全局唯一即可保证配置隔离，如：电商业务：测试环境-上海地区-支付功能。组隔离是基于租户和命名空间的第三级隔离。用户可以根据自己的需要使用不同的组。组间的自定义配置是相互独立和隔离的，不会因为更改一个配置而引起。其他分组配置更改。如下图，Tenant默认为public，Namespace为Env、Zone、App的组合，Group为分组；业务可以据此进行隔离。3.3增量发布和读取在大多数情况下，应用程序的配置变化是局部文件变化，以及大文件变化和多客户端订阅。如果全量推送，会占用大量带宽。在Paladin中，版本信息和配置信息是独立存储的。版本信息Message保存了该版本所有配置文件信息的列表。配置文件信息包括配置ID、变更状态、配置内容的校验和。以及配置信息的存储密钥（KeyLink）。发布配置时，Portal会将变更后的配置与最新发布生效的配置进行合并，实现增量发布。SDK可以根据每个配置文件的变化状态信息或者根据本地缓存和最新的Checksum来判断配置是否需要更新，从而实现读增量。3.4提高QPS和推送延迟Paladin采用缓存来提高QPS和推送延迟。如下图，缓存层分为两部分，一部分是LRU缓存，用于存放配置内容，主要用于加快配置读取。另一部分是通知缓存。为了提高通知性能，Paladin不再使用Redis作为推送缓存，而是使用HashMap作为缓存，将各个Namespace下的配置存储在同一个Key下。如果有更新，会通知租户和命名空间下的所有组，服务根据订阅的Label决定是否通知Client，大大提高了通知的效率和可扩展性。3.5同一集群内各节点数据一致性Paladin并没有像v1那样采用广播的形式进行数据同步，而是使用Raft协议[1,2]来保证集群内各节点数据的一致性和高可用集群。保证正常情况下一半以上的节点可以正常读写数据。复制状态机架构如下图3.6高可用为了实现多活部署，在模块设计上，Paladin：（1）将基础数据层（Node）分离成一个服务，与数据库等基础组件，并完整保存所有用户配置（某个历史版本），只提供客户端配置获取和变更监控。(2)Portal定位为业务逻辑层，保存配置的历史数据、用户信息、权限等，同时也与公司内部其他三方系统统一对接，提供所有配置管理所需的元信息；(3)Admin组件只封装了核心的配置修改、发布等接口和权限管理的支持，对外提供统一的OpenAPIs。数据同步：Paladin采用单数据库中心，多集群部署方案。持久数据存储在数据库中。配置发布时，Portal会同步发布数据到各个Node集群，保证各个集群的数据同步。通过anycast保证各个机房的服务读取就近机房的配置中心配置。一个机房配置中心宕机后，可以切换到其他机房读取相应的配置，保证容灾和降级。这样可以保证：（1）如果Admin失败，前端只需要连接其他Admin服务即可保证业务的连续性。(2)如果Portal出现故障，Admin可以重新连接其他Portal服务，对外提供服务。(3)如果一个Node发生故障，每个节点都有一份完整的配置副本，客户端可以重新连接到区域内的其他节点。(4)如果一个Node集群出现故障，该服务会自动降级到其他配置中心集群读取配置。3.7客户端订阅连接多路复用在新的业务应用中，用户会遇到单一服务监控多个组或应用的情况。因此，SDK支持连接复用，帮助简化用户操作。同时，为了避免像v1这样不可控的SDK，Paladin团队会维护所有语言的SDK。对于不支持的语言，Paladin提供物理机Agent和K8sSidecar将配置写入服务自定义目录。这样可以有效控制Paladin的SDK版本和后续的迭代升级。4.功能特点借鉴Config的反馈，Paladin提供了更多的功能和特性来满足新的业务需求，包括：4.1非感知接入Paladin提供应用配置，对于站内业务形态也是由配置中心完成B无意识访问。当应用满足相应条件时，业务可以直接在PaaS平台上创建并部署自己的业务，无需担心配置中心的存在，方便业务使用。帕拉丁是怎么做到的？配置中心的应用配置规定了一套使用标准，PaaS平台根据标准直接将相应的应用参数注入到应用容器的环境变量中，业务无需关心与应用之间的联动配置中心和PaaS在使用相应的默认配置参数时开箱即用。4.2平台空间Paladin支持平台空间能力，允许不同的平台利用配置中心的高可用、高容灾能力和稳定的配置下发通道，构建相应的平台空间。平台空间不能被普通业务直接感知，以类似可扩展插件的方式提供。现已对接B站新一代ABTest平台和服务治理平台。我们以ABTest平台为例。业务可以根据自身的产品测试需求，在ABTest平台上进行A/B测试配置，并发布到平台上。业务可在其ABTest平台空间获取A/B配置。可以有效降低业务感知和接入不同平台的复杂度。4.3Keyspace配置配置中心会涉及到网关等中间件的各种应用，如果每个应用在使用网关等中间件时都需要进行配置，或者对相应的SDK进行大量的配置，那么会非常庞大??。这增加了服务接入的复杂度，同时如果中间件升级，所有的接入服务都需要做相应的改动，增加了不必要的成本。Paladin针对这个问题引入了Keyspace配置。该配置不再涉及应用问题，可以集成到中间件SDK中，业务应用只需要引用对应的SDK即可接入。同时，中间件也可以根据不同的需求或功能改变指定的配置，角色与指定的业务相关。这样会大大降低接入和迭代的难度。4.4配置格式验证Paladin支持xml、toml、yaml、json等10多种格式，配置解析时如果配置格式错误，客户端将无法解析。因此，配置中心会对配置进行格式校验，可以有效防止人为操作导致的配置问题。4.5权限管理配置的变更将直接影响应用服务，重要服务的配置变更可能产生不可估量的后果。在权限管理方面，Paladin支持用户权限管理、OpenAPI权限管理，也支持变更通知和发布审核通知。4.6版本控制和回滚当用户需要回顾配置时，可以通过版本历史和版本对比查看历史上各个版本的配置，通过对比功能可以直接查看版本之间的差异。如果配置变更不符合预期，还可以通过回滚操作将配置回滚到指定版本。4.7颜色释放Paladin提供了颜色释放的能力。当配置变动影响较大时，用户可以通过染料发布的方式在部分实例上发布最新的配置，测试是否达到预期。如果满足所有实例，如果不满足，可以直接取消染色，回到之前的配置。配置中心色彩发布与公司服务管理平台已全面打通，支持相关多通道能力建设。比如配置中心与PaaS平台的联动，可以实现发布染色服务、读取染色配置等一整套流程。4.8增量发布读取Paladin提供增量读取配置。一个配置版本可能包含多个未改变的配置，客户端只需要加载改变的配置即可。4.9模板配置Paladin也支持模板配置。对于中间件或者其他公共服务SDK，需要的配置格式是固定的，大部分的Values也是固定的。这时候中间件就可以创建相应的模板，其他使用这个中间件的应用程序只需要引用模板即可，可以减少因每个用户的理解不同而导致的配置问题。4.10复制和导入Paladin可以使用导入或复制功能直接操作不同区域之间的配置，可以有效防止人为操作导致的配置错误。4.11命令行运维工具为了更好的提供运维服务，Paladin可以只运维Node组件，有利于运维，也可以在Admin和Portal无法有效提供服务时做应急运维.5.性能作为一项基础服务，圣骑士的性能也是考察该服务的重点。配置中心本身就是一个多读服务。在48核2.8GHZ服务器，单节点30万配置情况下，可同时连接6.5万个客户端，平均推送时间小于40毫秒。在相同服务器和配置的前提下，10000个客户端同时监听一个配置文件的变化，需要的推送时间也在600毫秒以内。六、展望配置中心是微服务基础设施中不可或缺的核心组件。后续我们会继续研究配置中心的应用模式和场景。在功能方面，Paladin基本上涵盖了配置的大部分使用方法。未来我们将进一步优化用户体验，抽象feature/vars等场景能力，进一步优化大模型数据的分发性能，并结合公司容器平台正在研究适配K8s来替代相应的ETCD并制作努力提高相应的绩效。现代微服务架构和云原生环境对应用配置管理提出了更高的要求。配置驱动资源正在成为云计算的重要技术趋势。所有与云计算相关的资源都可以通过配置来驱动[3]。未来我们也会研究如何与云服务平台上的其他服务进行集成。参考文献[1]https://github.com/hashicorp/raft[2]https://pages.cs.wisc.edu/~remzi/Classes/739/Spring2004/Papers/raft.pdf[3]https://aws.amazon.com/cn/blogs/china/technical-selection-and-landing-practice-for-building-a-cloud-native-configuration-center本期作者王宗宝哔哩哔哩高级开发工程师陈碧仁哔哔哩哔哩高级开发工程师
