从单体到微服务，我们走了两年
2023年初，我们的核心系统还是一个200万行代码的Java单体应用。每次发布都要全量部署，一个模块的bug可能导致整个系统宕机。经过两年的微服务改造，现在系统拆分为12个独立服务，发布频率从每月1次提升到每周3次，系统可用性从99.5%提升到99.95%。
「云原生架构演进：从单体到微服务的转型之路」并不是一个孤立的话题。容器与 Kubernetes 编排同时牵动容量规划、网络划分、弹性伸缩与容灾边界等多个层面，只有把它们当作一个整体来推进，才能避免上线之后反复返工、被动救火。
拆分策略：绞杀者模式
我们采用了绞杀者模式（Strangler Fig），而不是大爆炸式重写。先从边缘模块开始拆分，比如消息通知、文件上传这些相对独立的功能。每拆分一个模块，就用新的微服务"绞杀"掉老系统中的对应部分。流量通过API网关逐步切到新服务，老服务逐步下线。
拆分顺序很重要：先拆无状态的（通知、文件），再拆读多写少的（查询、报表），最后拆核心交易链路。核心链路要等团队积累了足够的微服务运维经验后再动。
服务通信
同步调用使用Spring Cloud OpenFeign + 阿里云MSE（微服务引擎）做服务注册发现。异步通信使用 RocketMQ（阿里云版），订单创建后通过消息通知库存、积分、物流等下游服务。
服务间调用链路长，必须接入链路追踪。我们用阿里云ARMS，可以看到一个请求从网关到各个微服务的完整调用链，包括每个节点的耗时、状态码。排查问题时效率提升10倍。
数据拆分
这是最难的部分。我们采用了"数据库跟随服务"原则：每个微服务有自己的数据库（Schema级别隔离），跨服务数据通过API或事件获取。原来单库的JOIN查询，改为在应用层组装数据。
对于需要跨服务查询的场景（如运营后台），使用Elasticsearch做数据聚合，通过Canal监听各库的Binlog同步到ES。
踩过的坑
分布式事务：最初用2PC，性能太差。后来改用Saga模式 + 本地消息表，最终一致性方案。对于资金类操作，保留TCC（Try-Confirm-Cancel）模式。
服务雪崩：一个下游服务超时导致调用方线程池耗尽。解决方案：所有远程调用必须设置超时、必须配置熔断（Sentinel）、必须有降级方案。
配置管理：12个服务的配置散落在各处，管理混乱。统一使用Nacos做配置中心，支持灰度推送和版本回滚。
落地前的自检清单
- 容量与规格：是否用真实压测数据而非经验估算来定规格，是否预留了弹性空间。
- 网络与边界：网段划分是否留有扩展余地，安全组是否遵循最小开放原则。
- 弹性与容灾：扩缩容策略是否经过演练，故障切换路径是否清晰、可回退。
- 可观测性：关键链路是否有指标、日志与告警覆盖，出问题能否快速定位。
这四件事做到位，容器与 Kubernetes 编排才算真正「落地」，而不是停留在方案文档里。
与安徽卓牛一起推进容器与 Kubernetes 编排
安徽卓牛作为阿里云一级代理商，长期服务企业客户的上云与用云全过程，能够围绕容器与 Kubernetes 编排提供架构评审、产品选型、迁移实施与运维托管等一站式支持，帮助团队把精力集中在业务本身。
如果你正在评估「云原生架构演进：从单体到微服务的转型之路」相关方案，或希望对现有架构做一次体检，欢迎通过官网在线客服联系安徽卓牛，获取贴合自身业务的建议。