跳到主要内容
版本：V6.2

异构微服务编排

异构微服务编排的意义​

Rainbond "信创"版本凭借"一云多芯"管理能力，可以在同一个集群中统一调度管理不同 CPU 架构的计算节点。应用中的服务组件可以按照要求部署到指定的架构中去。但只有不同架构的微服务组件之间能够相互编排、相互通信，才能形成一个有机的整体，实现完整的业务系统功能。这一能力对于满足信创应用从传统 X86_64 向 arm64 国产化迁移过渡期的需求尤为重要。

借助于服务网格（Service Mesh）和 Kubernetes Service 的能力，Rainbond 天然支持跨架构微服务之间的编排与通信。使用方法与 Rainbond 一贯的拖拉拽、拼积木式的微服务编排方式完全一致，无需额外的配置和学习成本。

异构微服务编排示意图

异构微服务编排原理​

在 Rainbond 平台上，不同架构的微服务组件之间能够无缝通信和协作，这得益于以下技术实现：

  1. 统一服务发现：无论服务组件部署在何种架构的节点上，都被纳入统一的服务发现系统
  2. 透明的网络通信：Rainbond 的内部服务网络对架构差异透明化处理
  3. 自动化依赖注入：组件间建立依赖关系时，自动注入所需的环境变量和连接信息

这些技术确保了即使在混合架构环境中，微服务组件也能像在同一架构下一样自然地协作。

实现异构微服务编排​

基本操作步骤​

在 Rainbond 平台上实现异构微服务编排非常简单，基本步骤如下：

  1. 创建应用：在团队视图中创建一个新应用

  2. 部署不同架构的组件：

    • 按照多架构应用部署指南，分别在 X86_64 和 ARM64 架构上部署需要的组件
    • 确保每个组件都成功部署并运行正常

  3. 建立组件依赖关系：

    • 在应用拓扑图中，拖拽连接线建立不同组件之间的依赖关系
    • 从一个组件拖拽到另一个组件，即可建立依赖
    • 依赖关系建立后，可以配置具体的依赖参数

  4. 验证跨架构通信：

    • 启动所有组件后，检查日志确认服务间通信正常
    • 可通过访问入口组件验证整体功能

异构微服务编排最佳实践​

合理规划架构分布​

在规划异构微服务架构时，建议遵循以下原则：

  1. 关联性原则：紧密关联、通信频繁的组件尽量部署在相同架构上，减少跨架构通信开销
  2. 性能优先原则：对性能要求高的组件优先考虑其最佳运行架构
  3. 渐进迁移原则：在信创迁移过程中，可先迁移较独立的组件，逐步扩展到核心组件

典型异构微服务架构模式​

以下是几种常见的异构微服务架构模式：

1. 前后端分离模式​

  • 前端：部署在 ARM64 架构（国产化环境）
  • 后端API：部署在 X86_64 架构（传统环境）
  • 数据库：部署在 X86_64 架构（等待稳定后再迁移）

这种模式适合快速展示国产化成果，同时保留后端系统的稳定性。

2. 核心业务迁移模式​

  • 核心业务服务：部署在 ARM64 架构
  • 辅助服务：部署在 X86_64 架构
  • 数据服务：根据兼容性和性能需求选择部署架构

这种模式适合将关键业务迁移到国产化环境，同时保留难以迁移的辅助系统。

3. 数据分析混合模式​

  • 数据采集与存储：部署在 X86_64 架构
  • 数据计算与分析：部署在 ARM64 架构（利用ARM的并行计算优势）
  • 展示层：跨架构部署，根据客户环境自适应

这种模式利用了不同架构的优势，实现资源的最优利用。

异构微服务编排常见问题​

1. 跨架构服务调用超时​

可能原因：

  • 不同架构节点之间的网络延迟
  • 服务实例负载不均衡
  • 序列化/反序列化效率问题

解决方案：

  • 调整服务超时阈值，适当放宽超时限制
  • 检查网络配置，确保不同架构节点间网络畅通
  • 优化数据传输格式，减少传输量

2. 依赖组件无法连接​

可能原因：

  • 环境变量未正确注入
  • DNS解析问题
  • 防火墙或网络策略限制

解决方案：

  • 检查环境变量是否正确设置和注入
  • 验证服务发现是否正常工作
  • 检查网络策略，确保不同架构节点间允许相互访问