Spring Boot + Nacos 实现不停服发布

最近，由于业务属性比较重要，对服务发布提出了更高的要求，希望能实现不停服发布。目前，团队所有项目已经完成基于K8s容器化部署，服务注册发现基于Nacos，故本文基于该两前提下进行讨论。

基于该架构下，需要解决如下几个问题：

1. K8s Java 应用实现滚动发布，如果新服务不正常的情况下，不将新服务发布上去，且旧服务不下线
2. 服务从Nacos上主动下线，让流量不再流入

K8s 滚动发布

K8s 已天然支持滚动发布的机制，只需要简单的配置就可以实现我们的要求，如下是具体配置摘要，我将从上到下进行说明。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: example-service
  name: example-service
spec:
  #副本数量
  replicas: {{.pod_replicas}}
  selector:
    matchLabels:
      app: example-service
  minReadySeconds: 30 #设置升级延迟时间15秒,等待15秒后升级
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1   #升级过程中最多可以比原先设置多出的POD数量
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: example-service
        monitortype: backend
    spec:
      #以下内容为可选,容器调度策略，保证同一deployment的多个副本位于不同的机器上，防止单节点挂掉导致服务不可用,由于涉及到要与运维沟通资源情况,无法直接给予固定配置。
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - example-service
              topologyKey: kubernetes.io/hostname
      containers:
        - image: example-service:latest
          imagePullPolicy: IfNotPresent
          name: example-service
          lifecycle:
            preStop:
              exec:
                command:
                  - curl
                  - '-XPOST'
                  - '127.0.0.1:8080/actuator/shutdown'      
          readinessProbe:                # 就绪探针
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 30      # 延迟加载时间
            periodSeconds: 10            # 重试时间间隔
            timeoutSeconds: 1            # 超时时间设置
            successThreshold: 1          # 健康阈值
            failureThreshold: 3          # 不健康阈值
          livenessProbe:                 # 存活探针
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 30      # 延迟加载时间
            periodSeconds: 10            # 重试时间间隔
            timeoutSeconds: 1            # 超时时间设置
            successThreshold: 1          # 健康阈值
            failureThreshold: 3          # 不健康阈值
          ports:
            - containerPort: 8080
              name: backend
              protocol: TCP
          envFrom:
            - configMapRef:
                #存放公共环境变量，比如：数据库，redis，nacos等连接信息，每个项目的各个微服务基本都是一样的。
                name: pub-cm
            - configMapRef:
                #存放个性化配置，对于个别的服务，除了公共变量外，会涉及其他引用信息。
                name: example-service-cm
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name
          resources:
            #设定以下是设定服务资源根据你的项目实际情况来
            limits: # limits是代表的资源上限,服务能消耗的资源上限
              cpu: {{.pod_cpu_limit}} #{limits_cpu}(必须),目前默认单位为m,如果申请一核则为1024m,以此类推,默认则为500m
              memory: {{.pod_memory_limit}} #{limits_mem}(必须),目前默认单位为Mi,如果申请1G内存则为1024Mi,以此类推,默认则为2048Mi
            requests: # requests是服务所需最小的启动资源,设置后如果node达不到这个资源要求就会部署失败
              cpu: {{.pod_cpu_request}} #{requests_cpu}(必须),目前默认单位为m,如果申请一核则为1024m,以此类推,默认则为250m
              memory: {{.pod_memory_request}} #{requests_mem}(必须),目前默认单位为Mi,如果申请1G内存则为1024Mi,以此类推,默认则为500Mi
          # 以下为必须选项,项目做日志采集
          volumeMounts:
            - name: host-time
              readOnly: true
              mountPath: /etc/localtime
            - name: example-service-log
              mountPath: /home/logs # 如果接入日志必须存在容器内/home/logs文件夹下存放日志文件
              subPathExpr: $(POD_NAME)
      volumes:
        - name: example-service-log
          hostPath:
            path: /home/logs
            type: DirectoryOrCreate
        - name: host-time
          hostPath:
            path: /etc/localtime
            type: ''
      imagePullSecrets: # 写死,前提是要执行这个凭证创建命令
        - name: harborha-secret001fe
