Spring Cloud 转向k8s+istio的动机

背景

• 微服务架构虽然带来诸多优势，但也增加了系统的复杂性，如网络问题、服务发现、容错保护等。
• 微服务SDK（如Spring Cloud）曾是治理标配，但存在局限。
• 服务网格（如Istio）提供与开发解耦的治理能力。

Spring Cloud 的问题

1. 多语言支持问题：云原生场景下需要支持多种语言和框架。
2. 服务发现不及时：在Kubernetes环境下，服务实例动态迁移导致服务发现问题。
3. SDK升级问题：每次Spring Cloud升级都需要业务团队配合升级服务。
4. 单体到微服务的迁移：渐进式微服务化存在挑战。

解决方案：服务网格（Istio）

• 多语言问题：服务网格不绑定语言和框架，任何服务都可被管理。
• 服务发现问题：统一使用Kubernetes服务发现数据。
• SDK升级问题：服务治理与业务解耦，基础设施升级不影响业务。
• 渐进微服务化：Istio可以管理单体和微服务，实现渐进式迁移。

实践细节

• 解耦和卸载：将非开发功能从SDK中卸载到基础设施。
• 迁移步骤：
  1. 废弃原有微服务注册中心，使用K8s的Service。
  2. 短路SDK中服务发现和负载均衡逻辑，直接使用k8s服务名和端口。
  3. 逐步使用网格治理能力替换SDK功能。
• 迁移方式：
  • 只修改配置，最小化代码修改。
  • 完全移除Spring Cloud依赖，简化项目。

微服务、容器、Kubernetes 和 Istio 的关系

1. 微服务和容器的轻量级特性相辅相成。
2. Kubernetes 成为容器编排的事实标准。
3. Istio 与 Kubernetes 紧密结合，提供端到端的微服务治理平台。
4. 使用Istio进行微服务治理成为越来越多用户的选择。