服务架构演进
软件架构经历了从原始分布式 → 单体 → SOA → 微服务 → 云原生的演进，每次演进都是为了解决上一代架构的核心痛点。
提示
从原始分布式到云原生的架构演进历程
原始分布式时代（1980s-1990s）
核心问题：单机算力不足，试图通过分布式突破硬件限制。
代表技术：DCE（Distributed Computing Environment）、CORBA。
核心教训：「某个功能能够进行分布式，并不意味着它就应该进行分布式。」
失败原因：远程调用与本地调用存在数量级的性能差距，开发者必须时刻意识到自己在编写分布式程序。分布式带来的服务发现、跟踪、通信、容错、隔离等问题，付出的代价远超收益。
单体系统时代（1990s-2010s）
「单体」只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。
| 优势 | 说明 |
|---|---|
| 开发简单 | 无需考虑分布式复杂性 |
| 测试简单 | 本地方法调用，无网络问题 |
| 性能高效 | 无网络开销 |
劣势（仅当系统规模超过单机上限时才重要）：隔离性差（内存泄漏影响全局）、更新困难（无法单独更新某部分代码）、技术锁定（必须使用相同语言框架）、扩展困难（只能整体扩展）。
何时适用：小型系统由单台机器足以支撑时，单体是最佳选择。
SOA 时代（2000s）
核心思想：通过服务拆分实现独立部署和运行。
三种拆分模式：烟囱式架构（完全不与其他系统交互）、微内核架构（公共核心+插件模块）、事件驱动架构（通过事件队列解耦）。
失败原因：过于严格的规范带来过度复杂性，只能解决异构大型系统的复杂集成，难以普及。如同「EJB 败于 Spring」一样，过于「阳春白雪」。
微服务时代（2014-至今）
Martin Fowler 定义：微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定技术标准来构建。微服务拆分后需要 服务治理 来解决服务发现问题。
九大核心特征
| 特征 | 说明 |
|---|---|
| 服务组件化 | 通过服务而非类库构建组件 |
| 围绕业务能力 | 康威定律：团队结构决定系统结构 |
| 产品化思维 | 团队对产品全生命周期负责 |
| 强终端弱管道 | 反对 ESB 的复杂通信机制 |
| 分散治理 | 技术选型权下放给团队 |
| 数据去中心化 | 按领域分散管理数据 |
| 容错性设计 | 断路器是必备而非可选 |
| 演进式设计 | 服务应能被报废替换 |
| 基础设施自动化 | 依赖 CI/CD |
核心矛盾：微服务对开发者友善，对架构者是挑战。
后微服务时代 / 云原生（2017-至今）
核心转变：从软件层面应对分布式问题 → 软硬一体合力应对。
标志性事件：2017 年 Kubernetes 赢得容器战争胜利。
Spring Cloud 在应用层解决分布式问题，Kubernetes 在基础设施层解决，云原生架构 在网络层提供细粒度治理。
演进规律
┌─────────────────────────────────────────┐
│ 透明性 vs 复杂性 │
├─────────────────────────────────────────┤
│ 原始分布式：追求透明 → 复杂性失控 │
│ 单体架构：避免复杂 → 失去隔离能力 │
│ SOA：规范约束 → 过度复杂 │
│ 微服务：轻量自由 → 决策负担重 │
│ 云原生：软硬协同 → 追求透明+轻量 │
└─────────────────────────────────────────┘| 系统规模 | 推荐架构 |
|---|---|
| 小型系统（单机可支撑） | 单体 |
| 中型系统（团队 10-50 人） | 微服务（Spring Cloud） |
| 大型系统（团队 50+ 人） | 云原生架构（Kubernetes + 服务网格） |
适用场景
| 场景 | 推荐架构 | 原因 |
|---|---|---|
| 创业公司 MVP | 单体 | 快速迭代，避免分布式复杂性 |
| 团队 10-50 人 | 微服务（Spring Cloud） | 独立部署、技术栈灵活 |
| 多团队大型系统 | 云原生（Kubernetes + 服务网格） | 基础设施自动化、透明治理 |
| 遗留系统改造 | 渐进式拆分 | 先识别瓶颈模块，逐步服务化 |
FAQ
Q: 什么时候从单体拆分为微服务？ A: 当出现以下信号时考虑拆分：1）单体部署耗时超过 30 分钟；2）一个模块的变更需要全量回归测试；3）团队规模超过 10 人，代码冲突频繁；4）某个模块的流量远大于其他模块，需要独立扩缩容。过早拆分会引入不必要的分布式复杂性。
Q: 微服务拆分的粒度怎么定？ A: 按业务领域拆分（DDD 限界上下文），而非按技术层拆分。一个微服务应该由一个小团队（2-5 人）独立维护，具备独立的数据库和部署流水线。如果两个服务之间需要同步修改才能上线，说明拆分过细。
Q: SOA 和微服务的核心区别是什么？ A: SOA 通过 ESB（企业服务总线）集中管理通信，规范严格但笨重；微服务去中心化，轻量级通信（HTTP/REST），每个服务独立选型。SOA 适合异构大型系统的集成，微服务适合快速迭代的互联网产品。