背景
- 微服务架构虽然带来诸多优势，但也增加了系统的复杂性，如网络问题、服务发现、容错保护等。
- 微服务SDK（如Spring Cloud）曾是治理标配，但存在局限。
- 服务网格（如Istio）提供与开发解耦的治理能力。
Spring Cloud 的问题
- 多语言支持问题：云原生场景下需要支持多种语言和框架。
- 服务发现不及时：在Kubernetes环境下，服务实例动态迁移导致服务发现问题。
- SDK升级问题：每次Spring Cloud升级都需要业务团队配合升级服务。
- 单体到微服务的迁移：渐进式微服务化存在挑战。
解决方案：服务网格（Istio）
- 多语言问题：服务网格不绑定语言和框架，任何服务都可被管理。
- 服务发现问题：统一使用Kubernetes服务发现数据。
- SDK升级问题：服务治理与业务解耦，基础设施升级不影响业务。
- 渐进微服务化：Istio可以管理单体和微服务，实现渐进式迁移。
实践细节
- 解耦和卸载：将非开发功能从SDK中卸载到基础设施。
- 迁移步骤：
- 废弃原有微服务注册中心，使用K8s的Service。
- 短路SDK中服务发现和负载均衡逻辑，直接使用k8s服务名和端口。
- 逐步使用网格治理能力替换SDK功能。
- 迁移方式：
- 只修改配置，最小化代码修改。
- 完全移除Spring Cloud依赖，简化项目。
微服务、容器、Kubernetes 和 Istio 的关系
- 微服务和容器的轻量级特性相辅相成。
- Kubernetes 成为容器编排的事实标准。
- Istio 与 Kubernetes 紧密结合，提供端到端的微服务治理平台。
- 使用Istio进行微服务治理成为越来越多用户的选择。
)
