单体应用在业务早期开发快、部署也简单。可功能一多、团队一大，代码互相缠绕，发布越来越慢，一个模块出问题就可能拖垮整站。微服务的做法是把系统切成一组能单独开发、单独部署、单独扩容的服务，团队按业务边界各自推进。但拆分本身不是目的。拆完之后，业务能不能快速调整、系统能不能稳住，才是判断拆得好不好的标准。
国内做云原生的团队，在阿里云上通常会用到一组相关产品：容器服务 ACK、注册配置中心 Nacos、微服务引擎 MSE、服务网格 ASM、消息队列 RocketMQ，还有应用高可用服务 AHAS。这些产品不必一次全上，按当前阶段挑几个用就够了。
一个区域电商的拆分过程
下面这个案例是按行业常见情况整理的示意，用来说明思路，并非某家公司的真实数据。某区域电商早期是单体架构，订单、库存、营销、会员共用一套数据库。大促时，营销活动的流量会拖慢下单接口，库存服务跟着超时，最后整个交易链路都受影响。
这个团队没有一口气重构完，而是分三步走。
- 先看清边界：用调用链分析梳理模块之间的依赖关系，优先拆出访问量大、改动频繁的营销服务和库存服务。
- 再把基础设施搬上去：服务部署到 ACK 上，注册和配置交给 Nacos。参数调整不用再整包发版，改完配置就能生效，这一步省下的发布次数不少。
- 最后补治理能力：通过 MSE 配置限流、熔断和降级。大促前给营销接口单独设一个流量阈值，超过时自动回落到缓存结果，营销再抖也不会把下单拖下去。
半年后，大促期间的核心交易接口明显更稳，营销侧的异常不再蔓延到下单链路。这说明拆分的收益主要来自故障隔离和各自独立演进，架构图好看并不算数。
上线前要想清楚的几件事
拆多细比较合适
拆得太碎，远程调用会成倍增加，链路追踪和运维也跟着变重。判断标准可以很朴素：这个服务是不是一个小团队能扛下来，它的数据归属是不是清楚。数据库尽量按服务切开，如果两个服务老是同时读写同一张表，那基本可以确定边界还没划对。
哪些调用要同步，哪些走异步
下单时查库存，必须马上拿到结果，这种就用同步调用。日志处理、积分发放、消息推送这类任务，用户不需要立刻知道结果，交给 RocketMQ 异步处理更合适。大促时消息队列还能起到削峰的作用，上下游之间的耦合也会松一些。
出了问题能不能快速找到
微服务里一次请求经过十几个服务并不稀奇。链路追踪、指标监控和统一日志最好在项目初期就接上，等线上出了故障再回头补，往往已经晚了。
服务之间怎么保证安全
内部服务之间的调用要做身份认证和权限控制。对外的网关需要配置鉴权和限流。内部服务如果直接暴露在公网，攻击面会大很多，这一点在上线前必须检查。
实施时可以按这个顺序来
- 先摸清现有系统的耦合点，挑一到两个收益最大的模块做试点，不要全面铺开。
- 尽早统一服务命名、接口版本、配置管理和日志格式，后面补的成本会高很多。
- 在测试环境里验证限流、熔断、降级策略，并定期做一次故障演练。演练时拔掉一个依赖，看看结果是不是你预期的。
- 发布和回滚机制要提前建好，确保每个服务都能单独上线，也能单独回退。
- 定期对比拆分带来的收益和运维投入，如果发现服务多了却没省事，就该停下来想想是不是拆过头了。
总的看，阿里云这套产品能降低基础设施的门槛，但架构设计、团队协作和运维能力才决定项目能不能跑顺。选型时从自己的业务痛点出发，一步步演进，比一开始就追求完整架构更靠谱。
