Java微服务知识点详细总结

Java 微服务知识点详细总结

一、微服务基础概念

1.1 微服务定义

• 微服务是一种架构风格，将单体应用拆分为多个小型、独立的服务单元，每个服务围绕特定业务领域构建，通过轻量级通信协议（如 HTTP/REST、gRPC）交互。

• 核心特点：单一职责、独立部署、技术异构、去中心化治理。

1.2 微服务与单体架构对比

维度	单体架构	微服务架构
代码规模	代码量庞大，维护难度高	代码量小，聚焦单一业务，易维护
部署方式	整体部署，修改需重新部署全应用	独立部署，单个服务更新不影响其他
技术栈	统一技术栈，灵活性低	支持多技术栈，可按需选择（如 Java、Go）
扩展性	整体扩展，资源利用率低	按需扩展，仅扩容高负载服务
故障影响	一处故障可能导致全应用崩溃	故障隔离，仅影响单个服务

1.3 微服务核心原则

1. 单一职责原则：每个服务仅负责一个业务领域功能（如用户服务、订单服务）。

2. 独立自治原则：服务具备独立的开发、测试、部署、运维能力，不依赖其他服务的内部实现。

3. 去中心化原则：包括去中心化数据管理（每个服务有独立数据库）和去中心化治理（避免集中式决策）。

4. 容错设计原则：服务需具备故障隔离、熔断、降级能力，防止级联故障。

二、Java 微服务核心技术组件

2.1 服务注册与发现

2.1.1 核心作用

• 解决 “服务在哪里” 的问题：服务启动时将自身地址（IP、端口）注册到注册中心，其他服务通过注册中心查询目标服务地址。

2.1.2 主流组件

1. Eureka（Netflix）

• 基于 AP 设计（可用性优先），支持服务注册、心跳检测（默认 30 秒）、自我保护机制（网络波动时不剔除服务）。

• 缺点：2.0 版本后停止维护，适合中小型项目。

1. Nacos（Alibaba）

• 支持服务注册发现（CP/AP 可切换）和配置中心，功能全面，社区活跃，支持动态配置更新、服务健康检查。

• 优势：兼容 Spring Cloud，部署简单，适合中大型项目。

1. Consul（HashiCorp）

• 基于 CP 设计（一致性优先），支持服务发现、健康检查、KV 存储，通过 Raft 协议保证数据一致性。

• 适用场景：对数据一致性要求高的场景（如金融领域）。

2.2 服务通信

2.2.1 通信协议分类

1. 同步通信

• REST API：基于 HTTP 协议，简单易用，适合跨语言交互（如 Java 服务调用 Python 服务），代表框架：Spring Cloud OpenFeign（声明式 HTTP 客户端）。

• gRPC：基于 HTTP/2 协议，使用 Protocol Buffers（PB）序列化，性能高（比 REST 快 3-5 倍），适合服务间高频通信（如内部微服务调用）。

1. 异步通信

• 基于消息队列，实现解耦、削峰填谷，代表组件：RabbitMQ、Kafka、RocketMQ。

• 适用场景：非实时业务（如订单创建后发送通知、日志异步收集）。

2.2.2 服务调用框架

• Spring Cloud OpenFeign：整合 Ribbon（负载均衡），支持声明式接口调用，自动封装 HTTP 请求，示例代码：

@FeignClient(name = "user-service") // 目标服务名public interface UserFeignClient {    @GetMapping("/users/{id}")    UserDTO getUserById(@PathVariable("id") Long id);}

• Dubbo（Alibaba）：基于 RPC 协议，支持多种序列化方式（Hessian2、JSON），性能优于 OpenFeign，适合 Java 生态内服务调用。

2.3 负载均衡

2.3.1 核心作用

• 解决 “如何选择服务实例” 的问题：当多个服务实例提供同一功能时，负载均衡器将请求分发到不同实例，避免单点过载。

2.3.2 主流实现

1. 客户端负载均衡（如 Ribbon）

• 负载均衡逻辑在调用方（客户端），客户端从注册中心获取服务实例列表，自行决定调用哪个实例。

• 常见策略：轮询（默认）、随机、权重（按实例性能分配权重）、最少活跃调用数（优先调用处理请求少的实例）。

1. 服务端负载均衡（如 Nginx、Gateway）

• 负载均衡逻辑在服务端（网关或负载均衡器），客户端仅需调用负载均衡器地址，无需感知服务实例。

• 优势：集中管理，适合大型分布式系统。

2.4 服务网关

2.4.1 核心作用

• 作为微服务入口，统一处理路由转发、认证授权、限流熔断、日志监控等功能，避免每个服务重复开发。

2.4.2 主流组件

1. Spring Cloud Gateway

• 基于 Spring 5、WebFlux（响应式编程），支持动态路由、Predicate（路由匹配规则）、Filter（过滤器），性能优于 Zuul。

