服务架构

服务架构关注系统如何拆分、如何协作、如何演进。服务架构演进文件详细介绍了从原始分布式到云原生的演进历程。

提示

从原始分布式到云原生的架构演进历程

演进历程

软件架构经历了原始分布式（1980s）→ 单体（1990s）→ SOA（2000s）→ 微服务（2014）→ 云原生（2017）的演进。每次演进都是为了解决上一代架构的核心痛点。

原始分布式试图通过分布式突破硬件限制，但远程调用与本地调用的性能差距让这个方向失败了。单体架构在小型系统中仍然是最佳选择，只有当系统规模超过单机上限时才需要考虑分布式。SOA 通过服务拆分实现独立部署，但过于严格的规范带来过度复杂性。

微服务是当前主流的架构风格，九大核心特征包括服务组件化、围绕业务能力、产品化思维、强终端弱管道、分散治理、数据去中心化、容错性设计、演进式设计、基础设施自动化。核心矛盾是微服务对开发者友善，对架构者是挑战。

微服务架构需要服务治理解决服务发现问题，需要流量治理解决雪崩问题，需要可观测实现分布式系统的观测，需要架构安全解决认证授权问题。

云原生架构是微服务的下一个阶段，通过 Kubernetes 和服务网格实现基础设施的声明式管理。核心转变是从软件层面应对分布式问题到软硬一体合力应对。Spring Cloud 在应用层解决分布式问题，Kubernetes 在基础设施层解决，服务网格在网络层提供细粒度治理。

系统规模决定架构选择：小型系统（单机可支撑）用单体，中型系统（团队 10-50 人）用微服务（Spring Cloud），大型系统（团队 50+ 人）用云原生（Kubernetes + 服务网格）。没有最好的架构，只有最适合当前阶段的架构。

演进规律的核心矛盾是透明性 vs 复杂性。原始分布式追求透明导致复杂性失控，单体架构避免复杂失去隔离能力，SOA 规范约束导致过度复杂，微服务轻量自由但决策负担重，云原生通过软硬协同追求透明+轻量。