主要观点：从单体 Java 8 系统迁移到 Kubernetes 上的反应式微服务架构，可显著提升性能和可维护性，本文分享迁移历程、采用的关键 Spring Cloud Kubernetes 特性、开发中面临的挑战及经验教训。
关键信息：

• 业务逻辑：通过 Kafka、Spark Streaming 和 Iceberg 将数据处理逻辑流式传输到 S3 存储，曾遇文件优化和 Spark 内存问题，后选择 Trino 作为搜索引擎服务，且有客户对 S3 数据操作导致系统负载高，旧架构为 Java 8 单体架构，存在性能和维护挑战。
• 旧单体架构：缺乏可扩展性和灵活性，是遗留设计，组件间耦合紧密，代码修复耗时，多数库已弃用，受 Java 8 垃圾回收和与现代库不兼容限制，依赖 Zookeeper 存储全局参数，维护繁琐。
• 新反应式架构：提取搜索服务并使用现代 Java 中的反应式 Spring 技术重建，通过 Spring Cloud Kubernetes 部署，该平台提供 Spring Cloud 接口实现以使用原生 Kubernetes 服务。

• 关键 Spring Cloud Kubernetes 特性：

  • ConfigMap 属性源：以键值对或嵌入文件形式外部化配置参数，Spring Cloud Kubernetes Config 项目可在应用启动时使用并热加载。
  • Secrets 属性源：用于存储敏感信息，可集成使用。
  • 领导者选举：使用 Kubernetes ConfigMap 实现 Spring Integration 的领导者选举 API，避免多 pod 间的竞争条件。
  • Spring Cloud Kubernetes 配置观察器：将 ConfigMap 或 Secrets 作为卷挂载，内容变化时自动更新，通过@RefreshScope实现配置更改自动触发 bean 重载。
  • Spring Boot Actuator：提供生产就绪的监控、指标收集和健康检查功能，可集成用于监测应用性能等。
• 开发中问题：测试时发现 Actuator 收集外部 IP 调用服务的指标导致 CPU 使用率逐渐增加，通过MeterFilter.deny()过滤解决；设计能从 Kubernetes ConfigMap 和本地应用资源读取配置数据的单类有挑战；更新 Kubernetes ConfigMap 需与 Argo 项目同步，添加pushToGit()函数自动提交更新。
• 经验教训：将单体服务重构为微服务，开发更高效，提升性能，可访问 Spring Cloud Kubernetes 的全功能，获得可扩展性、动态配置管理和简化的可观测性，能更快部署更新、快速恢复和减少维护开销。
• 结论：从单体 Java 8 架构迁移到基于 Spring WebFlux 和 Kubernetes 的反应式微服务环境，提升了系统的可靠性和敏捷性，组合使用多种特性创建了可灵活处理大规模复杂工作负载的云原生平台。