1. 系统架构的迭代
1.1 单体架构
所谓单体架构,就是把整个应用程序的所有功能模块(如用户管理、订单管理、支付管理等)都打包在一个单一的进程中,共用同一个数据库。
好处在于技术栈统一,开发、测试、部署都比较简单。初期功能集中,模块间直接调用,沟通成本低。因为是本地方法调用,没有网络开销,性能表现好。而且只需维护一个应用,运维压力小。
不过随着功能增加,代码库会变得庞大、耦合严重,难以理解和维护。技术栈固化,引入新框架或语言很困难。无法针对特定模块进行独立伸缩,必须整体扩容,成本高。任何微小的修改都需要重新构建和部署整个应用,风险高、上线慢。更糟糕的是,一个模块的 bug 可能导致整个系统崩溃。
1.2 集群与分布式架构
分布式是将单体应用按业务维度拆分成多个独立的子系统,这些子系统可以部署在不同的服务器上,通过网络通信协作完成整体业务。本质上是'拆分'。
集群是为了解决单点故障和性能瓶颈,将相同的单体应用部署在多台服务器上,通过负载均衡器对外提供服务。本质上是'复制'。
这种架构的优势在于高可用与高性能,通过集群实现负载均衡和故障转移。初步实现了物理上的解耦,技术栈可以按服务选择。数据库层面可能出现分库分表、读写分离。
但缺点也很明显:服务治理复杂,需要管理地址(服务发现)、调用关系、负载均衡策略。网络调用代替本地调用,面临超时、重试、网络故障等问题。数据一致性从单一数据库变为分布式数据库,面临分布式事务难题。运维变得复杂,需要监控、管理成百上千的服务实例,部署、配置、日志收集都变得困难。服务间依赖可能形成复杂的调用链。
1.3 微服务架构
微服务架构是分布式架构的一种更精细、更彻底的实践。它强调将单个应用程序拆分为一组微小、自治的服务。
分布式架构侧重于压力的分散,强调的是服务的分散化;微服务架构侧重于能力的分散,更强调服务的专业化和精细分工。
2. Spring Cloud 概述
2.1 微服务、Spring Cloud 与 Spring Boot 的关系
微服务是一种架构思想,强调将单个应用拆分为一组小型的、独立部署的服务,每个服务围绕业务能力构建。但思想落地需要工具——服务发现、配置中心、负载均衡等这些分布式系统要解决的问题,微服务本身并不提供。
Spring Cloud 是构建微服务架构的一套解决方案,规定了应用间协作的标准方式,涵盖以下核心组件:
- 服务发现:互相知道在哪里
- 远程调用:支持服务间接口调用
- 负载均衡:将请求/流量按照规定的算法分配到处理同一业务的不同机器上
- 配置管理:外部化动态配置和集中化管理配置
- API 网关:请求的统一入口
Spring Boot 则是构建单个微服务的基础框架,通过自动配置、起步依赖和嵌入式容器等特性,快速创建独立运行的 Spring 应用。
2.2 Spring Cloud 的实现方式
Spring Cloud 本身是一套标准/规范,具体实现方式主要分为以下几种技术选型方案。
站在 Java 的视角进行类比的话,Spring Cloud 相当于定义了一堆 interface,下述的 Spring Cloud Netflix/Spring Cloud Alibaba 相当于同一接口的不同实现类。
| 组件角色 | Spring Cloud Netflix | Spring Cloud Alibaba | Spring Cloud 官方原生 |
|---|---|---|---|
| 服务发现 | Eureka | Nacos | Consul / Zookeeper |
| 负载均衡 | Ribbon | Ribbon / Spring Cloud LoadBalancer | Spring Cloud LoadBalancer |
| 远程调用 | Feign | Feign / RestTemplate |


