认识微服务
一、单体架构
整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。
优点：上手快，部署、运维方便，适合小型项目
缺点：团队协作成本高，系统发布效率低，系统可用性差
二、什么是微服务？
微服务是一种 架构风格（Architectural Style），它将一个庞大复杂的单体系统拆分为若干个小型服务模块，每个服务模块聚焦于特定的业务功能，并可以独立开发、部署、运行和扩展。
在微服务架构中：
- 每个服务是自治的（独立运行，不依赖同进程其他服务）；
- 每个服务可以由不同的团队 使用不同的技术栈开发；
- 服务间通过轻量级通信协议（如HTTP/REST、gRPC、消息队列）交互。
三、为什么选择微服务？
- 解决单体架构的痛点
- 体积庞大、耦合严重，维护困难；
- 部署频率低，任何小改动都需要整体打包上线；
- 缺乏弹性，系统某一部分高负载时无法单独扩容。
- 提升敏捷开发与交付效率
- 不同服务可由不同团队并行开发，提高开发效率；
- 独立部署，提高上线频率，支持快速迭代；
- 故障隔离，一个服务挂掉不影响整体系统。
四、微服务的核心特征
| 特征 | 说明 |
|---|---|
| 独立部署 | 每个服务都可以单独部署上线 |
| 独立数据库 | 每个服务拥有自己的数据存储，不共享数据库 |
| 服务自治 | 服务间松耦合，内部逻辑对外不可见 |
| 小而专注 | 每个服务聚焦某一业务功能 |
| 技术异构性支持 | 不同服务可以使用不同的语言和技术实现 |
| 自动化部署与监控 | 强调 DevOps、自动化测试、日志与链路监控 |
五、微服务常见技术栈
- 服务注册与发现 ：Eureka、Consul、Nacos
- 配置中心：Spring Cloud Config、Apollo
- 服务网关 ：Spring Cloud Gateway、Kong、Nginx
- 通信方式：HTTP REST、gRPC、RabbitMQ、Kafka
- 服务熔断与限流 ：Hystrix（已过时）、Sentinel、Resilience4j
- 容器化与部署：Docker、Kubernetes（K8s）
- 监控链路追踪：Prometheus + Grafana、Zipkin、Sleuth、SkyWalking
六、微服务带来的挑战
- 服务间通信复杂：网络调用远不如本地调用稳定；
- 数据一致性问题：跨服务事务需要用最终一致性来解决；
- 部署与运维压力大：多个服务需要统一配置、监控、日志追踪；
- 测试复杂性上升：集成测试比单体更困难；
- 人员能力要求提高：需要理解分布式系统、容器、CI/CD 等一整套体系。
七、微服务 vs 单体架构
| 对比项 | 单体架构 | 微服务架构 |
|---|---|---|
| 架构复杂度 | 简单，开发和部署较方便 | 高，需要组件和治理机制 |
| 模块解耦 | 强耦合 | 松耦合 |
| 技术选型 | 技术统一 | 可多样化 |
| 扩展能力 | 整体扩展 | 按服务单独扩展 |
| 部署方式 | 整体打包部署 | 服务独立部署 |
| 运维要求 | 简单 | 要求 DevOps 能力较高 |
八、是否应该使用微服务？
适合使用微服务的场景：
- 系统足够复杂，有明确的业务模块边界；
- 团队组织清晰，有多个小团队协同开发；
- 有 DevOps 能力支持自动化部署、监控与测试；
- 系统对可用性与扩展性要求较高。
不适合使用微服务的场景：
- 项目较小，模块划分不明确；
- 团队经验不足；
- 上线周期不紧，系统变更不频繁。