认识微服务

认识微服务

一、单体架构

整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。

优点：上手快，部署、运维方便，适合小型项目
缺点：团队协作成本高，系统发布效率低，系统可用性差

二、什么是微服务？

微服务是一种 架构风格（Architectural Style），它将一个庞大复杂的单体系统拆分为若干个小型服务模块，每个服务模块聚焦于特定的业务功能，并可以独立开发、部署、运行和扩展。

在微服务架构中：

• 每个服务是自治的（独立运行，不依赖同进程其他服务）；
• 每个服务可以由不同的团队使用不同的技术栈开发；
• 服务间通过轻量级通信协议（如HTTP/REST、gRPC、消息队列）交互。

三、为什么选择微服务？

1. 解决单体架构的痛点

• 体积庞大、耦合严重，维护困难；
• 部署频率低，任何小改动都需要整体打包上线；
• 缺乏弹性，系统某一部分高负载时无法单独扩容。

2. 提升敏捷开发与交付效率

• 不同服务可由不同团队并行开发，提高开发效率；
• 独立部署，提高上线频率，支持快速迭代；
• 故障隔离，一个服务挂掉不影响整体系统。

四、微服务的核心特征

五、微服务常见技术栈

• 服务注册与发现：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 能力支持自动化部署、监控与测试；
• 系统对可用性与扩展性要求较高。

不适合使用微服务的场景：

• 项目较小，模块划分不明确；
• 团队经验不足；
• 上线周期不紧，系统变更不频繁。