作者 | 行松 阿里巴巴云原生团队

应用发布、服务升级一直是一个让开发和运维同学既兴奋又担心的事情。

兴奋的是有新功能上线,自己的产品可以对用户提供更多的能力和价值;担心的是上线的过程会不会出现意外情况影响业务的稳定性。确实,在应用发布和服务升级时,线上问题出现的可能性更高,本文我们将结合 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,导致请求失败;

服务 A 在发布的过程中,如何保证经过 SLB 的流量不报错?我们接着看下 SAE 是如何做的。

南北向流量优雅升级方案

如上文所提,请求失败的原因在于后端服务实例先停止掉,然后才从 SLB 摘掉,那我们是不是可以先从 SLB 摘掉服务实例,然后再对实例进行升级呢?

按照这个思路,SAE 基于 K8S service 的能力给出了一种方案,当用户在通过 SAE 为应用绑定 SLB 时,SAE 会在集群中创建一个 service 资源,并把应用的实例和 service 关联,CCM 组件会负责 SLB 的购买、SLB 虚拟服务器组的创建,并且把应用实例关联的 ENI 网卡添加到虚拟服务器组中,用户可以通过 SLB 来访问应用实例;当应用发布时,CCM 会先把实例对应的 ENI 从虚拟服务器组中摘除,然后再对实例进行升级,从而保证流量不丢失。

这就是 SAE 对于应用升级过程中关于南北向流量的保障方案。

东西向流量

东西向流量存在问题

在讨论完南北向流量的解决方案后,我们再看下东西向流量,传统的发布流程中,服务提供者停止再启动,服务消费者感知到服务提供者节点停止的流程如下:

  1. 服务发布前,消费者根据负载均衡规则调用服务提供者,业务正常。

  2. 服务提供者 B 需要发布新版本,先对其中的一个节点进行操作,首先是停止 java 进程。

  3. 服务停止过程,又分为主动注销和被动注销,主动注销是准实时的,被动注销的时间由不同的注册中心决定,最差的情况会需要 1 分钟。

    1. 如果应用是正常停止,Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能正常被执行,这一步的耗时可以忽略不计。

    2. 如果应用是非正常停止,比如直接使用 kill -9 停止,或者 Docker 镜像构建的时候 java 应用不是 1 号进程且没有把 kill 信号传递给应用。那么服务提供者不会主动去注销服务节点,而是在超过一段时间后由于心跳超时而被动地被注册中心摘除。

  4. 服务注册中心通知消费者,其中的一个服务提供者节点已下线。包含推送和轮询两种方式,推送可以认为是准实时的,轮询的耗时由服务消费者轮询间隔决定,最差的情况下需要 1 分钟。

  5. 服务消费者刷新服务列表,感知到服务提供者已经下线了一个节点,这一步对于 Dubbo 框架来说不存在,但是 Spring Cloud 的负载均衡组件 Ribbon 默认的刷新时间是 30 秒 ,最差情况下需要耗时 30 秒。

  6. 服务消费者不再调用已经下线的节点。

从第 2 步到第 6 步的过程中,Eureka 在最差的情况下需要耗时 2 分钟,Nacos 在最差的情况下需要耗时 50 秒。在这段时间内,请求都有可能出现问题,所以发布时会出现各种报错,同时还影响用户的体验,发布后又需要修复执行到一半的脏数据。最后不得不每次发版都安排在凌晨两三点发布,心惊胆颤,睡眠不足,苦不堪言。

东西向流量优雅升级方案

经过上文的分析,我们看,在传统发布流程中,客户端有一个服务调用报错期,原因就是客户端没有及时感知到服务端下线的实例。在传统发布流程中,主要是借助注册中心通知消费者来更新服务提供者列表,那能不能绕过注册中心,服务提供者直接通知服务消费者呢?答案是肯定的,我们主要做了两件事情:

  1. 服务提供者应用在发布前后主动向注册中心注销应用,并将应用标记为已下线的状态;将原来的停止进程阶段注销服务变成了 prestop 阶段注销服务。

  2. 在接收到服务消费者请求时,首先会正常处理本次调用,并通知服务消费者此节点已下线,服务消费者会立即从调用列表删除此节点;在这之后,服务消费者不再调用已经下线的节点。这是将原来的依赖于 注册中心推送,做到了服务提供者直接通知消费者从调用列表中摘除自己。

通过上面这个方案,就使得下线感知的时间大大减短,从原来的分钟级别做到准实时,确保应用在下线时能做到业务无损。

分批发布和灰度发布

上文介绍的是 SAE 在处理优雅下线方面的一些能力,在应用升级的过程中,只有实例的优雅下线是不够的,还需要有一套配套的发布策略,保证我们新业务是可用的,SAE 提供分批发布和灰度发布的能力,可以使得应用的发布过程更加省心省力;

我们先介绍下灰度发布,某应用包含 10 个应用实例,每个应用实例的部署版本为 Ver.1 版本,现需将每个应用实例升级为 Ver.2 版本。

从图中可以看出,在发布的过程中先灰度 2 台实例,在确认业务正常后,再分批发布剩余的实例,发布的过程中始终有实例处于运行状态,实例升级过程中依照上面的方案,每个实例都有优雅下线的过程,这就保证了业务无损。

再来看下分批发布,分批发布支持手动、自动分批;还是上面的 10 个应用实例,假设将所有应用实例分 3 批进行部署,根据分批发布策略,该发布流程如图所示,就不再具体介绍了。

最后针对在 SAE 上应用灰度发布的过程进行演示,点击即可观看演示过程:https://developer.aliyun.com/lesson_2026_19009

课程推荐

