【JAVA】BOSS系统发版艺术：构建高效、优雅的微服务部署策略

在现代软件开发领域，微服务架构与容器化部署已迅速成为行业新趋势。微服务架构通过将应用拆分成多个小型、自治的服务单元，每个服务承担某项特定的业务功能。而容器化部署则以其轻量级和高度可移植的特性，为这些微服务的有效打包、分发和运行提供了强大支持。

在这样的环境中，实现微服务的优雅上下线变得至关重要。优雅上下线意味着在进行服务更新、扩展或缩减服务规模时，能够无缝切换，避免或最小化对用户的影响。这种做法不仅保障了系统的高可用性和稳定性，还大幅提升了开发和运维团队的工作效率。

本文将深入探讨如何借助容器化技术，实现微服务的优雅上下线。我们将分享一系列实用的方法和策略，包括滚动升级、就绪检查以及优雅关闭等。通过采用这些策略，您能在进行版本更新、规模调整或故障恢复期间，确保系统的连续稳定运行，从而显著提升整体的系统可靠性和稳定性。

1 项目背景

BOSS物业管理系统（以下简称“BOSS系统”）是碧桂园服务（以下简称“碧服”）体系中的核心主营收费系统，它主要负责管理客户、房屋及车位等基础数据，并支持物业费、合同类、表计类、车位类及临时类费用的全自动化计费。BOSS系统采用微服务架构和容器化部署，拆分成30个不同功能的微服务。这种设计虽然大幅提升了系统的灵活性和可维护性，却也增加了服务发版部署的时长。

此外，在发版过程中，服务可能会出现短暂的中断，或者在服务停止时还有未完成的异步线程的任务，导致业务数据的不完整，进而引发大量的运维工单，增加运维成本的同时也影响了用户体验。

当前，BOSS系统采用了敏捷开发模式，其显著特点之一是小步快跑。这种模式使我们能够以更快的速度推出新功能和优化现有功能，迅速响应用户业务需求的变化。在这种开发模式下，发版效率显得尤为重要。以往，每次部署时长约两小时，再加上发版后的验证回归和测试，整个流程可能需要数小时才能完成。这样漫长的发版流程不仅占用了团队大量的时间和资源，还增加了出错的风险。

2 如何实现高效

2.1 引入发版的checklist

由于BOSS系统的服务拆分的比较细，若全量发版则需要发布30个服务。每次发版不仅包括数据库更改脚本、nacos配置更新及XXL-Job任务调度等内容，还有服务清单和代码迁入的情况。如果在发版前没有进行充分的检查与准备，后续可能需要多次更新服务，极大地增加了整个发版时长。

为了解决这一问题，引入发版checklist显得尤为重要。该checklist能够帮助盘点上线事项，并回顾开发过程中的各个细节。通过checklist，团队可以更有序地执行发版流程，从而提高发版的效率和准确性。

上线checklist包括以下几个关键内容：

1、上线前准备：此阶段需准备数据库脚本、nacos配置、XXL-Job任务以及一些提前编写好的配置文件等；

2、上线步骤：包括更新的SQL、各个模块的更新顺序以及是否依赖公共包等。对于C端应用，需要注意服务端与前端的发布先后顺序；

3、需验证的事项：在每个模块更新完成后，需采取相应的措施来验证其是否正常，例如观察页面、检查日志和监控是否正常等；

4、明确人与时间：checklist应尽可能详细，明确具体的人员和特定时间段的任务安排；

5、评估对用户的影响：在每个步骤完成后，需要评估对用户的影响，并关注相应的内容；

6、提前做好预发回归：预发环境应与生产环境的数据源相通。在预发环境中，可以模拟线上更新的步骤，提前预演一遍。为避免预发环境对线上的影响，可考虑使用白名单控制访问权限，同时注意用户权限的回收，以防止误操作影响线上环境。

2.2 容器升级策略

在容器化部署中，滚动更新允许逐个替换Pod实例以实现零停机的Deployment更新。新创建的Pod将会被调度到可用资源的节点上。

在阿里云k8s中，默认采用滚动升级策略。此策略下“不可用Pod最大数量”和“超出期望的Pod数量”都是25%。然而，当节点资源的内存严重紧张时，日常使用平均内存利用率已经超过80%，并且需要同时更新30个服务，尤其是这些服务配置的内存需求多集中在8至16GB之间，就可能导致发版过程中节点池的内存资源不足以支撑这么多Pod的同时申请，导致容器尝试滚动升级时大量Pod处于pending状态，等待分配资源。

