微服务是把一个复杂应用拆分为一组围绕业务能力组织的小服务，每个服务有相对清晰的职责、接口和生命周期。它适合处理业务变化快、团队协作复杂、发布节奏不一致的系统，但前提是服务边界、数据归属和治理能力跟得上。
单体架构并不低级。很多业务早期用单体更高效，因为代码集中、事务简单、部署路径短。微服务的价值通常出现在系统规模、团队规模和变更频率同时上升之后。
单体架构的压力通常先出现在协作上
单体应用把多个业务模块放在同一个代码库、同一个进程和同一个发布包中。早期这样做很自然：开发快、调试方便、事务边界简单，团队只需要维护一套部署流程。
问题会在业务复杂后显现。订单、账户、库存、报表、营销等模块的变更频率不同，却被同一个发布窗口绑定；一个小功能上线也要回归整个系统；不同团队修改同一代码库，冲突和等待开始增加。
关键判断：单体是否需要演进，主要看变更耦合和发布耦合，而不是代码行数。 如果系统很大但变更稳定、团队小、发布风险可控，继续维护单体可能更合理。
微服务先拆业务边界，再拆技术组件
微服务拆分要围绕业务能力，例如账户服务、订单服务、支付服务、库存服务，而不是按控制器、工具类、数据库表或技术分层拆。按技术层拆出的“用户Controller服务”“订单DAO服务”会制造更多远程调用，却没有减少业务耦合。
服务边界通常需要结合领域模型、数据变更频率、团队归属和发布风险判断。一个服务最好能独立完成一类业务能力，并拥有对应数据的读写责任。跨服务访问数据时，应通过接口、事件或同步机制，而不是多个服务直接共享同一张核心表。
拆分时常见的证据包括调用链、数据库表关系、代码包依赖、发布记录、缺陷归属和团队排班。只凭架构图拆服务，往往会低估数据迁移、接口兼容和灰度发布的成本。
微服务架构改变的不只是运行形态
微服务上线后，系统复杂度会从代码内部转移到分布式协作。网络延迟、接口超时、服务实例变化、配置差异、链路追踪、日志聚合、服务注册、熔断降级和灰度发布都会成为日常治理对象。
以下表格可以帮助判断微服务与单体在关键维度上的差异：
| 维度 | 单体架构 | 微服务架构 | 需要补齐的能力 |
| 发布方式 | 整体打包发布 | 服务独立发布 | CI/CD、灰度、回滚 |
| 数据边界 | 多模块共享数据库 | 服务拥有数据责任 | 数据拆分、接口契约 |
| 故障影响 | 进程内传播明显 | 网络和依赖链传播 | 熔断、限流、隔离 |
| 排查方式 | 日志集中在单应用 | 调用跨多个服务 | 链路追踪、统一日志 |
| 团队协作 | 统一代码库协作 | 服务归属到团队 | 版本管理、契约测试 |
表格中的变化说明，微服务不是单纯的技术升级。它会要求研发、测试、运维和平台团队一起调整工作方式。
拆得过细会让系统更难维护
微服务常见误区是过早、过细拆分。服务数量增加后，接口版本、部署配置、网络策略、权限、监控、告警和成本都会增加。如果团队缺少自动化交付和可观测能力，小服务会变成大量难以追踪的运行单元。
一个较稳妥的做法是先识别“变化最频繁、发布最受限、团队边界最清楚”的模块做试点。试点服务应具备独立构建、独立部署、独立回滚和基础监控能力，再考虑继续拆分。
风险提醒：微服务拆分的目标是降低业务变化的协作成本，不是追求服务数量。 当拆分没有减少等待、冲突和发布风险时，架构可能只是变复杂了。
从单体演进到微服务可以分阶段推进
企业系统很少适合一次性重写。更常见的路径是保留稳定单体，在边缘业务或高频变化模块上逐步抽离服务。
可参考的演进顺序如下：
- 先梳理模块依赖和数据库访问关系，找出高耦合点
- 把外部接口和内部调用契约稳定下来，避免边拆边改需求
- 选择一个业务边界清晰的模块，建立独立仓库、流水线和运行配置
- 通过API或事件与单体交互，保留兼容路径
- 建立日志、指标、链路追踪和告警规则
- 在灰度和回滚策略稳定后，再扩展到更多服务
这个过程要持续记录接口版本、数据迁移脚本、回滚条件和故障复盘。否则服务拆出来了，知识仍停留在个人经验中。
微服务需要平台能力做长期支撑
当服务数量增长后，平台能力会影响微服务能否稳定运行。服务注册与发现、配置管理、统一网关、服务网格、可观测平台、容器编排、自动化发布和权限治理，都会从“可选工具”变成“日常基础设施”。
落地建议：先让每个服务具备清晰责任，再用平台能力降低重复治理成本。 如果组织还没有明确服务Owner、接口规范和发布责任，直接引入复杂治理平台也很难奏效。
小结：先确认为什么拆，再决定怎么拆
微服务架构是什么，不能只用“多个小服务”概括。它是一套围绕业务能力、团队协作和独立交付建立的架构组织方式。
准备从单体演进时，建议先回答三个问题：哪个模块的变化最痛、拆出去后谁负责、失败后如何回滚。只有这些问题能被清楚回答，微服务才可能带来更高交付弹性，而不是新的运维负担。
改造前先识别服务边界
微服务改造前还要补充一项基础动作：把现有模块、数据库表、外部接口和发布窗口画在同一张图上。只有边界被看见，拆分才不会变成新的耦合，后续治理也更稳。
常见问题
微服务一定比单体架构好吗？
不一定。微服务适合业务复杂、团队多、发布节奏差异大的系统。对于早期产品、内部工具或变更频率不高的系统，单体往往更简单、更易维护。架构选择要看协作成本和运行治理能力。
一个微服务应该拆多小？
可以用业务能力、数据所有权和团队责任来判断。一个服务应能独立完成一类业务功能，并由明确团队负责开发、发布和运行。如果拆分后大量依赖其他服务才能完成基本动作，边界可能过细。
微服务必须配合容器和Kubernetes吗？
不是硬性要求，但容器和Kubernetes能降低部署、扩缩容、服务发现和环境一致性的管理成本。当服务数量较多、发布频繁时，容器平台通常会成为更自然的运行底座。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1258/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
