Serverless 架构下的服务优雅下线实践
应用发布、服务升级一直是一个让开发和运维同学既兴奋又担心的事情。
兴奋的是有新功能上线,自己的产品可以对用户提供更多的能力和价值;担心的是上线的过程会不会出现意外情况影响业务的稳定性。确实,在应用发布和服务升级时,线上问题出现的可能性更高,本文我们将结合 Serverless 应用引擎(以下简称 SAE)就 Serverless 架构下,讨论如何保障上线过程中服务的优雅下线。
在平时的发布过程中,我们是否遇到过以下问题:
- 发布过程中,出现正在执行的请求被中断?
- 下游服务节点已经下线,上游依然继续调用已经下线的节点导致请求报错,进而导致业务异常?
- 发布过程造成数据不一致,需要对脏数据进行修复。
有时候,我们把发版安排在凌晨两三点,赶在业务流量比较小的时候,心惊胆颤、睡眠不足、苦不可言。那如何解决上面的问题,如何保证应用发布过程稳定、高效,保证业务无损呢?首先,我们来梳理下造成这些问题的原因。
场景分析
这个图描述了我们使用微服务架构开发应用的一个常见的场景,先看下这个场景的服务调用关系:
- 服务 B、C 把服务注册到服务注册中心,服务 A、B 从注册中心发现依赖的服务。
- 业务流量从负载均衡路由到服务 A,在 SLB 上配置服务 A 实例的健康检查,当服务 A 有实例停机的时候,相应的实例从 SLB 摘掉;服务 A 调用服务 B,服务B再调用服务C。
从图中,可以看到有两类流量,南北向流量(即通过 SLB 转发到后端服务器的业务流量,如业务流量->SLB->A的调用链路)和东西向流量(借助于服务注册中心服务发现调用的流量,如服务A->服务B的调用链路)
针对这两类流量我们分别进行分析。先来分析下在这种架构下南北向流量存在的问题,当服务 A 发布的时候,服务A1 实例停机后,SLB 根据健康检查探测到实例 A1 下线,然后把实例从 SLB 摘掉,实例 A1 依赖 SLB 的健康检查从 SLB 上摘掉,一般需要几秒到十几秒的时间,在这个过程中,如果 SLB 有持续的流量打入,就会造成一些请求继续路由到实例 A1,导致请求失败。
那如何保证经过SLB的业务流量不报错?我们看下 SAE 是如何做到的。
南北向流量优雅下线方案
上面提到过,请求失败的原因在于后端服务实例先停止掉,然后才从 SLB 摘掉,那我们是不是可以先从 SLB 摘掉服务实例,然后在对实例进行升级呢?
按照这个思路,SAE 基于 K8s Service 的能力给出了一种方案,当用户在通过 SAE 为应用绑定 SLB 时,SAE 会在集群中创建一个 Service 资源,并把应用的实例和 Service 关联,CCM 组件会负责 SLB 的购买、SLB 虚拟服务器组的创建,并且把应用实例关联的 ENI 网卡添加到虚拟服务器组中,从而用户可以通过 SLB 来访问应用实例;当应用发布时,CCM 组件会先把实例对应的 ENI 从虚拟服务器组中摘除,然后再对实例进行升级,从而保证了流量不丢失。
东西向流量优雅下线方案
在讨论完南北向流量的解决方案后,我们再看下东西向流量, 传统的发布流程中,服务提供者停止再启动,服务消费者感知到服务提供者节点停止的流程如下:
- 服务发布前,消费者根据负载均衡规则调用服务提供者,业务正常。
- 服务提供者 B 需要发布新版本,先对其中的一个节点进行操作,首先是停止 Java 进程。
- 服务停止过程,又分为主动注销和被动注销,主动注销是准实时的,被动注销的时间由不同的注册中心决定,最差的情况会需要 1 分钟。
- 如果应用是正常停止,Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被执行,这一步的耗时可以忽略不计。
- 如果应用是非正常停止,比如直接使用 kill -9 停止,或者 Docker 镜像构建的时候 Java 应用不是 1 号进程且没有把 kill 信号传递给应用。那么服务提供者不会主动去注销服务节点,而是在超过一段时间后由于心跳超时而被动地被注册中心摘除。
- 服务注册中心通知消费者,其中的一个服务提供者节点已下线。包含推送和轮询两种方式,推送可以认为是准实时的,轮询的耗时由服务消费者轮询间隔决定,最差的情况下需要 1 分钟。
- 服务消费者刷新服务列表,感知到服务提供者已经下线了一个节点,这一步对于 Dubbo 框架来说不存在,但是 Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ,最差情况下需要耗时 30 秒。
- 服务消费者不再调用已经下线的节点。
从第 2 步到第 6 步的过程中,Eureka 在最差的情况下需要耗时 2 分钟,Nacos 在最差的情况下需要耗时 50 秒。在这段时间内,请求都有可能出现问题,所以发布时会出现各种报错。
经过上面的分析,我们看,在传统发布流程中,客户端有一个服务调用报错期,原因就是客户端没有及时感知到服务端下线的实例造成的,这种情况主要是因为服务提供者借助注册中心通知消费者来更新服务提供者列表造成的,那能不能绕过注册中心,服务提供者直接通知服务消费者呢?答案是肯定的,SAE 主要做了两件事情。
- 服务提供者应用在发布前后主动向注册中心注销应用,并将应用标记为已下线的状态;将原来的停止进程阶段 注销服务变成了 prestop 阶段注销服务。
- 在接收到服务消费者请求时,首先会正常处理本次调用,并通知服务消费者此节点已下线,服务消费者会立即从调用列表删除此节点;在这之后,服务消费者不再调用已经下线的节点。这是将原来的依赖于 注册中心推送,变成了服务提供者直接通知消费者从调用列表中摘除自己。
通过上面这个方案,就使得下线感知的时间大大减短,从原来的分钟级别做到准实时,确保您的应用在下线时能做到业务无损。
分批发布和灰度发布
上面介绍的是 SAE 在处理优雅下线方面的一些能力,在应用发布的过程中,只有实例的优雅下线是不够的,需要有一套配套的发布策略,保证我们新业务是可用的,SAE 提供了分批发布和灰度发布的能力,可以使得应用的发布过程更加省心省力;
我们先介绍下灰度发布,某应用包含10个应用实例,每个应用实例的部署版本为Ver.1版本,现需将每个应用实例升级为Ver.2版本。
从图中可以看出,在发布的过程中先灰度2台实例,在确认业务正常后,再分批发布剩余的实例,发布的过程中始终有实例处于运行状态,实例升级过程中依照上面的方案,每个实例都有优雅下线的过程,这就保证了业务无损。
再来看下分批发布,分批发布支持手动、自动分批;还是上面的10个应用实例,假设将所有应用实例分3批进行部署,根据分批发布策略,该发布流程如图所示,就不再具体介绍了。
如果您想体验 Serverless 架构下在微服务应用的优雅下线、分批发布和灰度发布方面的能力,欢迎您登陆 SAE 的 控制台 >>
【更多精彩】
1.中间件爆款一折起,还有阿里巴巴十年最佳实践深度解密,点击马上了解:https://www.aliyun.com/activity/daily/commercial?spm=5176.20960838.0.0.6a54305etoEn4D
2.【填问卷领淘公仔】点击马上填写问卷:
https://survey.aliyun.com/apps/zhiliao/YmW95Gk8bU
【加入行业实战交流钉钉群】
阿里云专门成立了“互联网架构升级实战课”钉钉群,每周邀请一位阿里云专家在群内进行行业最佳实践直播,每天分享行业前沿干货,钉钉扫码马上加入。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
阿里宣布成立云原生技术委员会,释放哪些趋势信息?
作者 | 中国电子报记者李佳师 在今年阿里的云栖大会上,除了吸引眼球的云电脑“无影”、机器人“小蛮驴”之外,另外一个值得关注的事情是,阿里成立了云原生技术委员会,全面推动阿里经济体的云原生化。中国工程院院士王坚说,此举将“让阿里云与客户坐在同一架飞机上。”王坚为什么这样说?此举又将对未来的云计算带来哪些影响?这其中有哪些趋势信息需要关注? 云原生到了爆发的元年? 9 月 18 日,在云栖大会的第二天日早上,阿里巴巴宣布成立云原生技术委员会,负责人是阿里巴巴高级研究员蒋江伟,此外还包括达摩院数据库首席科学家李飞飞、阿里云计算平台高级研究员贾扬清、阿里云原生应用平台负责人丁宇等阿里技术负责人,组建此委员会的目的是推动阿里经济体全面云原生化,同时将阿里巴巴10多年沉淀的云原生实践,通过阿里云对外赋能数百万家企业,助力各行业迈入数字原生时代。 最近两三年,云原生这个词在业界被提及频率越来越高,专家表示,2020 年将是中国云原生的元年。按照 Gartner预测,到 2022 年有 75% 的全球企业将在生产中使用云原生的容器化应用。 究竟什么是云原生?阿里云容器平台集群管理团队负责人张瓅玶在接...
- 下一篇
复杂系统如何在不停机升级同时保持稳定?你必须考虑以下几个点...
作者:闲鱼技术-兰林 背景 在互联网行业,线上服务的升级更新可谓家常便饭。据统计,在过去的一个季度中闲鱼工程师们执行了千余次发布,总计更新的代码数量超过百万行。 这些发布中,有一些可能只更新了几行代码,而有一些可能执行了整个集群的迁移升级。而无论这些变更的影响面有多大,我们都必须保证线上服务的可用性,用户无感知。本文将以闲鱼搜索服务的迁移升级为例,向大家介绍其背后的技术方案。 闲鱼搜索服务基本架构 闲鱼的底层搜索服务由查询规划服务 Search Planner、查询理解服务 Query Planner、打分排序服务 Rank Service 以及搜索引擎 Heaven Ask 3 所组成。它们之间的相互调用关系如下图所示: 可以看到,整个搜索服务是由多个相互独立的微服务所构成的。不同的微服务之间相互隔离,通过预先向外暴露的接口提供服务。所有的微服务最终通过 Search Planner 收口,对外提供统一、完整的搜索能力。 在底层搜索服务之上,还有业务逻辑层和接入网关层,具体架构在此不再赘述。用户的搜索请求先通过网关层转发给逻辑层处理,再向底层搜索服务发起搜索请求。这条请求链上包含数十...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS8编译安装MySQL8.0.19
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- SpringBoot2更换Tomcat为Jetty,小型站点的福音