“微服务“一词总是出现,它是什么?
一句话定义微服务
微服务（Microservices）是一种将单个应用程序拆分为一组小型、独立、松耦合、可独立部署的服务的架构风格，每个服务运行在自己的进程中，通过轻量级通信机制（通常是 HTTP/REST 或消息队列）协同工作。
▶ 单体架构（传统方式）：
✅ 优点：开发简单、调试方便、部署单一
❌ 缺点：
- 一个模块出 bug，整个系统崩溃
- 团队协作冲突（10 个人改同一个 Git 仓库）
- 技术栈无法灵活选型（比如想用 Python 做推荐，但整个系统是 Java）
- 扩展性差（某模块压力大，但你只能整体扩容）
▶ 微服务架构：
✅ 优点：
- 独立开发、部署、扩展：某服务压力大？单独给它加 3 台服务器。
- 技术异构：推荐系统用 Python + TensorFlow，支付系统用 Java 保稳定。
- 容错性强：某服务挂了，用户还能浏览其他服务。
- 团队自治：每个小团队负责一个服务，Git 仓库独立，发布节奏自由。
❌ 缺点：
- 架构复杂度飙升（服务发现、配置中心、链路追踪、分布式事务…）
- 运维成本高（需要 Kubernetes / Docker / CI/CD 自动化）
- 网络通信开销（原来内存调用，现在 HTTP 调用）
微服务的核心组件（企业级架构必备）
要玩转微服务，你必须知道这些“基础设施”：
服务注册与发现 | 服务自动注册、互相能找到对方 | Java: Eureka / Nacos / Consul |
API 网关 | 统一入口、路由、鉴权、限流 | Spring Cloud Gateway / Kong / APISIX |
配置中心 | 集中管理所有服务的配置 | Spring Cloud Config / Nacos / Apollo |
分布式链路追踪 | 查看一个请求经过哪些服务 | Zipkin / Jaeger / SkyWalking |
消息队列 | 异步解耦、削峰填谷 | RabbitMQ / Kafka / RocketMQ |
容器化部署 | 标准化打包、快速扩缩容 | Docker + Kubernetes |
服务熔断/降级 | 防止雪崩效应 | Hystrix / Sentinel / Resilience4j |
什么项目才“需要”微服务？—— 对照表
机房/仓库/学校后台管理系统 | ❌ 不适合 | 功能内聚、用户量小、无高并发、团队小 |
电商平台（淘宝/京东级别） | ✅ 必须 | 亿级用户、模块复杂（商品/订单/支付/推荐）、团队上百人 |
银行核心交易系统 | ✅（但用 SOA 更多） | 高可用、强一致性、监管要求 |
AI 模型服务平台 | ✅ 适合 | 模型推理用 Python，前端用 Java，技术异构 |
初创公司 MVP 产品 | ❌ 先单体 | 快速验证、节省成本、避免过早优化 |