Helidon 4中RegistryFactory替代方案及Metrics API变更咨询

原RegistryFactory.getInstance().getRegistry(type)的替代实现 #

针对RegistryFactory的变更，有几种可行的替代方案：

• 直接使用Helidon Metrics API核心类
  改用io.helidon.metrics.api.MetricsFactory来获取注册表，这是最直接的替换方式：

  import io.helidon.metrics.api.MetricsFactory;
  import io.helidon.metrics.api.MetricRegistry;
  
  // 获取指定类型的注册表
  MetricRegistry registry = MetricsFactory.getInstance().registry(MetricRegistry.Type.APPLICATION);
  

• CDI注入（MicroProfile环境下）
  如果你的应用基于MicroProfile，可以通过CDI注入指定类型的注册表，配合@RegistryType qualifier：

  import jakarta.inject.Inject;
  import io.helidon.metrics.api.MetricRegistry;
  import io.helidon.microprofile.metrics.RegistryType;
  
  @Inject
  @RegistryType(type = MetricRegistry.Type.APPLICATION)
  private MetricRegistry appRegistry;
  

• 通过RegistryFactoryManager监听回调
  利用公开的RegistryFactoryManager注册监听，在工厂创建时获取实例：

  import io.helidon.microprofile.metrics.RegistryFactoryManager;
  import io.helidon.metrics.api.MetricRegistry;
  
  RegistryFactoryManager.getInstance().addListener(registryFactory -> {
      MetricRegistry registry = registryFactory.getRegistry(MetricRegistry.Type.APPLICATION);
      // 执行注册表相关操作
  });
  

  注意要确保监听注册在RegistryFactory创建之前，否则回调不会触发。

移除org.eclipse.microprofile.* MetricRegistry支持的原因 #

Helidon团队做出这个变更主要有以下几点考虑：

• 统一内部API体系：Nima作为Helidon的下一代响应式架构，需要一套自洽、轻量化的原生API，避免依赖外部规范API带来的适配成本和兼容性限制。
• 适配响应式模型：自研的io.helidon.metrics.api.* API完全贴合Nima的响应式设计，在性能、异步支持上比原MicroProfile实现更优。
• 独立迭代节奏：依赖MicroProfile规范会限制Helidon的迭代速度，改用自研API可以更快地推出新特性、修复问题，不受外部规范更新周期的约束。
• 简化依赖结构：移除对MicroProfile Metric API的依赖，能减少应用的依赖树规模，降低潜在的版本冲突风险，提升应用的稳定性。

内容的提问来源于stack exchange，提问作者Ashok