从单体到微服务，我们走了两年
2023年初，我们的核心系统还是一个200万行代码的Java单体应用。每次发布都要全量部署，一个模块的bug可能导致整个系统宕机。经过两年的微服务改造，现在系统拆分为12个独立服务，发布频率从每月1次提升到每周3次，系统可用性从99.5%提升到99.95%。
拆分策略：绞杀者模式
我们采用了绞杀者模式（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做配置中心，支持灰度推送和版本回滚。