• 核心概念：Route（路由，包含 ID、目标 URI、Predicate、Filter）、Predicate（如路径匹配Path=/order/**、时间匹配After=2024-01-01T00:00:00）。

1. Zuul（Netflix）

• 基于 Servlet，同步阻塞模型，性能较低，1.x 版本稳定，2.x 版本停止维护，逐步被 Gateway 替代。

2.5 配置中心

2.5.1 核心作用

• 解决 “配置集中管理” 问题：将分散在各服务的配置（如数据库连接、接口地址）统一存储，支持动态更新，无需重启服务。

2.5.2 主流组件

1. Nacos：支持配置分组、命名空间（隔离环境，如 dev、test、prod），配置变更实时推送。

2. Spring Cloud Config：基于 Git 存储配置，需配合 Spring Cloud Bus（消息总线）实现配置动态刷新，操作较复杂。

2.6 服务容错

2.6.1 核心问题

• 微服务调用链长，若某一服务故障，可能导致 “级联故障”（如订单服务调用库存服务，库存服务宕机导致订单服务线程阻塞，最终订单服务不可用）。

2.6.2 主流组件与机制

1. Sentinel（Alibaba）

• 核心功能：限流（控制请求流量，避免过载）、熔断（服务故障时快速失败，避免阻塞）、降级（故障时返回默认值，如 “服务暂时不可用”）、热点参数限流（如限制某一用户 ID 的请求频率）。

• 优势：轻量级，支持控制台可视化配置，兼容 Spring Cloud、Dubbo。

1. Resilience4j

• 基于 Java 8，轻量级（无依赖），支持熔断、限流、重试、舱壁模式（隔离线程池，避免单个服务故障影响其他服务），适合微服务轻量化场景。

1. Hystrix（Netflix）

• 早期主流容错组件，支持熔断、降级、舱壁模式，但已停止维护，逐步被 Sentinel、Resilience4j 替代。

三、微服务架构设计

3.1 服务拆分原则

1. 按业务领域拆分：基于 DDD（领域驱动设计），将业务划分为多个领域（如用户领域、订单领域、支付领域），每个领域对应一个或多个微服务。

2. 避免过度拆分：服务拆分过细会导致调用链变长、运维复杂度升高，建议单个服务团队（3-5 人）可维护。

3. 数据独立：每个服务拥有独立数据库（或数据库 Schema），避免多服务共享数据库（共享数据库会导致服务耦合，无法独立扩展）。

• 例外：若多个服务需访问同一批数据且无写入冲突，可通过数据同步（如 Canal 同步 MySQL binlog）或只读副本实现。

3.2 领域驱动设计（DDD）在微服务中的应用

• 核心概念：

1. 领域：业务相关的范围（如电商领域包含订单、商品、用户子领域）。

2. 聚合根：领域模型的核心（如订单聚合根包含订单明细、支付信息），外部仅通过聚合根访问内部对象。

3. 领域服务：处理跨聚合根的业务逻辑（如订单创建时需调用库存服务扣减库存）。

• 作用：指导服务拆分，确保服务边界清晰，符合业务逻辑。

3.3 微服务通信模式

1. 同步调用：适用于实时性要求高的场景（如订单创建时需实时查询库存），但会增加调用链复杂度，需做好容错。

2. 异步调用：适用于非实时场景（如订单完成后发送短信通知），通过消息队列解耦，提高系统吞吐量。

3. 事件驱动：基于事件总线（如 Spring Cloud Stream），服务发布事件（如 “订单创建事件”），其他服务订阅事件并处理（如库存服务订阅事件扣减库存、积分服务订阅事件增加积分），实现松耦合。

四、微服务关键问题解决方案

4.1 分布式事务

4.1.1 问题背景

• 微服务中，一个业务操作可能涉及多个服务的数据库修改（如 “下单” 需修改订单库、扣减库存库、扣减余额库），需保证所有操作要么全部成功，要么全部失败，即 “事务一致性”。

4.1.2 主流解决方案

1. 2PC（两阶段提交）

• 流程：准备阶段（协调者询问所有参与者是否可提交）→ 提交阶段（所有参与者确认后，协调者下达提交命令）。

• 缺点：阻塞性（准备阶段后参与者需等待协调者命令）、单点故障（协调者宕机导致事务卡住），适合短事务、低并发场景。

1. TCC（Try-Confirm-Cancel）

• 流程：Try（预留资源，如冻结库存）→ Confirm（确认操作，如扣减库存）→ Cancel（取消操作，如解冻库存）。

• 优势：无锁、高性能，适合复杂业务场景（如金融支付），但需手动编写 Try/Confirm/Cancel 逻辑，开发成本高。

1. SAGA 模式

• 流程：将分布式事务拆分为多个本地事务，每个本地事务执行后，若后续步骤失败，通过 “补偿操作” 回滚前序步骤。

• 实现方式：

  • 编排式（如 Seata）：由协调者统一管理事务流程，开发简单。

  • choreography 式（如 Eventuate）：通过事件驱动，服务间无直接依赖，灵活性高。

1. 本地消息表

• 流程：业务操作时，先写入本地消息表（与业务表同库，保证本地事务），再异步将消息发送到消息队列，其他服务消费消息并执行业务，失败则重试。

• 优势：实现简单，适合中小规模项目，缺点：需维护消息表，消息重试可能导致重复执行（需实现幂等）。

4.2 分布式锁

4.2.1 问题背景

• 微服务中，多个服务实例并发操作同一资源（如秒杀商品库存扣减），需保证操作的原子性，避免超卖、数据不一致。

4.2.2 主流实现方式

1. Redis 分布式锁

• 核心命令：SET key value NX EX 30（NX：仅当 key 不存在时设置，EX：过期时间 30 秒），释放锁时通过 Lua 脚本保证原子性（先判断 value 是否为当前线程标识，再删除）。

• 问题解决：

  • 锁超时：设置合理过期时间，或通过 “看门狗” 线程自动续期（如 Redisson）。

  • 单点故障：使用 Redis 集群（主从 + 哨兵），避免主节点宕机导致锁丢失。

1. ZooKeeper 分布式锁

• 原理：基于 ZNode 的有序临时节点，客户端创建临时节点，若为最小节点则获取锁，否则监听前序节点，节点删除时重新竞争。

• 优势：天然支持可重入、公平锁，缺点：性能低于 Redis，适合对公平性要求高的场景。

4.3 幂等性设计

4.3.1 问题背景

• 微服务通信中，因网络重试、消息重发等原因，可能导致同一请求被重复处理（如订单创建接口被调用两次，导致创建两个订单），需保证 “重复请求的处理结果与单次请求一致”。

4.3.2 实现方式

1. 基于唯一 ID：请求时携带唯一 ID（如 UUID、订单号），服务端存储已处理的 ID，重复请求时直接返回成功。

2. 基于状态机：业务数据设计状态流转（如订单状态：待支付→已支付→已发货），重复请求时判断当前状态是否允许操作（如已支付状态不允许再次支付）。

3. 基于版本号：数据添加版本号字段，更新时携带版本号，仅当版本号匹配时更新（如UPDATE order SET status=1, version=version+1 WHERE id=1 AND version=2）。

4.4 分布式追踪

4.4.1 问题背景

• 微服务调用链长，若某一环节出现延迟或错误，难以定位问题根源，需追踪请求的完整路径、耗时、状态。

4.4.2 主流组件

• Spring Cloud Sleuth + Zipkin

  • Sleuth：在请求头中添加 Trace ID（全局唯一，标识一次请求）和 Span ID（标识调用链中的一个环节），记录调用关系。

  • Zipkin：收集 Sleuth 产生的追踪数据，通过 UI 展示调用链、各环节耗时、错误信息，帮助定位性能瓶颈。

• SkyWalking

  • 基于字节码增强（无需侵入代码），支持服务、接口、数据库的追踪与监控，性能优于 Sleuth+Zipkin，适合中大型分布式系统。

五、微服务实践与部署

5.1 开发框架

1. Spring Cloud：基于 Spring Boot，整合服务注册发现、网关、配置中心等组件，生态完善，适合 Java 开发者，主流版本：Spring Cloud Alibaba（整合 Nacos、Sentinel、Dubbo）、Spring Cloud Netflix（逐步淘汰）。

2. Spring Boot：微服务的基础框架，简化 Java 应用开发，提供自动配置、starter 依赖（如spring-boot-starter-web），支持快速构建独立服务。

5.2 容器化与编排

1. Docker：将微服务打包为容器（包含代码、依赖、环境配置），保证 “一次构建，到处运行”，解决环境不一致问题。

• 核心概念：镜像（容器模板）、容器（镜像运行实例）、Dockerfile（构建镜像的脚本）。

1. Kubernetes（K8s）：容器编排平台，支持容器的部署、扩缩容、滚动更新、故障自愈，核心组件：

• Pod：最小部署单元，包含一个或多个容器。

• Service：为 Pod 提供固定访问地址，实现负载均衡。

• Deployment：管理 Pod 的创建、更新，支持滚动更新（避免服务中断）。

• ConfigMap/Secret：存储配置信息（ConfigMap 存储明文，Secret 存储敏感信息如密码）。

5.3 持续集成 / 持续部署（CI/CD）

• CI 流程：代码提交（Git）→ 自动构建（Maven/Gradle）→ 自动测试（JUnit、Mockito）→ 生成镜像（Docker）→ 推送镜像仓库（Harbor、Docker Hub）。

• CD 流程：从镜像仓库拉取镜像 → 部署到测试环境（K8s）→ 自动验收测试 → 部署到生产环境（K8s，支持灰度发布）。

• 主流工具：Jenkins、GitLab CI、GitHub Actions。

5.4 监控与告警

1. 监控指标：

• 系统指标：CPU、内存、磁盘、网络（Node Exporter）。

• 应用指标：接口 QPS、响应时间、错误率（Spring Boot Actuator + Prometheus）。

• 日志：集中收集（ELK Stack：Elasticsearch、Logstash、Kibana），支持日志检索、分析。

1. 可视化与告警：

• Grafana：对接 Prometheus，展示监控指标图表（如接口响应）