什么是微服务

[1 概述](#1 概述)

[1.1 发展史](#1.1 发展史)

[1.2 微服务概述](#1.2 微服务概述)

1 概述

1.1 发展史

框架发展史
Servlet

是什么：Java 定义的 "服务器端小程序" 规范（属于 Java EE 标准），是早期 Java 开发 Web 应用的底层基础技术。
作用：负责接收前端请求、处理业务逻辑、返回响应，比如早期的 Java Web 项目（如电商网站）会直接基于 Servlet 开发。
痛点：纯 Servlet 开发需要手写大量重复代码（如请求参数解析、响应结果封装），开发效率极低。

组成：Struts2（Web 层） + Spring（核心层） + Hibernate（持久层）。
作用：是早期 Java 企业级开发的 "经典三件套"，通过框架分工解决了纯 Servlet 开发的痛点：
- Struts2：接管 Web 层，负责请求路由、参数封装，替代了 Servlet 的手动请求处理；
- Spring：作为 "胶水" 整合各层，提供依赖注入、事务管理等核心能力；
Hibernate：接管持久层（操作数据库），通过 "对象 - 关系映射（ORM）" 自动完成 Java 对象与数据库表的映射，替代了 JDBC 的手动 SQL 操作。

组成：Spring（核心层） + SpringMVC（Web 层） + MyBatis（持久层）。
作用：是 SSH 的 "轻量化替代方案"，解决了 SSH 过于笨重的问题：
- SpringMVC：替代 Struts2，是 Spring 家族的 Web 层框架，更轻量、与 Spring 整合更紧密；
MyBatis：替代 Hibernate，是 "半 ORM" 框架，允许开发者手动控制 SQL 语句，比 Hibernate 更灵活（Hibernate 会自动生成 SQL，对复杂查询支持不足）。

SpringBoot

作用：不是 "新框架"，而是Spring 生态的 "脚手架"，核心是 **"自动装配" 和 "开箱即用"**：
- 它把 SSM 等框架的整合过程 "自动化"，你只需引入依赖（如 spring-boot-starter-web），就能直接开发 Web 接口，不用再手动配置 SpringMVC、Tomcat 等组件；
内置了大量 "启动器（Starter）"，比如 spring-boot-starter-jdbc 会自动配置数据库连接池，让开发者从繁琐的配置中解放出来。

SpringCloud

作用：是微服务架构的 "治理框架集合"，基于 SpringBoot 构建，解决微服务拆分后的一系列问题：
- 服务注册与发现（如 Eureka、Nacos）：让微服务之间能自动找到彼此；
- 负载均衡（如 Ribbon）：把请求分散到多个服务实例上，避免单点压力；
- 服务熔断（如 Hystrix）：防止某个服务故障导致整个系统崩溃；
配置中心（如 Config）：统一管理所有微服务的配置文件。

项目架构发展史
单体

特点：整个项目的所有功能（用户登录、商品展示、订单支付等）都打包在一个 WAR/JAR 包里，部署在一台服务器上。
例子：早期的博客系统，所有功能都在一个应用里，代码耦合度高。
痛点：一处代码 bug 可能导致整个系统崩溃；新增功能需要全量发布，迭代周期长。

聚合

特点：从 "纯单体" 过渡到 "按业务模块拆分"，但模块之间仍通过本地调用（如方法调用）耦合，未完全独立。
例子：把电商系统拆分为 "用户模块""商品模块""订单模块"，但模块代码仍在同一个项目里，只是包结构分开。

SOA（面向服务架构）

特点：模块彻底独立为 "服务"，通过 "服务总线"（如 ESB）通信，每个服务可独立部署。
例子：用户服务、商品服务、订单服务分别部署在不同服务器，通过服务总线调用彼此接口。
痛点：服务总线过于笨重，服务之间依赖仍较深，维护成本高。

微服务

特点：是 SOA 的 "轻量化升级"，每个服务更小、更独立，遵循 "单一职责原则"，通过 HTTP/REST 等轻量级协议通信。
例子：一个电商系统可能拆分为 "用户微服务""商品微服务""购物车微服务""支付微服务" 等，每个微服务可独立开发、测试、部署。
优势：技术栈灵活（不同微服务可选不同语言）、容错性强（一个服务故障不影响全局）、迭代速度快（单个服务可频繁更新）。

技术发展史

早期项目以单体架构为主，基于 Servlet 技术开发；
后来出现了 SSH、SSM 等框架集成方案，项目架构向聚合、SOA（面向服务架构）演进；
随着 2014 年微服务概念的提出，SpringBoot（简化单体开发）、SpringCloud（支撑微服务治理）等框架快速发展，项目架构正式进入微服务时代。

1.2 微服务概述

微服务这个概念是2014, martin fowler（马丁・福勒）提出的。定义了这种将大型应用拆分为多个独立小服务的架构风格，为后续分布式系统的发展奠定了理论基础。
微服务是一种架构风格（服务微化）。
微服务就是把一个大应用拆成多个小型的、有独立业务功能的服务单元，每个服务都能自己处理业务，靠简单的通信方式（比如 HTTP）和其他服务互动，能部署在一台或多台服务器上。它也是一种 "松耦合" 的服务架构，每个服务都有自己明确的业务边界。
一个完整的应用应该由这一组小型服务组成，它们之间通过 HTTP 等方式互相调用。
单体应用是 "所有功能都塞在一个包里"（ALL IN ONE）；而微服务里，每一个功能模块最终都是可以独立替换、独立升级的软件单元------ 比如想升级支付功能，只需要更新 "支付微服务"，不用动其他服务。
微服务文档https://martinfowler.com/articles/microservices.html#MicroservicesAndSoa
微服务优点：
每一个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是开发阶段或是部署阶段都是独立的。
微服务能够使用不同的语言开发。
微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，一个团队的新成员能够更快投入生产。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，
微服务能够即时被要求扩展。
微服务能够部署中低端配置的服务。
易于和第三方集成。
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。
微服务缺点：
微服务架构可能带来过多的操作，可能需要双倍的努力，分布式系统可能复杂难以管理
因为分布部署跟踪问题难，当服务量增加，管理复杂性增加