异构微服务编排
异构微服务编排的意义
Rainbond "信创"版本凭借"一云多芯"管理能力,可以在同一个集群中统一调度管理不同 CPU 架构的计算节点。应用中的服务组件可以按照要求部署到指定的架构中去。但只有不同架构的微服务组件之间能够相互编排、相互通信,才能形成一个有机的整体,实现完整的业务系统功能。这一能力对于满足信创应用从传统 X86_64
向 arm64
国产化迁移过渡期的需求尤为重要。
借助于服务网格(Service Mesh)和 Kubernetes Service 的能力,Rainbond 天然支持跨架构微服务之间 的编排与通信。使用方法与 Rainbond 一贯的拖拉拽、拼积木式的微服务编排方式完全一致,无需额外的配置和学习成本。
异构微服务编排原理
在 Rainbond 平台上,不同架构的微服务组件之间能够无缝通信和协作,这得益于以下技术实现:
- 统一服务发现:无论服务组件部署在何种架构的节点上,都被纳入统一的服务发现系统
- 透明的网络通信:Rainbond 的内部服务网络对架构差异透明化处理
- 自动化依赖注入:组件间建立依赖关系时,自动注入所需的环境变量和连接信息
这些技术确保了即使在混合架构环境中,微服务组件也能像在同一架构下一样自然地协作。
实现异构微服务编排
基本操作步骤
在 Rainbond 平台上实现异构微服务编排非常简单,基本步骤如下:
-
创建应用:在团队视图中创建一个新应用
-
部署不同架构的组件:
- 按照多架构应用部署指南,分别在 X86_64 和 ARM64 架构上部署需要的组件
- 确保每个组件都成功部署并运行正常
-
- 在应用拓扑图中,拖拽连接线建立不同组件之间的依赖关系
- 从一个组件拖拽到另一个组件,即可建立依赖
- 依赖关系建立后,可以配置具体的依赖参数
-
验证跨架构通信:
- 启动所有组件后,检查日志确认服务间通信正常
- 可通过访问入口组件验证整体功能
异构微服务编排最佳实践
合理规划架构分布
在规划异构微服务架构时,建议遵循以下原则:
- 关联性原则:紧密关联、通信频繁的组件尽量部署在相同架构上,减少跨架构通信开销
- 性能优先原则:对性能要求高的组件优先考虑其最佳运行架构
- 渐进迁移原则:在信创迁移过程中,可先迁移较独立的组件,逐步扩展到核心组件
典型异构微服务架构模式
以下是几种常见的异构微服务架构模式:
1. 前后端分离模式
- 前端:部署在 ARM64 架构(国产化环境)
- 后端API:部署在 X86_64 架构(传统环境)
- 数据库:部署在 X86_64 架构(等待稳定后再迁移)
这种模式适合快速展示国产化成果,同时保留后端系统的稳定性。
2. 核心业务迁移模式
- 核心业务服务:部署在 ARM64 架构
- 辅助服务:部署在 X86_64 架构
- 数据服务:根据兼容性和性能需求选择部署架构
这种模式适合将关键业务迁移到国产化环境,同时保留难以迁移的辅助系统。
3. 数据分析混合模式
- 数据采集与存储:部署在 X86_64 架构
- 数据计算与分析:部署在 ARM64 架构(利用ARM的并行计算优势)
- 展示层:跨架构部署,根据客户环境自适应
这种模式利用了不同架构的优势,实现资源的最优利用。
异构微服务编排常见问题
1. 跨架构服务调用超时
可能原因:
- 不同架构节点之间的网络延迟
- 服务实例负载不均衡
- 序列化/反序列化效率问题
解决方案:
- 调整服务超时阈值,适当放宽超时限制
- 检查网络配置,确保不同架构节点间网络畅通
- 优化数据传输格式,减少传输量
2. 依赖组件无法连接
可能原因:
- 环境变量未正确注入
- DNS解析问题
- 防火墙或网络策略限制
解决方案:
- 检查环境变量是否正确设置和注入
- 验证服务发现是否正常工作
- 检查网络策略,确保不同架构节点间允许相互访问