我们通过优化容器升级策略，在不增加节点服务器资源前提下，实现了快速的滚动升级。考虑到常规发布操作安排在非高峰时段，因此可以接受不可用Pod的最大数量控制在25%至80%之间。这种调整显著释放了节点资源，极大地提升了后续的容器滚动升级速率。

2.3 发版汇总

通过最近几次的发版汇总记录进行分析，我们可以发现，初次执行全量发布30个服务的操作耗时约两小时。然而，在引入发版checklist和优化容器升级策略后，第二次进行全量发版的时间大幅缩短至半小时内。目前，全量发版仅需20分钟即可完成，而对于日常的少量服务发版，则仅需10分钟。发版时间的显著缩短，为后续的测试验证工作提供了更加充裕的时间，从而提高了整个发版与验证的效率。

3 微服务优雅上下线设计与实践

3.1 什么是微服务优雅上下线

微服务优雅上下线的基本原理是指在微服务更新发布过程中确保服务的稳定性和可用性，防止由于服务变更引起的流量中断或错误。

实现微服务的优雅上下线，旨在避免以下问题：

• 过早的注册服务：服务尚未完全就绪时就注册到了注册中心，开始接受请求，导致业务异常；

• 过早退出应用程序：服务还在处理请求时，应用程序被强制终止，导致正在进行的请求出现错误。

  针对这些问题，我们可以采取以下优化措施：

  • 优雅上线：在服务启动后，等待服务完全就绪后再对外提供服务，或者有一个服务预热过程；

  • 优雅下线：在服务停止前，先从服务注册中心注销，拒绝新的请求，并等待旧的请求处理完毕后再下线服务，从而确保所有请求都能得到妥善处理。

    3.2 实现微服务在容器中优雅上下线 

    1、优雅上线

    在实现微服务的优雅上线过程中，我们可以利用k8s的就绪检查与微服务生命周期对齐，等完成服务注册与准备就绪后，再开始接受外部流量。

    就绪检查接口一般包括数据库连接状态、redis连接状态、nacos注册状态及调用预热接口等工作。

    我们可使用Spring Boot Actuator提供的健康检查接口/health来做就绪检查：

    引入依赖

        org.springframework.boot    spring-boot-starter-actuator

    启用liveness和readiness探针

    management:  server:    port: 8088  endpoints:    web:      exposure:        include: health,info,metrics,prometheus,monitoring,deregister  endpoint:    health:      show-details: always    probes:      enabled: true  health:    livenessstate:      enabled: true    readinessstate:      enabled: true

    health/readiness接口会严格检查SpringBoot的各项组件服务，比如邮件服务、数据库服务及MQ服务等。当所有组件处于正常状态时，它会返回内容{"status": "UP"}，否则返回{"status": "down"}。

    2、优雅下线

    在实现微服务的优雅下线过程中，我们可以结合使用SpringBoot的优雅停机方案和k8s生命周期管理（停止前处理）来实现服务的优雅退出。

    SpringBoot的优雅停机使用方式：

    通过配置文件的方式即可开启优雅停机，需要配置server.shutdown属性和宽限期。宽限期会影响到同步请求的超时中断。

    # 开启优雅关闭server:  shutdown: graceful# 配置强制结束时间，不配置的话默认30sspring:  lifecycle:    timeout-per-shutdown-phase: 60s  cloud:  loadbalancer:    cache:      ttl: 10s  

    在Spring Cloud LoadBalancer中，为了优化服务调用的性能，减少对服务注册中心的频繁请求，LoadBalancer实现了对服务实例列表的本地缓存。默认设置下，这个缓存的时效为35秒。但是，这一默认缓存过期时间可能会导致在系统上下线过程中出现问题。如果缓存中仍然存储着旧的服务列表，那么这可能会影响到服务的可用性和准确性。

    优雅下线接口，这里采用的是手写的方式，还可以用Spring Boot Actuator提供的接口/shutdown端点的方式，但该接口只支持POST的方式。

    @Autowiredprivate NacosAutoServiceRegistration nacosAutoServiceRegistration;@ReadOperationpublic String deregister() {    Executors.newSingleThreadExecutor().submit(() -> {        log.info("Ready to stop service: {}", serviceName);        nacosAutoServiceRegistration.stop();        log.info("Nacos instance has been de-registered.");    });    return "{\n" +            "    \"status\": \"UP\"\n" +            "}";}

    注意：在优雅下线接口中，我们只需要执行退出nacos注册操作即可，无需手动退出spring应用程序。这是因为配置文件已经启用了服务器端的优雅关闭机制。另外，timeout-per-shutdown-phase参数的时间是影响同步请求的超时中断。

    容器停止前处理：配置调用优雅退出接口并等待30秒

    容器生命周期：

    容器终止流程：

    1、Pod被删除，状态置为Terminating；

    2、将Pod从service的endpoint列表中摘除掉；

    3、如果Pod配置了preStop Hook，将会执行（容器停止前处理）；

    4、发送SIGTERM信号以通知容器进程开始优雅停止；

    5、等待容器进程完全停止。如果在terminationGracePeriodSeconds内 (默认30s) 还未完全停止，就发送SIGKILL信号强制杀***进程；

    6、容器进程终止，清理Pod资源。

    在k8s的容器终止流程中，第五步为容器删除预留了一个最大时间限制，即30秒。如果SpringBoot应用的优雅关闭超时时间和k8s的preStopHooks的总和超过30秒，那么k8s可能会在SpringBoot处理完所有请求之前强制删除容器。

    为了避免这种情况，我们可以调整优雅终止的时间。在k8s中，这个时间由terminationGracePeriodSeconds参数控制，其默认值是30s。我们可以根据实际情况调整这个值，但需要确保terminationGracePeriodSeconds的值要大于sleep时间。请注意，terminationGracePeriodSeconds设置的是最大等待时间，并不意味着每次终止都会等待这么长时间。

    此外，探索JVM退出的钩子函数（Runtime.addShutdownHook）的使用也是一个很好的实践。通过添加关闭钩子函数，可以实现在程序退出时的关闭资源、优雅退出的功能。这也是SpringBoot优雅退出的原理，ApplicationContext.registerShutdownHook方法是spring框架中的一个方法，用于注册一个JVM关闭的钩子（Shutdown Hook），当JVM关闭时，Spring容器可以优雅地关闭并释放资源。

    3、异步线程优雅退出

    在实现服务优雅退出过程中，我们遇到了一个挑战：异步线程的优雅退出。由于BOSS系统的业务复杂性，几乎每个服务都使用了异步线程来处理一些耗时操作。然而，在发版期间，如果容器提前退出，那些尚未完成的异步任务可能会被中断，导致业务数据的不完整，进而需要人工介入进行数据修正。

    异步线程优雅退出的解决办法：

    • 使用统一的自定义线程池；

    • 配置线程池优雅退出和任务最大结束时间。

      @Bean("bossTaskExecutor")public ThreadPoolTaskExecutor bossTaskExecutor() {    log.info("start taskExecutor");    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();    // 配置核心线程数    executor.setCorePoolSize(threadPoolCorePoolSize);    // 设置最大线程数    executor.setMaxPoolSize(threadPoolMaxPoolSize);    // 设置队列容量    executor.setQueueCapacity(threadPoolQueueCapacity);    // 设置线程活跃时间（秒）    executor.setKeepAliveSeconds(threadPoolKeepAliveSeconds);    // 配置线程池中的线程的名称前缀    executor.setThreadNamePrefix("async-service-");    // 设置拒绝策略    // rejection-policy：当pool已经达到max size的时候，如何处理新任务    // CALLER_RUNS：不在新线程中执行任务，而是有调用者所在的线程来执行    executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());    // 等待所有任务结束后再关闭线程池    executor.setWaitForTasksToCompleteOnShutdown(true);    // 等待所有任务结束的最长时间    executor.setAwaitTerminationSeconds(threadAwaitTerminationSeconds);    // 执行初始化    executor.initialize();    log.info("创建一个线程池 threadPoolCorePoolSize is [" + threadPoolCorePoolSize + "] threadPoolMaxPoolSize is [            "] threadPoolKeepAliveSeconds is [" + threadPoolKeepAliveSeconds + "].");    return executor;}

       关键配置：

      等待所有任务结束后再关闭线程池：

      executor.setWaitForTasksToCompleteOnShutdown(true)

      等待所有任务结束的最长时间：

      executor.setAwaitTerminationSeconds(awaitTerminationSeconds)

      需要注意的是：要保证异步线程的任务处理完才退出，容器端的

      terminationGracePeriodSeconds时间要大于等于awaitTerminationSeconds，这样才能够确保异步线程任务的优雅退出。此外，上述的timeout-per-shutdown-phase时间和异步线程的任务最长时间没冲突。

      4、测试结果

      为了测试异步线程在发版中是否被中断，我们可以编写一个测试接口来模拟这种情况：

      @Autowired@Qualifier("bossTaskExecutor")private ThreadPoolTaskExecutor executorService;@ApiOperation(value = "测试异步耗时任务", notes = "测试异步耗时任务")@GetMapping("/testAsyncTask")public Response testAsyncTask() throws InterruptedException {    executorService.execute(new Runnable() {        @SneakyThrows        @Override        public void run() {            for (int i=0;i