为什么会到这里

微服务不是“更小的单体”，而是对组织边界、团队边界和系统边界的一次同步重构。
这篇前言先把几个核心问题讲清楚，避免把微服务当成“万能框架”。

企业为什么采用微服务？

常见动因包括：

  • 复杂度分层：单体系统扩展到一定规模后，变更成本急剧上升
  • 交付节奏加快：团队可以并行交付不同业务域
  • 可用性与弹性：资源可以按服务粒度扩缩容
  • 运维与治理分离：监控、链路追踪、鉴权、网关可按域逐步演进

康威定律（Melvin R. Conway，1968）提醒我们：组织结构会影响系统结构。
团队沟通方式决定服务边界，服务边界反过来约束协作效率。

从单体到微服务时要先澄清的事

  • 业务边界是否清晰，是否可以稳定抽象成上下文
  • 数据边界如何定义，是否有明确的归属权（ownership）
  • 可观测性（监控、日志、链路追踪）是否能同步落地
  • 发布流程与回滚能力是否能支撑多服务部署

先区分两个重点

面向对象更多是一种“建模思维”，微服务更偏“组织架构”与“运行模型”。
没有一致的建模，就算堆再多组件，系统依然会变得难以维护。

Spring Bean 和依赖治理

在微服务里，Spring 体系的 IoC/DI 仍是默认范式，但你需要在服务粒度、事务边界和客户端负载均衡之间做出清晰取舍。
把“技术能力”放到前面不一定对，先把“问题边界”定义清楚更重要。