很多人在一开始了解功能管理（Feature Management）的时候，会疑惑功能管理与配置中心有什么区别，在这篇文章中我们来讲讲二者的区别，在对比两者之前我们先看下它们是什么、分别能解决什么问题以及常见的实现方案有哪些。
一、什么是配置中心？
通过配置中心将应用程序中结构化配置进行统一管理，当配置变更后能够在应用程序中实时生效，有效避免了传统模式下修改应用程序配置需要打包、部署、测试、上线等一系列繁琐流程。广泛用于如微服务应用架构下的配置管理、应用业务参数配置、文案配置等需要满足快速对线上变更的业务场景。
配置中心的具体实现主要有两大方向：自建或使用第三方组件。最简单的自建方案如将配置存储在数据库中，程序定时从数据库中加载最新配置以实现快速变更生效。也可以直接使用成熟且功能完备的第三方开源组件，如 Apollo、Nacos 等。
二、什么是Feature Management？
功能管理（Feature Management，也有译作特性管理）是管理「功能」生命周期的软件工程实践，它包含了渐进式发布、定向投放、A/B 实验、实时配置变更等针对「功能」粒度全生命周期管理。在持续交付实践中，它使我们能够做到让每一个变更都能独立部署，并通过渐进式发布来减少变更风险；能够感知到每一个功能在线上真实环境下用户的使用情况如何；能够清晰地看到新功能产生的业务价值等等。
一个完备的 Feature Management 系统不仅要实现「功能」的全生命周期管理功能，还要提供高效的「功能开关」规则下发和多语言客户端获取开关结果等能力，而国内原生支持功能管理实践的开源工具平台只有 FeatureProbe 。
三、两者的区别和关系
从上面定义不难看出两者主要区别是解决的问题不一样，配置中心解决的如何利用配置实现对线上快速变更，而 Feature Management 解决的是如何通过管理「功能」生命周期来实现对功能粒度的精准管控。
从技术角度来看，Feature Management 系统也需要实现对线上应用程序快速变更。例如当我们变更「功能开关」中人群放量规则后，Client 端（应用程序）需要能快速感知规则的变化来按最新配置规则执行放量处理，从这点来看 Feature Management 系统可以依托配置中心来作为开关规则下发链路的底层实现。
这也决定了两者系统组织结构上相似性，都至少需要由管理平台、下发通路及 Client SDK 组成，不同的地方在于两者的管理平台所提供的业务能力不一样。不过它们下发通路及 Client SDK 提供能力类似，对 Feature Management 而言需要下发开关（本质上也是一个配置）并为应用程序提供访问功能开关的 SDK，而配置中心同样也需要下发配置和为应用程序提供访问配置内容的能力。
四、两者相互是否具备替代性
既然两者部分功能上有一定的相似性，那是否具备替代性呢？
比如我们是否可以直接使用配置中心当成 Feature Management 系统来使用呢？其实前面有提到，配置中心作为通用配置平台并不关注配置内容，也就意味着你可以对配置做任何定义。以一个最简单功能开关场景为例，比如控制功能A开启或关闭，确实可以通过在配置中心上创建一个针对该场景的 K-V 配置当成开关来满足最基础的功能开关使用场景。
但这对于 Feature Management 系统来说是最简单的场景，还要做到对功能粒度的渐进式发布、将功能定向投放给特定人群、A/B 实验及对 Feature 进行价值评估等等，而都是作为配置中心所不具备的。
既然配置中心系统无法替代 Feature Management 系统，那反之用 Feature Management 系统替代配置中心是否可行？答案是肯定的。以 FeatureProbe 为例，在创建「功能开关」时支持4种开关返回值类型，分别是 Number、String、Boolean、JSON，意味着你可以在开关返回值中放上你原本在配置中心的配置内容，再利用 FeatureProbe 提供的 SDK 来获取相应的配置返回值即可。
五、总结
最后总结下配置中心与 Feature Management 不同维度的对比：
| 对比维度 | 配置中心 | Feature Management |
|---|---|---|
| 使用场景 | 自定义结构化配置，满足对线上快速变更。 | 持续集成、部署和发布解耦、渐进式发布、定向投放、A/B 实验、预案降级 |
| 用户角色 | 开发人员、QA。 | 开发人员、QA、PM、SRE、运营人员。 |
| 系统复杂性 | 较高，以纯文本、JSON 或 K/V 方式管理，需要针对配置内容定制开发满足不同需求。 | 较低，可视化配置，大部分功能管理场景开箱即用。 |
| 可观测性 | 需要自行定制开发监控逻辑。 | 可以实时监控功能访问情况并对功能进行效果评估 |
| 变更快速生效 | 支持。 | 支持，利用下发通路实现规则快速生效。 |
| 需要定期清理 | 很少，大多数配置和业务耦合性较高，需要配合业务长期使用。 | 经常，大多数功能开关都是短期性的，在使用完成后即可清理。 |