1. 微服务介绍

1.1 系统架构的演变

随着互联网的发展，网站应用的规模也在不断的扩大，进而导致系统架构也在不断的进行变化。从互联网早期到现在，系统架构大致经过下面几个过程：单体应用架构->垂直应用架构->分布式架构->SOA架构->微服务架构，当然还有现在的Service Mesh(服务网格化)。

1.1.1 单体应用架构

在互联网发展初期，网站应用的流量普遍较小，通常采用单一应用架构。这种架构将全部功能模块集中部署，能有效降低开发、部署和维护成本。

以电商系统为例，该系统可能包含用户管理、商品管理、订单管理和物流等模块。在传统架构下，这些功能会被整合为单个Web项目，并统一部署到Tomcat服务器上运行。

优点：

项目结构简单，小型项目，开发成本低
项目部署在一个节点上，维护方便

缺点：

全部功能集成在一个工程上，对大型项目来讲不易开发和维护
项目模块之间紧密耦合，单点容错率低
无法针对不同模块进行针对性优化和水平扩展

1.1.2 垂直应用架构

在这里插入图片描述
概念

按照业务线/功能模块，把系统拆分为多个独立应用。
例如：
- 用户系统（user service）
- 订单系统（order service）
- 支付系统（payment service）
各自有独立的数据库和应用，之间通过接口交互。

✅ 优点：

降低单个应用的复杂度，团队可以并行开发。
部署隔离：更新某个模块不会影响整个系统。
可以选择不同技术栈（支付模块用 Java，推荐模块用 Python）。
对外可以按业务线提供不同入口（PC 端、App 端、管理后台）。

❌ 缺点：

系统之间接口调用增加，接口维护复杂。
数据不再集中，可能存在数据冗余 & 一致性问题。
认证、权限、日志、监控等需要在各应用间统一。

1.1.3 分布式架构

概念

在垂直应用的基础上，进一步把业务系统拆解成更小的服务单元（Service）。
通过分布式技术（RPC、消息队列、负载均衡、服务注册发现等）来管理和调用。
演进方向：SOA → 微服务（Microservices） → 云原生（Kubernetes、Service Mesh）。

✅ 优点：

高扩展性：可以对某个服务做水平扩容（例如秒杀时只扩容订单服务）。
高可用：通过服务治理、容错机制（熔断、限流、降级）保证稳定性。
灵活性：服务独立部署、迭代，团队可用不同语言实现。
可支撑大规模并发与复杂业务场景。

❌ 缺点：

架构复杂度大大提升。
服务间调用涉及网络通信开销、延迟、容错。
分布式事务、一致性问题难处理。
需要配套的服务治理体系（如注册中心、配置中心、监控报警、链路追踪）。

1.1.3.1 SOA架构

SOA（Service-Oriented Architecture，面向服务的架构）其实就是分布式架构早期的一种实现模式，它是从“垂直应用”往“分布式架构”过渡的重要阶段。

SOA 是一种架构思想，它把系统功能抽象为服务（Service），不同服务之间通过统一的服务接口协议（通常是基于网络的调用，如WebService、SOAP、ESB）进行通信和组合。

✅ 优点

解耦：通过服务接口屏蔽内部实现，不同系统只关心服务定义。
复用：一个服务可以被多个业务系统调用（例如统一的支付服务）。
灵活组合：多个服务可以通过编排组合成新的业务流程。
跨平台：不同服务可以用不同技术栈实现（Java、.NET、Python 都行）。

❌ 缺点

实现复杂：需要引入 ESB（Enterprise Service Bus）做消息路由、转换、协议适配。
性能问题：早期 SOA 大多基于 SOAP/XML，通信开销大，性能较低。
中心化风险：ESB 过度集中，容易成为瓶颈或单点故障。
运维成本高：需要大量治理（安全、事务、监控）。

SOA 和微服务（Microservices）的区别

对比维度	SOA	微服务
通信方式	传统使用 ESB + SOAP/XML	轻量化，RESTful/HTTP、gRPC、消息队列
服务粒度	相对粗，服务更大	相对细，每个服务只做一件事
服务编排	依赖 ESB，中心化编排	去中心化，服务自治，通常使用 API Gateway + 注册中心
技术复杂度	高，需要重量级中间件	相对轻，依赖云原生生态（K8s、Spring Cloud、Dubbo）
弹性扩展	不灵活，容易受限于 ESB	灵活，支持容器化、自动扩缩容

👉 可以说微服务是对 SOA 的轻量化和进化，解决了 SOA 中心化、臃肿的问题。

举个例子

假设一个电商系统：

SOA 模式下
- 有支付服务、订单服务、库存服务
- 所有应用通过 ESB 调用这些服务
- ESB 会处理协议转换、消息路由、服务编排
微服务模式下
- 每个服务独立运行
- 通过注册中心（Eureka/Nacos） + API Gateway 直接通信
- 不需要依赖一个中心化的 ESB

1.1.4 微服务架构

微服务架构是一种架构风格，它将复杂应用拆分成一组小而独立的服务。
每个服务围绕单一业务能力构建（如用户服务、订单服务、支付服务），独立开发、部署和运维，通过轻量级通信机制（HTTP REST、gRPC、消息队列等）进行交互。

微服务架构的核心特征
1.服务小而专一

每个服务只负责一个明确的业务功能。
例如：订单服务只负责订单的创建、查询，不会处理用户登录。

2.独立部署

服务是独立的进程，可以单独部署，不影响其他服务。
便于快速迭代、灰度发布。

3.去中心化治理

没有像 SOA 的 ESB 单点瓶颈。
服务之间直接通过注册中心（Eureka/Nacos/Consul）发现和通信。

4.轻量通信

常用 RESTful API、gRPC、消息队列。
弃用了 SOAP/XML 这种重量级通信协议。

5.分布式特性

支持服务弹性伸缩（秒杀时扩容订单服务）。
容错机制：熔断、限流、降级（Hystrix、Sentinel）。
配置中心、日志监控、链路追踪等支撑系统。

优缺点
✅ 优点

灵活扩展：不同服务可独立水平扩容。
高可用：某个服务挂了，不会拖垮整个系统。
技术多样性：每个服务可用最适合的技术栈（Java、Go、Python…）。
快速迭代：不同团队负责不同服务，能并行开发。

❌ 缺点

架构复杂度高：涉及服务治理、分布式事务、网络调用问题。
运维成本高：服务数量多，部署、监控、调试更复杂。
数据一致性难：一个业务可能涉及多个服务，需要分布式事务或最终一致性。
性能开销：服务之间是远程调用（RPC/HTTP），比单体的本地调用慢。

微服务 vs 单体应用 vs SOA

特点	单体应用	SOA	微服务
架构	一个整体应用	服务化，但依赖 ESB	小服务 + 去中心化治理
部署	整体部署	部署多个服务，但耦合 ESB	每个服务独立部署
通信	方法调用（本地）	SOAP/XML，依赖 ESB	REST/gRPC/消息队列
扩展性	不灵活	一定灵活，但中心化瓶颈	高度灵活，天然支持云原生
技术栈	单一	多样，但受限于 ESB	完全多样，自由度更高