西安网站设计培训试听,wordpress媒体图片压缩比,桂林餐饮兼职网站建设,seolxw前言
上篇我们讲的是发布回滚过程#xff0c;尤其是在 Kubernetes 的回滚过程中#xff0c;原生有提供 Rollout 到上一个版本的能力#xff0c;能保证我们在发布过程中遇到问题时快速回退的能力。然而在每一次上线的过程中#xff0c;我们最难处理的就是正在运行中的流量尤其是在 Kubernetes 的回滚过程中原生有提供 Rollout 到上一个版本的能力能保证我们在发布过程中遇到问题时快速回退的能力。然而在每一次上线的过程中我们最难处理的就是正在运行中的流量如何做到流量的无损上/下线是一个系统能保证 SLA 的关键。
介绍
什么是优雅上线就如下面这个房子一样未建好的房子人住进去会有危险房子应该建好装修好人才能住进去。 那么如何做到优雅上线我们先来看一个WEB应用的加载过程就像上面造房子一样是个漫长的过程 应用的加载是漫长的在加载过程服务是不可预期的如过早的打开Socket监听则客户端可能感受到漫长的等待如果数据库、消息队列、REDIS客户端未完成初始化则服务可能因缺少关键的底层服务而异常。 所以在应用准备完成后才接入服务即做到优雅上线。当然应用上线后也可能因如数据库断连等情况引起服务不可用或是准备完成了但在上线前又如发生数据库断连导致服务异常。为了简化问题后面两种情况作为一个应用自愈的问题来看待。 什么是优雅下线与建房子相反就像下面的危房一样人住在里面很危险人应该先从房子出来然后推掉房子。
那么如何做到优雅下线我们先来看一个WEB应用的停止过程
所以关闭服务接入转移服务接入完成正在处理的服务清理自身占用的资源后退出即做到优雅下线。
如何实现优雅下线
从上面介绍看似乎不难但事实上很少系统真正实现了优雅上下线。因为软件本身由无数各种各样相互依赖的结构组成每个结构都使用一些资源污染一些资源通常在设计之初优雅上下线也不被作为优先考虑的需求所以对于下线的过程通常都没被充分考虑在设计上通常要求
结构组件应形成层次关系。用户线程需能收到停止信号并响应退出否则使用daemon线程。结构应按依赖关系自下向上构建就像建房子一样自内向外构建而成。结构应按依赖关系自上向下销毁就像拆房子一样自外向内拆解。
优雅下线实现路径
大致分为一个完整的过程需要经历一下四个关键的节点如下图
接收信号停止信号可能从进程内部触发比如 Crash 场景如果自退出的话基本上无法保证优雅下线所以能保证优雅下线的前提就是需要正确处理来自进程外部的信号。停止流量接收由于在停止之前我们会有一些正在处理的请求贸然退出会对这些请求产生损耗。但是在这段时间之内我们绝不能再接收新的业务请求如果这是一个后台任务型消息消费型或任务调度型的程序也要停止接收新的消息和任务。对于一个普通的 WEB 场景这一块不同的场景实现的方式也会不一样下面的 Srping Cloud 应用的下线流程会详细讲解。销毁资源常见的是一些系统资源也包括一些缓存、锁的清理、同时也包括线程池、关闭阻塞中的的IO操作等到我们这些服务器资源销毁之后就可以通知主线程退出。
Spring Cloud应用
一个Spring boot应用通常由应用本身加一系列的Starter组成对于Spring boot体系需要了解如下核心概念
Starter提供一系列的模块由Spring boot核心通过auto-configuration机制加载。Bean一切皆Beanstarter模块的加载产生各种Bean。ContextBean的容器容器拥有生命周期Bean需要感知生命周期事件。LifeCycle生命周期管理接口。ApplicationEvent模块之间模块与容器之间通过发送或监听事件来达到互相通讯的目的。 所以对于应用上下线这个主题我们应尽可能利用其丰富的原生事件机制Spring Cloud 中内置的 Starter 机制针对整个生命周期管理的过程有了很好的封装。
Spring Cloud应用的优雅上线
Spring Cloud 启动过程触发回调及事件如下详细介绍见application-events-and-listeners简单罗列如下
Spring自身及其组件大量基于这些事件构建如响应WebServerInitializedEvent事件向服务注册中心注册服务对于应用一般可利用
InitializingBean or PostConstruct在Bean装配完后被回调如完成数据源初始化连接。ApplicationReadyEvent、ApplicationRunner、CommandLineRunner如开始监听消息队列处理消息注册到SLB等先通过配置禁用服务的自动注册在这里做手动服务注册。
Spring Cloud应用的优雅下线
Spring Cloud 本身可以作为一个应用单独存在也可以是依附在一个微服务集群中同时还能作为反向代理架构中的一个网关。不同的场景需要用到的方法也不一样我们就常用的三种场景针对性的加以说明。
场景一直接访问WEB服务 客户端直接访问WEB应用在这个用例下优雅下线需要做的事情有
正在处理的请求完成处理应用自身完成的安全下线并正常退出客户端感知到连接异常
Spring-boot从2.3开始内置了WEB应用优雅下线的能力需配置如下具体介绍参见graceful-shutdown
server.shutdowngraceful
spring.lifecycle.timeout-per-shutdown-phase20s
其实现方式
首先关闭socket监听等待正在处理的所有请求完成具体可见WebServerGracefulShutdownLifecycle通过getPhase返回最大值达到早于WEB容器关闭执行的目的然后触发WEB容器关闭具体可见WebServerStartStopLifecycle
但其实对于未被WEB容器完全接收的请求客户端仍会收到连接被重置的异常只是这个时间窗口极小。该需求从提出到实现的时间跨度较长感兴趣的可参见github上的讨论。
场景二经由反向代理的服务优雅下线 因为实例前面还有反向代理相比上个场景需要新增“反向代理下线”这个处理流程。即若应用已经下线但反向代理未摘除该应用实例时客户端将感知到失败。一般采取的策略有
反向代理支持失败转移到其它应用实例在关闭应用前如将健康探测接口返回不健康以及等待足够的超时让反向代理感知并摘除实例的路由信息。
对于仍在使用2.3以前版本的Spring Cloud应用可参见一个方案实现方式
使用自身的shutdownHook替换Spring的shutdownHook先改变health状态等待一段时间让反向代理感知并摘除实例的路由信息
场景三在微服务集群中下线单个服务 在优雅关闭Spring Cloud应用自身之前我们除了完成场景一之中的目标之外还需要将自身节点从注册中心中下线。目前在Spring Cloud中针对注册中心下线的场景暂未提供开箱即用的方法下面介绍两种可能的实现方案
方案1先通过脚本、或通过监听ContextClosedEvent反注册服务摘除流量等待足够时间如使用ribbon负载均衡器需要长于配置的刷新时间对于基于HTTP的服务若Spring Cloud版本小于2.3则时间需加上预期的请求处理时间。方案2客户端支持连接感知重试如重试实现方案可参考Spring-retry针对连接异常RemoteConnectFailureException做重试。 针对 Eureka 中的场景有一个很好的参考的例子请参见https://home1-oss.github.io/home1-oss-gitbook/release/docs/oss-eureka/GRACEFUL_SHUTDOWN.html
Kubernetes 下的机制
Kubernetes 中针对应用的的管控提供了丰富的手段正常的情况他提供了应用生命周期中的灵活的扩展点同时也支持自己扩展他的 Operator 自定义上下线的流程。
抛开实现成本以下线的情况来说一个 Kubernetes 应用实例下线之前管控程序会向 POD 发送一个 SIGTERM 的信号应用响应时除了额外响应这一个信号之外还能触发一段自定义的 PreStop 的挂在脚本代码样例如下
yaml
lifecycle: preStop: exec: command: - sh- -c- sleep 5
上面的例子一点特殊说明因服务控制面刷新与POD收到SIGTERM同时发生所以这里通过sleep 5让服务控制面先完成刷新应用进程再响应SIGTERM信号。
Spring Cloud 与 Kubernetes 的结合
Kubernetes 会根据健康检查的情况来更新服务(Service)列表其中如果 Liveness 失败则会触发容器重建这是一个相对很重的操作若 Readiness 失败则 Kubenetes 则默认不会将路由服务流量到相应的容器基于这一基理Spring Cloud 2.3开始也做了原生的的支持具体参见 liveness-and-readiness-probes-with-Spring-boot这些健康检查端点可对接kubnetes相应的probe
/actuator/health/liveness/actuator/health/readiness
同时Spring Boot 内置了相应的 API、事件、Health Check 监控部分代码/配置片段如下
java
// Available as a component in the application context
ApplicationAvailability availability;LivenessState livenessState availabilityProvider.getLivenessState();
ReadinessState readinessState availabilityProvider.getReadinessState();
....
// 对于应用也可以通过API发布相应的事件来改变应用的状态
AvailabilityChangeEvent.publish(this.eventPublisher, ex, LivenessState.BROKEN);// 同时应用监控也可影响这健康状态将监控与健康关联在K8S体系下可以实现如离群摘除应用自愈的能力
// application.properties
management.endpoint.health.group.liveness.includelivenessProbe,cacheCheck
回到 Spring Cloud 应用 在微服务集群中下线单个服务 的章节中我们的应用如果跑在 Kuberntes 中如果我们使用了原生的 Kubernetes 机制去管理应用生命周期的话只需要发布一个应用事件(LivenessState.BROKEN)即可实现优雅下线的能力。 后续
这一章节之后和发布相关的内容都已经更新完毕下一章节我们要开始高可用部分的能力高可用也是系统保障 SLA 的关键部分简单的理解是流量洪峰到来如何保证系统不会受到影响当然我们还有一部分要达成的是洪峰退去之后资源是否存在浪费敬请期待 ... 原文链接 本文为阿里云原创内容未经允许不得转载。
