以这张图来进行讲解。一、服务注册和服务配置这里核心是注册中心和配置中心。先理解核心背景为什么需要这两个中心微服务把一个大系统拆成了多个独立的小服务比如订单服务、用户服务、支付服务这些服务要协同工作就会面临两个核心问题服务找谁订单服务想调用用户服务怎么知道用户服务部署在哪个服务器、哪个端口→ 靠注册中心解决。配置怎么统一管所有服务的数据库地址、接口开关、限流规则等配置改一处要同步所有服务→ 靠配置中心解决。1.服务注册注册中心Eureka已停止维护/Nacos 微服务的 “通讯录 / 黄页”** 核心原理 **所有微服务启动时都会把自己的 “身份信息”服务名、IP、端口、健康状态注册到注册中心当 A 服务想调用 B 服务时先去注册中心查询B 服务的最新地址 注册中心会实时监控所有服务的健康状态一旦某个服务宕机立刻从通讯录中移除避免调用失败。** 典型流程以 Nacos 为例**2. 服务配置配置中心config已停止维护/Nacos微服务的 “统一配置文件管理平台”** 核心原理 **所有微服务的配置比如数据库 url、redis 密码、功能开关都集中存在配置中心微服务启动时从配置中心拉取自己需要的配置 配置需要修改时直接在配置中心改所有相关服务可动态刷新配置不用重启服务。** 典型流程以 Nacos/Apollo 为例**3.简单总结注册中心 ↔ 业务微服务双向交互服务注册 / 发现 / 心跳检测配置中心 → 业务微服务单向为主微服务拉取配置配置中心推送更新业务微服务之间通过注册中心拿到地址后直接调用比如订单服务→用户服务两者独立但协同配置中心可配置注册中心的地址微服务先从配置中心拿到注册中心地址再去注册中心注册 / 发现服务。二、负载均衡1.负载均衡的作用假设我们把menu 菜品服务部署多实例menu - 实例 1127.0.0.1:8081menu - 实例 2127.0.0.1:8082两个实例代码完全一样都能处理【查询菜品、新增菜品、修改菜品】请求并且两个实例都注册到 Nacos 注册中心。管理员在后台管理系统点击查询菜品请求先到达【服务消费者】消费者要调用menu菜品服务。如果没有负载均衡消费者只会固定访问某一个 menu 实例比如永远 80818081 压力巨大8082 空闲资源浪费如果 8081 宕机整个菜品查询功能直接不可用。这时候负载均衡就发挥作用流量分发服务消费者收到调用菜品服务的请求时自动把请求分摊到menu:8081和menu:8082多个实例分摊压力充分利用服务器资源。故障容错如果menu-8081实例挂了负载均衡组件自动感知实例不健康不再往这个故障实例转发请求自动切到正常的menu-8082菜品查询功能依然可用。弹性扩容访问菜品的请求变多时我们直接新增menu-8083实例注册到 Nacos负载均衡自动识别新实例自动分担流量不用修改消费者代码。2.使用技术LoadBalancer1注册中心Nacos多个 menu 实例启动后向 Nacos 注册自己的地址、心跳、健康状态服务消费者从 Nacos 拉取 menu 服务的全部可用实例列表负载均衡组件拿到实例清单。2负载均衡组件Spring Cloud LoadBalancer新版 SpringCloud 默认旧版本是 Ribbon2020 之后 SpringCloud 移除 Ribbon内置 LoadBalancer。内置在 OpenFeign 里面Feign 默认集成 LoadBalancer不需要额外写代码。默认策略轮询轮流把请求发给 8081、8082循环分配也可以改成随机、权重策略。3调用工具OpenFeign服务消费者使用 Feign 接口声明调用 menu 菜品服务底层自动调用 LoadBalancer 做负载均衡再发起 http 远程调用。一句话通俗总结负载均衡就是服务消费者在调用 menu 菜品服务时自动选一个健康的 menu 实例来发请求分流 容错。三、流量控制1.为什么要流量控制前面我们讲了负载均衡就是保证一个消费需求服务可以有多个服务实例运行这样当访问量大的时候可以通过轮询比如每个服务器的配置都一样压力分担、权重配置到的服务器权重设置的大一点压力也可以多分担一点等方式确保有一个健康实例提供给消费者使用。那么对于某一个服务器来说也很有可能瞬间流量非常大这时候为了防止瞬间流量暴增服务卡死就需要进行流量控制。2.使用技术Sentinel Sentinel 是 Spring Cloud Alibaba 的流量防护组件核心能力流量控制限流、熔断降级、热点参数限流、系统保护。具体场景管理员 / 用户大量请求【查询菜品】接口并发突然暴涨。假设menu菜品服务单机最多稳定扛 200 QPS。如果瞬间涌入 1000 次查询菜品请求没有 Sentinel大量请求压垮 menu 服务线程池耗尽、CPU 打满服务卡死所有菜品相关接口全部不可用甚至连锁影响调用它的订单、消费者服务雪崩。接入 Sentinel对menu的查询菜品接口设置规则保护服务。3.三大核心能力结合 menu 菜品服务举例① 限流流量控制作用限制某个接口的访问频率超过阈值直接拒绝多余请求防止流量压垮服务。示例配置对menu的/menu/list查询菜品接口限流阈值单机最多允许 200QPS。当查询菜品请求超过 200 次 / 秒后续新请求直接触发限流快速返回友好提示菜品查询繁忙请稍后再试。不会让海量请求进入服务内部消耗数据库、线程资源。② 熔断降级防止服务雪崩场景menu菜品服务数据库出现卡顿大量查询菜品请求超时 / 报错。微服务雪崩menu 变慢 → 消费者请求堆积线程全部被占满 → 消费者其他接口登录、下单也无法处理整个系统瘫痪。Sentinel 熔断规则统计/menu/list接口如果1 秒内失败率超过 50%触发熔断。熔断开启打开断路器短时间内不再调用真实 menu 接口直接走本地兜底降级逻辑返回缓存的菜品列表或者提示。熔断一段时间例如 5 秒时间窗口后进入半开状态放少量请求探测 menu 服务是否恢复。如果探测请求成功关闭熔断恢复正常调用探测继续失败则重新打开熔断。③ 热点参数限流比如根据菜品 ID 查询菜品详情接口/menu/getById?idxxx。如果有人疯狂刷热门菜品比如爆款套餐 id1这个单品查询流量暴涨其他菜品查询正常。热点限流只针对参数id1做限流限制该热门菜品每秒最多访问 10 次其他菜品 id 不受限制。4.Sentinel下载与运行参考上一篇文章Sentinel Version选择1.8.3版本下载。可以直接到这个地址下载。Sentinel 1.8.3 下载地址下载完成后将sentinel-dashboard-1.8.3.jar架包保存到放置你常用软件文件下。在该文件夹下运行架包。命令是java-jarsentinel-dashboard-1.8.3.jar默认端口8080默认账号密码sentinel/sentinel浏览器访问http://localhost:80805.注意与负载均衡的关系负载均衡LoadBalancer请求分发把请求分给多个健康 menu 实例不限制流量流量大了多个实例一起扛流量足够大照样压垮。Sentinel流量防护控制进入接口的流量故障时熔断降级保护单个实例、防止服务雪崩。两者配合使用。四、网关Spring Cloud Gateway仍然以点餐微服务项目举例我们有menu菜品服务、order订单服务、user用户服务多个微服务实例客户端小程序 / 前端网页不能直接挨个去调用各个微服务。API 网关Spring Cloud Gateway就相当于整个微服务集群的统一入口、大门所有前端请求全部先经过网关再由网关转发到后端对应的微服务。注意这里的重点就是前端。1.网关的作用1请求路由根据请求路径匹配规则转发请求。例如/menu/**转发到菜品服务/order/**转发到订单服务。前端只需要访问网关地址不用记住每个微服务的 IP 和端口。2负载均衡网关集成负载均衡能力转发请求时自动选择服务的其中一个实例和前面的负载均衡逻辑一致。注意Feign 是消费者端负载均衡Gateway 是网关层负载均衡两个位置不一样。3统一前置处理统一鉴权、token 校验、跨域处理、请求参数校验、日志打印、限流。4统一后置处理统一返回结果封装、异常响应。2.使用技术微服务体系使用Spring Cloud GatewaySCGSpring Cloud 官方推荐网关基于 WebFlux 响应式编程性能更好。旧版是 Zuul已经停止维护新项目不用。3 .请求完整流程前端请求 → Gateway 网关1网关校验 token、跨域2路2路由匹配目标是menu菜品服务3网关读取 Nacos 里 menu 服务的实例列表做负载均衡选中其中一台 menu 实例4网关转发请求到选中的 menu 服务5menu 服务内部可以用 Sentinel 做限流、熔断保护6 返回结果原路经过网关统一包装后返回前端。4.网关 和 Sentinel、负载均衡简单区分负载均衡解决「多实例请求分给谁」Feign 消费者端 / Gateway 网关层都可以做Sentinel保护服务限流、熔断、降级消费者、提供者、网关都可以接入Gateway 网关统一入口请求第一道关卡做路由、鉴权、网关层面限流。五、分布式事务首先来看分布式事务什么时候会出现。在单体项目中多个 SQL 在同一个数据库用本地事务就能保证原子性。比如你去银行取钱在取的过程中出钞机临时故障钱没有取出来那么余额也不会减少。微服务拆分之后数据库也被拆分订单是一个数据库库存可能是另一个数据库。就有可能出现这样的异常场景用户下单订单创建成功但是网络抖动库存服务调用失败。如果没有分布式事务订单存在库存没有减少 →可能会导致超卖业务数据错乱。有分布式事务要么订单和库存都提交成功一旦库存扣减失败订单自动回滚订单取消。1.使用技术微服务体系常用SeataSpring Cloud Alibaba 配套最主流提供多种模式AT 模式无侵入业务代码改动最小学习、项目首选TCC 模式侵入性强性能高适合高并发场景SAGA 模式长事务场景XA 模式强一致性性能较差。学习阶段优先使用 Seata AT 模式搭配 Nacos 作为注册中心。2.请求完整流程前端请求 → Gateway 网关 → 负载均衡路由到 order 订单服务order 服务开启分布式事务向 Seata TC 事务协调器注册全局事务生成全局事务 IDorder 服务执行本地新增订单 SQL注册 undo_log 回滚日志order 通过 OpenFeign 远程调用 stock 库存服务stock 服务收到调用执行业务扣减库存 SQL同样记录 undo_log两个服务本地事务都执行完成向 TC 汇报分支事务状态全部分支成功TC 通知所有分支提交删除 undo_log业务生效任意分支失败TC 通知所有分支根据 undo_log 回滚本地 SQL数据恢复到执行前状态。补充undo_log 是 AT 模式的关键记录数据修改前的快照用来做回滚。