|SpringCloud应用在Kubernetes上的最佳实践


前言
阿里巴巴十多年的双十一 , 锤炼出来了一套业界领先的高可用技术 , 有一些已经商业化(云产品 PTS、AHAS) , 也有的开源了如:Sentinel、ChaosBlade 。 我们这一系列的高可用章节也主要介绍这方面的内容 。 今天介绍熔断部分 , 即开源产品 Sentinel 的核心能力 。
问题定义
在一个常见的分布式应用中 , 一个请求先通过终端到达 Gateway , 再经过防火墙和网络负载均衡 , 其中还包括调用下游的其它服务和第三方应用 , 才能到达前端网络服务;如下图所示 。
【|SpringCloud应用在Kubernetes上的最佳实践】|SpringCloud应用在Kubernetes上的最佳实践
本文插图

和这样一个架构一样 , 大家可能也会遇到如下的一些熟悉的 Case :

  • 瞬间洪峰流量导致系统超出最大负载 , load 飙高 , 系统崩溃导致无法正常提供服务 。
  • “黑马”热点数据击穿缓存 , DB 被打垮 , 挤占正常流量 。
  • 调用端被不稳定服务拖垮 , 线程池被占满 , 导致整个调用链路卡死甚至系统雪崩
  • ......
这些不稳定的场景可能会导致严重后果 。 大家可能想问:如何做到均匀平滑的用户访问?如何预防流量过大或服务不稳定带来的影响?这时候我们就要请出微服务稳定性的法宝 —— 高可用流量防护 , 其中重要的手段就是流量控制和熔断降级 , 它们是保障整个系统稳定性重要的一环 。
流量控制
流量是非常随机性的、不可预测的 。 前一秒可能还风平浪静 , 后一秒可能就出现流量洪峰了(例如双十一零点的场景) 。 然而我们系统的容量总是有限的 , 如果突然而来的流量超过了系统的承受能力 , 就可能会导致请求处理不过来 , 堆积的请求处理缓慢 , CPU/Load 飙高 , 最后导致系统崩溃 。 因此 , 我们需要针对这种突发的流量来进行限制 , 在尽可能处理请求的同时来保障服务不被打垮 , 这就是流量控制 。
|SpringCloud应用在Kubernetes上的最佳实践
本文插图

熔断降级
一个服务常常会调用别的模块 , 可能是另外的一个远程服务、数据库 , 或者第三方 API 等 。 例如 , 支付的时候 , 可能需要远程调用银联提供的 API;查询某个商品的价格 , 可能需要进行数据库查询 。 然而 , 这个被依赖服务的稳定性是不能保证的 。 如果依赖的服务出现了不稳定的情况 , 请求的响应时间变长 , 那么调用服务的方法的响应时间也会变长 , 线程会产生堆积 , 最终可能耗尽业务自身的线程池 , 服务本身也变得不可用 。
|SpringCloud应用在Kubernetes上的最佳实践
本文插图

Spring Cloud 中如何做熔断?
在原来的 Spring Cloud 产品族中 , 有自带的熔断组件 Hystrix, 是 Netflix 公司提供的一个开源的组件 , 提供了熔断、隔离、降级的这些特性 , 不过 Hystrix 在 2018 年 11 月份开始 , 就不再迭代开发 , 进入维护的模式 。 不过好消息是也就是这一年开源了 Spring Cloud for Alibaba 产品族 , 其中的 Sentinel 完美的对 Hystrix 做了补充 , 下面针对 Sentinel 做一些基本介绍 。
Sentinel 工作原理?
Sentinel 以资源流量(URL、线程、本地函数、Dubbo服务等)为切入点 , 根据用户输入的规则 , 自适应的做到流量控制、熔断降级、系统负载保护等多个维度 , 全方位的保障系统的稳定性 。 并提供了一套具备丰富的应用场景、完备的实时监控、广泛的开源生态、完善灵活的 SPI 扩展点的完美的高可用解决方案产品 , 一个基本的原理介绍图如下 , 详细介绍请参考官方文档 。
|SpringCloud应用在Kubernetes上的最佳实践


推荐阅读