Service Mesh的实践分享

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/servicemesher

摘要

文档分享了唯品会在Service Mesh实践中的演进过程，包括从服务化体系1.0到2.0的转变，对比了与Istio的区别，讨论了实践中遇到的挑战，并展望了未来的发展规划。文档详细介绍了服务元数据上报、服务路由网络传输、服务配置中心等核心组件，并分析了胖客户端、Sidecar代理和Cluster模式的优缺点。同时，探讨了服务网格在容器化环境下的部署策略和动态扩容方案，最后总结了在实践中踩过的坑，如ZooKeeper的强耦合问题。

AI总结

### 唯品会Service Mesh实践分享总结

#### 1. 内部Service Mesh的演进
唯品会的Service Mesh经历了从服务化体系1.0到2.0的演进：
- **服务化体系1.0**：基于胖客户端架构，依赖Zookeeper进行服务注册与配置管理，采用Thrift over Netty实现服务通信，支持基本的服务治理功能。但存在语言单一、升级困难等问题。
- **服务化体系2.0**：引入Sidecar代理和Daemonset模式，逐步向Service Mesh架构演进。通过Local Proxy和Remote Proxy实现服务治理与流量管理，支持动态扩容和优雅升级。

#### 2. 与Istio的区别
唯品会的Service Mesh在设计上与Istio有所不同：
- 采用Sidecar代理而非 Istio 的统一控制平面。
- 强调轻量级客户端和本地调用，减少对外部组件的依赖。
- 提供更高的灵活性，允许客户端选择是否使用Proxy。

#### 3. 实践中踩过的坑
- **ZooKeeper的强耦合**：早期设计直接依赖Zookeeper的特性和原语，导致跨机房多活、性能瓶颈和迁移困难。
- **胖客户端架构的局限性**：侵入性强、升级难度大，对应用进程资源占用高。
- **Sidecar与Daemonset的权衡**：物理机Sidecar在资源适配和动态扩容方面存在挑战。

#### 4. 今年规划（Roadmap）
唯品会计划进一步优化Service Mesh架构：
- 提升配置管理和流量调度的灵活性。
- 优化Proxy的资源适配和动态扩容能力。
- 解决跨机房多活和性能瓶颈问题，提升整体服务治理能力。

---

### 总结
唯品会在Service Mesh的实践中，从服务化体系1.0的胖客户端架构逐步演进到2.0的Sidecar代理模式，尝试减少对外部组件的依赖，提升架构的灵活性和可运维性。在实践中，团队深刻体会到ZooKeeper强耦合的弊端，并通过引入Local Proxy和Remote Proxy实现流量管理与服务治理的分离。未来规划聚焦于优化架构设计，提升服务治理能力，为业务提供更高效、可靠的微服务支持。