鸿基建设工程有限公司网站,门户网站制作价格表,网站建立平台 cms,谷城县城乡建设局网站来源 | 阿里云云栖号责编 | 晋兆雨应用发布、服务升级一直是一个让开发和运维同学既兴奋又担心的事情。兴奋的是有新功能上线#xff0c;自己的产品可以对用户提供更多的能力和价值#xff1b;担心的是上线的过程会不会出现意外情况影响业务的稳定性。确实#xff0c;在应用… 来源 | 阿里云云栖号责编 | 晋兆雨应用发布、服务升级一直是一个让开发和运维同学既兴奋又担心的事情。兴奋的是有新功能上线自己的产品可以对用户提供更多的能力和价值担心的是上线的过程会不会出现意外情况影响业务的稳定性。确实在应用发布和服务升级时线上问题出现的可能性更高本文我们将结合 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批进行部署根据分批发布策略该发布流程如图所示就不再具体介绍了。更多阅读推荐如何应对云原生之旅中的安全挑战放弃 Windows 后 开源操作系统能成为主流桌面系统吗
8000字 | 32 张图 | 一文搞懂事务隔离级别阻塞死锁
无论南京集成电路大学成立是真是假业内关于“中国芯”的声音都应该被听见AI 还原康乾盛世三代皇帝的样貌简直太太太好玩了