为了更多开发者能够享受到 Serverless 带来的红利,这一次,我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家,打造出最适合开发者入门的 Serverless 公开课,让你即学即用,轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程:https://developer.aliyun.com/learning/roadmap/serverless

Serverless 架构下的服务优雅下线实践的更多相关文章

  1. Serverless 架构:用服务代替服务器

    Serverless 架构:用服务代替服务器 转载本文需注明出处:EAII企业架构创新研究院(微信号:eaworld),违者必究.如需 加入微信群参与微课堂.架构设计与讨论直播请直接回复此公众号:&q ...

  2. 20 行代码:Serverless 架构下用 Python 轻松搞定图像分类和预测

    作者 | 江昱 前言 图像分类是人工智能领域的一个热门话题.通俗解释就是,根据各自在图像信息中所反映的不同特征,把不同类别的目标区分开来的图像处理方法. 它利用计算机对图像进行定量分析,把图像或图像中 ...

  3. spring-cloud 服务优雅下线

      在集群环境下,zuul后面的api服务一般会有多个实例,当下线某个实例时,如果使用 kill -9 pid 的方式,会造成这个服务在eureka中还存在,请求还会路由到这个服务上面,造成500,所 ...

  4. 人力节省 50%,研发效能提升 40%,阿里 Serverless 架构落地实践

    作者 | 万佳 嘉宾 | 杨皓然(不瞋) 导读:云的下一波浪潮是什么?杨皓然称"是 Serverless".作为一名阿里老兵,他早在 2010 年即加入阿里云,曾深度参与阿里云飞天 ...

  5. COS 数据湖最佳实践:基于 Serverless 架构的入湖方案

    01 前言 数据湖(Data Lake)概念自2011年被推出后,其概念定位.架构设计和相关技术都得到了飞速发展和众多实践,数据湖也从单一数据存储池概念演进为包括 ETL 分析.数据转换及数据处理的下 ...

  6. Apollo:微服务架构下的配置管理

    问题背景 在实际工作中,我们的开发环境,测试环境,生产环境对应的 Mysql 数据库,Redis 这些信息都不一样,每个环境都有对应的一套配置,在 Spring Boot 中我们通常会编写多个配置文件 ...

  7. 了解Serverless架构

    1 概述 Serverless中文译为“无服务”是一种新兴起的架构模式,公司ESB产品引入Rest微服务服务机制过程,笔者刚好参与其中,其中Serverless作为一个新起的概念,跟微服务架构相关,为 ...

  8. Serverless架构详解:开发者如何专注于业务代码本身?

    本文来自腾讯云技术沙龙,本次沙龙主题为Serverless架构开发与SCF部署实践 演讲嘉宾:黄文俊,曾负责企业级存储.企业级容器平台等产品的架构与开发,目前主要负责SCF腾讯无服务器云函数产品相关. ...

  9. 【转】Serverless架构

    这是来自martinfowler.com的Serverless架构一文的大意翻译. 什么是Serverless?    Serverless首先是用于描述我们的应用程序是明显或充分地依赖第三方应用或服 ...

随机推荐

  1. 回忆(一):反射中获得class对象的三种方法

    package reflex; /* * 反射:就是通过class文件对象 去使用该文件中的成员 * 变量,构造方法,成员方法. * * Person p = new Person(); p.使用 * ...

  2. Hibernate框架基本使用

    时间:2017-1-16 00:36 --什么是Hibernate    Hibernate是一个开放源代码的关系映射框架,它对JDBC进行了非常轻量级的对象封装,使得Java程序员可以使用对象编程思 ...

  3. Struts2之OGNL与ValueStack

    时间:2017-1-12 12:02 --OGNL1.OGNL表达式是什么    OGNL的全称是Object-Graph Navigation Language的缩写,中文名是对象图导航语言,它是一 ...

  4. Buffer和Cache的异同

    Buffer的本质是缓冲,常见实例如下面这个: 对,就是铁道端头那个巨大的弹簧一类的东西.作用是万一车没停住(是没停住啊,刹车了但是差一点没刹住那种,不是不拉刹直接撞上来),撞弹簧上减速降低危险,起到 ...

  5. Python实现GPU加速的基本操作

    技术背景 之前写过一篇讲述如何使用pycuda来在Python上写CUDA程序的博客.这个方案的特点在于完全遵循了CUDA程序的写法,只是支持了一些常用函数的接口,如果你需要自己写CUDA算子,那么就 ...

  6. ES6扩展——函数扩展之剩余函数

    1.结合扩展运算符 //剩余参数是做聚合的,扩展运算符是做展开的 function sum(...args){ console.log(arguments); console.log(argument ...

  7. Mysql基本知识整理

    一.简介 1.什么是数据库? 数据库(Database)是按照数据结构来组织.存储和管理数据的仓库,每个数据库都有一个或多个不同的API用于创建,访问,管理,搜索和复制所保存的数据. 2.关系型数据库 ...

  8. 从源码角度分析 MyBatis 工作原理

    一.MyBatis 完整示例 这里,我将以一个入门级的示例来演示 MyBatis 是如何工作的. 注:本文后面章节中的原理.源码部分也将基于这个示例来进行讲解.完整示例源码地址 1.1. 数据库准备 ...

  9. Robot Framework(8)- Collections 测试库常用的关键字列表

    如果你还想从头学起Robot Framework,可以看看这个系列的文章哦! https://www.cnblogs.com/poloyy/category/1770899.html 前言 所有关键字 ...

  10. django报错外理收集

    网址指向同一地址后: Forbidden (403) CSRF verification failed. Request aborted. You are seeing this message be ...