---
apiVersion: policy/v1beta1
kind: PodDisruptionBudget #设置pod最小可用数量
metadata:
  name: example-service-pdb
spec:
  minAvailable: 50%
  selector:
    matchLabels:
      app: example-service

RollingUpdate 用于配置服务滚动升级的策略，maxSurge设置升级过程中最多可以比原先设置多出的POD数量。

preStop 在容器下线前执行的操作，我这边是希望他先调用 Spring Boot Actuator提供的下线接口，让服务正常业务处理完后，下线掉。

readinessProbe 与 livenessProbe 都是探针，不同的地方是 readinessProbe 在容器启动时，会检查服务是否启动完全和正常，正常后Pod才会被显示正常，这种在使用Service或者Ingress的时候非常有用，livenessProbe 则是周期性检查服务的健康性，如果服务不健康将下线掉服务。

需要注意 readinessProbe 的 initialDelaySeconds 是在服务启动时开始计时，基于服务本身启动时间设置一个相对合理的时间，以提高成功率。

PodDisruptionBudget 该控制器主要是通过设置应用 Pod 处于正常状态的最低个数或最低百分比，这样可以保证在主动销毁 Pod 的时候，不会销毁太多的 Pod 导致业务异常中断，从而提高业务的可用性。

PodDisruptionBudget与Deployment中 RollingUpdate 配置说明

在滚动更新的时候，会根据RollngUpdate 配置来，在Eviction（主动驱逐保护，e.g.存在不健康的节点，下线服务）会根据PDB策略来。

Nacos主动下线

我们想象一种场景，A服务通过Nacos服务注册发现LoadBalance方式直接调用B服务，即使B服务容器已经被销毁，但如果A服务中还存在旧B服务的地址，那么就会调用异常，所以我们希望B服务下线的时候，A服务是有感知的，故我们选择在主动通知Nacos服务下线服务，同时，由Nacos去通知其他服务下线通知。

新建一个Endpoint，该方式是基于Spring Boot 2.7.X 版本的，其他版本可能有所区别。

@WebEndpoint(id = "deregister")
@Slf4j
@ConditionalOnClass(value = WebEndpoint.class)
public class NacosServiceDeregisterEndpoint {
    private final NacosDiscoveryProperties nacosDiscoveryProperties;

    private final NacosRegistration nacosRegistration;

    private final NacosServiceRegistry nacosServiceRegistry;

    public NacosServiceDeregisterEndpoint(NacosDiscoveryProperties nacosDiscoveryProperties, NacosRegistration nacosRegistration, NacosServiceRegistry nacosServiceRegistry) {
        this.nacosDiscoveryProperties = nacosDiscoveryProperties;
        this.nacosRegistration = nacosRegistration;
        this.nacosServiceRegistry = nacosServiceRegistry;
    }

    @ReadOperation
    public String deregisterEndPoint() {
        String serviceName = nacosDiscoveryProperties.getService();
        String groupName = nacosDiscoveryProperties.getGroup();
        String clusterName = nacosDiscoveryProperties.getClusterName();
        String ip = nacosDiscoveryProperties.getIp();
        int port = nacosDiscoveryProperties.getPort();

        log.info("Deregister from the Nacos, ServiceName:{}, GroupName:{}, ClusterName:{}, IP:{}, Port:{}", serviceName, groupName, clusterName, ip, port);

        // 设置服务下线
        nacosServiceRegistry.setStatus(nacosRegistration, "DOWN");

        return "success";
    }
}

增加和修改bootstrap.yaml 配置

management:
  endpoint:
    health:
      show-details: always
      probes:
        enabled: true
    metrics:
      enabled: true
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: "health,shutdown,metrics,deregister"
  server:
    port: 8080
  metrics:
    tags:
      application: ${spring.application.name}

后续

其实上方我们还遗漏一个问题——“服务更新时，服务已经成功注册到 Nacos，但容器还没有被检测为健康，此时流量打到新节点上。”这种情况应该怎么解决。其实不用苦恼，Nacos 自身已经能保证在服务启动完全之后，才会注册到 Nacos 服务列表上。