很多人在一开始理解性能治理（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 不同维度的比照：
| 比照维度 | 配置核心 | 配置核心 |
|---|---|---|
| 应用场景 | 自定义结构化配置，满足对线上疾速变更。 | <li> 继续集成 <li> 部署和公布解耦 <li> 渐进式公布 <li> 定向投放 <li>A/B 试验 <li> 预案降级 |
| 用户角色 | 开发人员、QA。 | <li> 开发人员、<li>QA<li>PM<li>SRE<li> 经营人员。 |
| 零碎复杂性 | 较高，以纯文本、JSON 或 K/V 形式治理，须要针对配置内容定制开发满足不同需要。 | 较低，可视化配置，大部分性能治理场景开箱即用。 |
| 可观测性 | 须要自行定制开发监控逻辑。 | 能够实时监控性能拜访状况并对性能进行成果评估 |
| 变更疾速失效 | 反对。 | 反对，利用下发通路实现规定疾速失效。 |
| 须要定期清理 | 很少，大多数配置和业务耦合性较高，须要配合业务长期应用。 | 常常，大多数性能开关都是短期性的，在应用实现后即可清理。 |
以后 FeatureProbe 作为一个 Feature Management 平台曾经应用 Apache 2.0 License 协定齐全开源，你能够在 GitHub 和 Gitee 上间接拜访源码，你也能够在下面给提给咱们提 issue 和 feature 哦，咱们看到后会第一工夫回复大家。
GitHub: https://github.com/FeaturePro…
Gitee: https://gitee.com/featureprob…