一、微服务架构核心概念
1.1 什么是微服务？
微服务是一种架构风格，将单一应用拆分为多个小型、独立部署的服务，每个服务围绕特定业务领域构建，通过轻量级通信机制协同工作，服务间松耦合、可独立扩展和迭代。
1.2 服务拆分原则
- 高内聚：一个服务只做一件事，例如 "用户服务" 仅处理用户注册、登录、信息管理。
- 低耦合：服务间依赖最小化，通过定义清晰的接口通信，避免直接操作其他服务的数据库。
- 领域驱动设计：按业务领域拆分，而非技术层，例如电商系统拆分为：用户服务、商品服务、订单服务、支付服务、物流服务。
- 避免 "分布式单体"：拆分粒度适中，避免过细导致服务数量爆炸、通信成本过高。
1.3 服务通信模式
- 同步通信 ：
- REST API：基于 HTTP/HTTPS，轻量、易理解，适合跨语言调用。
- gRPC：基于 HTTP/2，使用 Protocol Buffers 序列化，性能高，适合服务间高频通信。
- 异步通信 ：
- 消息队列：服务间通过消息传递数据，解耦强依赖，支持削峰填谷。主流组件：Kafka、RabbitMQ、RocketMQ。
- 事件驱动：服务发布事件，其他服务订阅事件并响应，适合 "最终一致性" 场景。
二、服务注册与发现
2.1 核心问题
微服务集群中，服务实例动态扩缩容，客户端如何知道 "服务在哪"？避免硬编码服务 IP 和端口。
2.2 主流组件
- Nacos：集注册中心 + 配置中心于一体，支持 AP 和 CP 模式切换，适合中小团队快速落地。
- Eureka：Spring Cloud 原生组件，基于 AP 模式，强调高可用，适合 Java 技术栈。
- Consul：基于 Raft 协议，支持健康检查、多数据中心，适合对一致性要求高的场景。
2.3 工作流程
- 服务注册：服务启动时，向注册中心注册自己的 IP、端口、服务名、健康检查地址。
- 服务发现：客户端从注册中心拉取服务列表，缓存到本地。
- 健康检查：注册中心定期检查服务实例状态，剔除不可用实例，客户端定期更新服务列表。
- 负载均衡：客户端从服务列表中选择一个实例调用。
三、配置中心
3.1 核心问题
微服务多实例、多环境，如何统一管理配置？避免修改配置后重启服务。
3.2 主流组件
- Nacos：与注册中心一体化，支持动态配置刷新、配置隔离。
- Apollo：携程开源，功能完善，支持灰度发布、配置回滚、权限管理，适合大型团队。
- Spring Cloud Config：基于 Git 仓库存储配置，需配合 Bus 实现动态刷新，适合 Git 生态团队。
3.3 关键特性
- 动态刷新：配置修改后，服务无需重启即可生效。
- 配置隔离：按环境、服务、集群隔离配置，例如 "dev 环境 - 订单服务" 的配置独立于 "prod 环境 - 用户服务"。
- 版本管理：记录配置修改历史，支持回滚到旧版本。
四、服务容错：熔断与降级
4.1 服务熔断
- 核心作用：当服务调用失败率超过阈值，自动 "断开" 调用，避免故障扩散。
- 工作状态 ：
- 闭合：正常调用，统计失败率。
- 打开：失败率超标，拒绝调用，直接返回降级结果。
- 半开：熔断一段时间后，允许少量请求尝试调用，若成功则恢复闭合，否则继续打开。
- 主流组件：Resilience4j、Sentinel。
4.2 服务降级
- 核心作用：服务压力过大或依赖服务不可用时，关闭非核心功能，释放资源保障核心功能可用。
- 降级策略 ：
- 熔断降级：触发熔断后执行降级逻辑。
- 限流降级：请求量超过阈值后降级。
- 超时降级：调用超时后降级。
- 降级示例：电商大促时，"商品评价" 功能降级为 "仅展示文字，不加载图片"，优先保障 "下单支付"。
五、服务网关
5.1 核心作用
- 统一入口：客户端所有请求通过网关进入系统，无需记住每个微服务的地址。
- 路由转发：根据请求路径将请求转发到对应微服务。
- 横切功能：认证授权、限流、监控、日志、SSL 终结。
5.2 主流组件
- Spring Cloud Gateway：基于 Netty 的异步非阻塞网关，性能高，支持动态路由、Predicate、Filter。
- Zuul：Netflix 开源，分为 Zuul 1 和 Zuul 2，Zuul 2 基于 Netty 异步，Zuul 1 为同步阻塞，目前 Spring Cloud 生态更推荐 Gateway。
5.3 关键功能
- 动态路由：通过配置中心动态修改路由规则，无需重启网关。
- 负载均衡：集成 Ribbon/Nacos，自动将请求分发到健康的服务实例。
- 限流：限制单位时间内的请求量，保护后端服务。
六、分布式事务
6.1 核心问题
跨服务操作时，如何保证数据一致性？例如 "下单" 需要调用 "订单服务" 创建订单，同时调用 "库存服务" 扣减库存，若订单创建成功但库存扣减失败，会导致数据不一致。
6.2 主流解决方案
- 2PC ：
- 流程：协调者向所有参与者发送 "准备" 请求，参与者执行操作但不提交，若都准备成功，协调者发送 "提交" 请求，否则发送 "回滚" 请求。
- 特点：强一致性，但性能差，适合金融核心场景。
- TCC ：
- 流程：Try、Confirm、Cancel。
- 特点：业务侵入式，灵活性高，适合复杂业务场景。
- SAGA ：
- 流程：将长事务拆分为多个本地事务，每个事务完成后触发下一个事务，若某一步失败，通过补偿事务回滚前面的操作。
- 特点：最终一致性，业务侵入低，适合长事务。
- 本地消息表 + MQ ：
- 流程：本地事务执行成功后，将消息写入本地消息表，通过定时任务将消息发送到 MQ，消费者消费消息并执行远程事务，确认后删除消息表记录。
- 特点：实现简单，最终一致性，适合非核心业务。
七、服务监控与可观测性
7.1 核心目标
快速定位微服务问题，包括 "哪出了问题""为什么出问题""影响范围多大"。
7.2 三大支柱
- 日志：集中收集所有服务的日志，支持检索和分析。主流组件：ELK、Loki+Grafana。
- Metrics：监控服务指标，生成可视化仪表盘。主流组件：Prometheus+Grafana、Micrometer。
- 链路追踪：追踪跨服务调用链路，展示请求从网关到各微服务的流转过程，定位慢调用、错误节点。主流组件：SkyWalking、Jaeger、Zipkin。
八、容器化与编排
8.1 容器化
- 核心价值：解决 "开发环境能跑，生产环境跑不了" 的问题，将服务及依赖打包为标准化容器，保证环境一致性。
- 主流工具：Docker，通过 Dockerfile 定义镜像，Docker Compose 管理多容器应用。
8.2 容器编排
- 核心价值：管理大规模容器集群，实现服务自动部署、扩缩容、自愈。
- 主流工具 ：Kubernetes，核心概念包括：
- Pod：最小部署单元，包含一个或多个容器。
- Deployment：管理 Pod 的创建和扩缩容。
- Service：为 Pod 提供稳定的网络访问地址。
- Ingress：管理外部访问集群内服务的规则。
九、微服务安全
9.1 服务间认证
- mTLS：双向 HTTPS，服务端验证客户端证书，客户端验证服务端证书，确保只有授权服务能通信。
- JWT Token：服务间调用时携带 Token，通过网关或拦截器验证身份和权限。
9.2 API 网关层防护
- 限流：防止恶意请求压垮后端服务。
- WAF：拦截 SQL 注入、XSS 等攻击。
- 输入校验：对请求参数进行合法性校验，避免恶意数据进入系统。
9.3 数据安全
- 传输加密：所有服务间通信使用 HTTPS/mTLS。
- 存储加密：敏感数据加密存储。
十、微服务落地挑战与建议
- 挑战：分布式事务复杂、服务依赖管理难、监控排查成本高、团队协作要求高。
- 建议 ：
- 从小规模服务开始试点，逐步推广。
- 优先解决核心痛点，再引入其他组件。
- 建立完善的 DevOps 流程，自动化部署、测试、监控。
总结：微服务不是银弹，需结合业务场景选择合适的技术栈，核心是 "以业务为中心，解耦服务依赖，提升系统弹性和可扩展性"。