依赖50+ System of records的单体转Microservices架构可行性咨询

我们计划从单体架构迁移至微服务架构，但因依赖50+个记录系统（System of records），无法实现“每个微服务对应独立数据库”的模式。目标是将前端渠道API服务器（如移动端API、网站API等）的逻辑迁移至可在Openshift/Kubernetes环境中水平扩展的微服务。现咨询两个核心问题：

1. 微服务无法直接连接数据库，部分业务逻辑存于记录系统且需通过REST或MQ与其交互时，迁移至微服务架构是否可行？
2. 微服务通过消息队列（MQ）或HTTP与记录系统通信是否可行？

架构示意图 #

新架构（微服务架构） #

旧架构（单体架构） #

问题1：无法直连数据库、依赖记录系统交互的微服务架构是否可行？ #

完全可行，这是大型企业遗留系统向微服务迁移时的典型落地场景。

• 核心思路是将原单体前端渠道API中的转发、聚合、业务适配逻辑，拆分为聚焦单一业务能力或渠道的微服务，这些微服务无需自建数据库，而是通过标准化接口（REST/MQ）调用现有记录系统完成数据读写与业务逻辑执行。
• 这种模式的核心价值：
  • 无需改造50+现有记录系统，大幅降低迁移的风险与成本；
  • 拆分后的微服务可在K8s/Openshift中独立水平扩展，精准应对前端渠道的流量峰值；
  • 每个微服务职责单一，便于快速迭代、维护与故障隔离。
• 关键注意事项：
  • 建议为记录系统的接口封装统一适配层，屏蔽底层接口的细节差异，避免微服务与记录系统直接耦合；
  • 必须实现服务间调用的容错机制（如熔断、降级、重试），防止单个记录系统故障扩散影响整个微服务集群。

问题2：微服务通过MQ或HTTP与记录系统通信是否可行？ #

两种通信方式均可行，需结合业务场景选型：

HTTP（REST） #

• 适用场景：同步业务请求（如用户信息查询、实时订单提交），需要立即获取处理结果的场景；
• 优势：实现成本低，接口可读性强，调试与监控便捷；
• 关键要点：需处理超时、重试逻辑，同时保证接口的幂等性，避免重复请求导致数据不一致。

消息队列（MQ） #

• 适用场景：异步业务流程（如操作日志上报、非实时数据同步、后台通知推送），不需要即时获取结果的场景；
• 优势：彻底解耦微服务与记录系统，具备削峰填谷能力，提升整体系统的稳定性；
• 关键要点：需保障消息的可靠性（持久化、死信队列），处理消息丢失、重复消费的问题，若业务有顺序要求需额外控制消息顺序。

内容的提问来源于stack exchange，提问作者topgun