域名注册COM_应用不停机发布的思考与初识 | IDCF

应用发布，简单来说就是将开发好的系统功能部署到生产环境，以便为用户提供正常的服务。

传统的申请发布流程一般采用“三步走”的方式：

那你肯定会问，从应用程序停止到启动这段时间内，系统功能是不是就无法正常使用呢？

对的，应用发布过程中可能会出现各种异常，比如黑屏、访问超时等，而且通常持续时间比较长，所以发布时间基本集中在凌晨。有些比较讲究的人可能会加上一句友情提示“系统正在维护中，请稍后访问！”。

这种情况多发生在传统行业，可能是他们觉得没必要，因为：

但事实真是如此吗？如今，越来越多的传统行业向互联网服务模式转型，其服务的主要特点是：为客户提供“全天候”不间断的“高质量”“在线”服务。

因此高质量的客户服务必然对服务可用性提出更高的要求，而传统的宕机发布不仅会影响客户使用，还会间接给公司造成间接经济损失。

例如：由于客户体验不佳而导致客户流失

就这些？不！作为一名前运营工程师，我经常凌晨发帖，时不时还要进行8小时的“长途旅行”，身体直接被耗干了。再加上第二天还要“补血”，还会被各种骚扰电话轰炸，这简直就是噩梦。

由此可见不停机发布应用的重要性，它可以帮助我们：第一，在应用发布时保证线上服务的持续可用，从而提高服务的可用性；第二，可以在白天或者任何时间发布应用，从而提高运维人员的机动性。

那么，我们需要做什么才能在不停机的情况下发布应用程序呢？让我们直奔主题。

第1部分

应用发布零停机，从字面意思上很容易理解，即应用发布过程中，服务不中断。

但仔细想想，原本在应用发布的过程中，服务是会中断的，所以在应用发布之后，可以通过阻断外部网络流量的方式，对内验证核心或者通用功能，确保没有问题之后，再解封，对外提供服务。

那现在呢？应用是直接对外发布吗？不需要内部或者小流量验证吗？相信每个人的答案都是不一样的。对此，我们可以简单定义三个成熟度等级，来衡量应用无宕机发布的能力。

到期

成熟度能力

成熟度 1 级

应用发布过程中服务不中断

成熟度 2 级

应用发布过程中不中断服务，可先内部/小流量验证单体应用功能

成熟度 3 级

应用发布过程中不中断服务，可先内部/小流量验证多应用（联动）功能

注：不同成熟度等级对技术能力的要求不同，建议通过逐步演进的方式提升成熟度，在演进过程中验证不同的技术能力，持续改进。

有人会说蓝绿发布、滚动发布、灰度发布都可以实现上述能力。但其实这些答案都不准确，也不全面，虽然有交集，但不能面面俱到。

既然提到了发布模式，那么我们先来简单比较一下几种发布模式的优缺点。

蓝绿发布

滚动发布

灰度发布

资源成本

生产中资源投入比例导致成本上升

基本不需要额外资源投入，成本低

基本不需要额外资源投入，成本低

回滚时长

两种环境直接切换，持续时间较短。

由滚动速率决定，持续时间较长

一些灰度实例会在一定时间内回滚

技术难点

资源完全隔离，技术难度较低

需要制定滚动策略，技术难度适中

引入流量路由功能，这在技术上很困难

势力范围

影响所有用户，影响较大

影响所有用户，影响较大

影响用户数少，影响较小

注：大部分技术文章提到，以上任何一种发布模式都可以用来实现应用在用户不知情的情况下发布，但在实际情况中，这还不够，需要结合一些辅助手段才能实现。

综合以上几种发布模式的优缺点，如果你的组织在基础设施技术能力上已经非常成熟，那么灰度发布一定是最好的选择，但如果还处于早期阶段，那么可能就不是最好的选择了。蓝绿发布的资源投入较高，所以也不是一个很好的选择。

剩下的就只有滚动发布，但是滚动发布的发布策略比较复杂，特别是在容器环境下，需要分别实现针对同一个应用的多个服务实例的滚动策略。

因此前期可以选择一个折中的做法，即：搭建单独的预发布验证环境，应用架构需要和生产环境保持一致，但容量可以最小化，一般一个应用至少有2个服务实例。

这样，我们可以在将应用发布到生产环境之前，先将应用发布到生产预验证环境，发布之后只对内部用户可见，验证通过之后，再将完整应用发布到生产环境。

第2部分

实现应用不停产发布是一个综合的能力，确定了发布模式之后，需要逐步识别涉及哪些技术组件，明确整个解决方案中各个技术组件的职责，让它们能够协同工作。

下面列出了一些主要的技术组件：

技术组件

责任边界

应用管理平台

主要负责控制整个应用发布流程，集成和调度不同的技术组件，并协同完成应用无停机发布

负载平衡（第 4 层）

主要负责服务请求的流量接入，并能根据识别出的流量特征，将负载分配到不同的负载均衡器（7层）上

负载平衡（第 7 层）

主要负责服务请求的流量路由，它可以根据识别的流量特征将流量分发到同一应用程序的不同实例上。

容器/虚拟机平台

主要负责容器/虚拟机资源管理，包括容器/虚拟机的创建、更新、销毁

域名解析系统

主要负责域名地址管理，包括域名注册、更新、解析等，以及提供用户访问应用或者应用间访问等寻址能力

注册中心

主要负责服务资源管理，包括服务的注册、更新、注销，以及提供服务请求者发现服务提供者的能力。

在明确了技术组件之后，还需要对技术组件做出合理的架构规划，以适应不同的网络架构要求。

这次我们主要讲解负载均衡，一方面它是负责处理流量的核心技术组件，另一方面网络架构的不同可能对其部署架构影响最大。

在传统的网络架构环境中，出于网络安全或其他考虑，通常会划分多个不同的网络区域，而网络区域之间的访问需要设置防火墙的访问策略才能实现互通。

但这种方式势必会影响应用服务之间直接点对点的访问，主要原因是在虚拟机或者容器环境中，应用的IP地址可能会发生变化，无法提前明确防火墙的访问策略。

因此人们一般考虑采用负载均衡（代理模式）来解决这个问题。

建议前期优先考虑方案三，虽然较长的链路对性能会稍微有影响，但是这种部署方案相对比较成熟，一方面可以避免流量负载不均的问题，另一方面应用改造的成本也会比较低。

注意：除了网络区域隔离外，这种情况也适用于不同的容器集群在某些网络架构下同样无法访问的情况。

另外，若非必要，应尽量减少跨网络区域或跨容器集群的访问，例如优先考虑容器集群内的路由访问，跨网络区域频繁交互的应用服务建议迁移到同一网络区域。

负载均衡一般可以分为4层模式和7层模式，其中4层更注重流量负载，7层更注重流量路由。

一般建议负载均衡（4层）和负载均衡（7层）分层部署，以发挥各自优势。

建议前期优先考虑方案2，虽然无法实现多容器集群之间的全局流量调度，但对于目前可观察性和故障排除能力还不够完善的组织来说，通过物理隔离降低运维难度也是不错的选择。

基于以上架构决策，最终全局流量链路大致如下，默认情况下数据中心之间的流量是隔离的，即单数据中心内的流量是汇聚的，但可以根据实际情况选择性放行。

第 3 部分

实现应用不停机发布的基础是服务路由，这里我们可以把应用服务分为服务请求者和服务提供者两个角色，服务请求者通过不同的寻址方式最终访问到服务提供者，这可以称为服务路由。

服务路由可分为南北向和东西向。

不难发现，主要的区别就在于南北向的服务请求者需要通过负载均衡（代理模式）来访问服务提供者，而东西向的服务请求者则直接访问服务提供者。

注意：域名解析结果会缓存在本地，可以缓解域名解析服务的压力。但缓存时间需根据不同的服务等级进行评估，否则会延长解析地址切换和故障转移时间。如果条件允许，建议使用本地缓存来解决问题。

但不管是南北向还是东西向，服务提供方必须能够被服务请求者感知或看到才能够被访问，常见的方式有两种，一种是独立于注册中心，一种是依赖于注册中心。

如果当前的应用架构没有采用微服务框架，即不依赖注册中心，服务提供方可以手动或者自动将服务注册到负载均衡器上，服务请求者直接调用负载均衡器即可。

如果当前的应用架构已经采用了微服务框架，即依赖一个注册中心，那么服务提供方可以在注册中心上注册服务，服务请求者可以在注册中心上发现服务，或者负载均衡器可以在注册中心上发现服务，服务请求者直接调用负载均衡器。

注：在多注册中心场景下，可以通过统一注册中心完成异构注册中心的服务发现

另外我们还会将同一个应用的不同服务实例进行分组，分组策略可以根据不同的条件来确定，比如不同的环境，不同的版本等等。

假设按照不同环境（试生产环境、生产环境）的情况，将部署在试生产验证环境的应用服务划分为试生产组，将部署在生产环境的应用服务划分为上线组。

然后通过配置路由策略并下发给负载均衡或者应用服务，就可以实现简单的服务路由。

比如不同群组之间默认不允许服务路由，但是在特殊场景下允许将预发布群组服务路由到在线群组。

注：如果服务请求方是前端页面或者客户端，那么前端流量也可以进行分组，比如按照网络环境，将连接公司WI-FI网络环境的流量标识为一个发送组。

第 4 部分

实现应用不停机发布的核心在于如何优雅地停止应用，单靠服务路由可能还不够，虽然解决了大部分问题，但距离成功还有一步之遥。

前面我们提到过，应用的发布应该是在用户不知情的情况下进行的，那么，如果在应用发布过程中，出现了短暂的中断，而用户恰好正在使用，这是否意味着用户已经察觉到了呢？

但如果你认为在线服务中断5分钟是可以容忍的，那我只能笑笑了，但我相信绝大多数互联网服务模式的领先公司都无法容忍5分钟的服务中断，更别说5秒了。

我们先来分析一下为什么会出现瞬间或者短暂的中断：

对于以上两种情况，我们还需要按照南北方向和东西方向分别进行讨论。

在南北方向上，服务请求者和服务提供者通过负载均衡进行路由，因此在发布应用时，需要在负载均衡上进行一些特殊的处理。

1）在负载均衡上，对应用服务实例逐个进行阻断，这种阻断只会影响新的请求，服务请求处理完成后，再进行如下操作：

注意：商业负载均衡一般都支持优雅下线/上线

2）由于服务请求者的所有请求都会先经过负载均衡，而负载均衡的成员节点只需要保证至少有一个服务实例存在，这种场景不需要通知，因此不适用。

东西方向，服务请求者和服务提供者直接路由服务，因此在应用发布时，需要对服务请求者和服务提供者分别进行一些特殊的处理，这些处理方式受到应用框架的限制，这里我们先介绍一种常用的框架，即：+应用框架

第二点看似简单，其实比较复杂，我做了一些降阶，来权衡收益价值和转型成本。

取得成果

装修费用

方法一：最大中断时间为5秒

对容器/虚拟机平台进行微小修改

方法二：不中断（不通知）

改造容器/虚拟机平台

方法三：不中断（通知）

改造容器/虚拟机平台；改造注册中心/统一注册中心

方法一：最大中断时间为5秒

步骤 1：依赖项启动--组件、暴露/端点

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown

步骤2：调整配置参数，分别增加客户端和服务端的性能压力

配置项

配置说明

默认值

建议值

..-拿来 -

客户端获取服务注册信息的频率

三十

.erval

客户端刷新时间

三十

..疼痛

服务器是否使用只读缓存

真的

错误的

步骤3：在销毁容器的服务实例或者更新虚拟机的服务实例之前，请求以下地址，停止应用服务实例。

curl -X 应用服务地址 //

方法二：不中断（不通知）

step1: 依赖-boot--，暴露/和/-

端点

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown,service-registry

步骤2：调整配置参数，分别增加客户端和服务端的性能压力

配置项

配置说明

默认值

建议值

..-拿来 -

客户端获取服务注册信息的频率

三十

.erval

客户端刷新时间

三十

..疼痛

服务器是否使用只读缓存

真的

错误的

步骤3：在销毁容器的服务实例或者更新虚拟机的服务实例之前，请求以下地址将应用服务实例下线。

curl -X 应用服务地址 //-?=DOWN

注意：此时服务提供方仍然可以提供服务，但再次获取该服务实例的服务请求方将不会再次获取该服务实例

步骤4：服务请求者最多会等待5秒才会更新服务列表。因此，完成上述操作后，可以休眠5秒后再请求以下地址停止应用服务实例。

curl -X 应用服务地址 //

注意：..-fetch--+.erval=5秒

方法三：不中断（通知）

步骤 1：依赖 -boot--，暴露 / 和 /-

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: shutdown,service-registry

步骤2：调整配置参数，这会增加服务器的性能压力

配置项

配置说明

默认值

建议值

..疼痛

服务器是否使用只读缓存

真的

错误的

步骤3：在销毁容器的服务实例或者更新虚拟机的服务实例之前，请求以下地址将应用服务实例下线。

curl -X 应用服务地址 //-?=DOWN

注意：此时服务提供方仍然可以提供服务，但再次获取该服务实例的服务请求方将不会再次获取该服务实例

步骤4：在注册中心上记录当前订阅该服务实例的服务请求者列表，并通知其根据列表立即重新获取最新的服务实例，通知完成后请求以下地址停止应用服务实例

curl -X 应用服务地址 //

以上三种方式可以结合价值收益和改造成本进行权衡，能接受瞬间断电的可以选择方式一，对技术有极致追求的可以选择方式三，如果两种都不行就选择方式二。

注意：各个应用服务的配置参数可能不完全统一，这可能会导致配置管理成本大幅增加。但如果可以统一，方法2还是不错的选择。

第 5 部分

有了上述条件和能力之后，不停机应用发布的基本框架已经形成，但这样就能不停机实现应用发布吗？

其实没那么简单，我们在开发中还是需要遵循一些规范，但是遵循这些规范可能会增加我们的开发成本。

因此，并不是说每次发布应用都要做到零宕机，而是要进行合理的权衡，但好的系统设计必须能够符合开发规范，又不会过多增加开发成本。

下面列出了一些常用的开发规范，可以根据实际情况进行必要的调整，目的是为了尽可能保证向上兼容，无论是接口更新还是数据库更新。

最后的想法

感谢大家耐心看到这里，整篇文章主要围绕应用不停机发布进行讲解，简单讲解了为什么要做，能带来什么价值，怎么做，要注意哪些方面，主要目的是让大家对应用不停机发布的框架有一个大概的了解。

实现应用不停机发布的手段并不局限于文章中提到的这些，涉及到的技术组件也可能不止这些，但解决思路基本一致，具体的技术实现方式可以结合自身的架构环境进行适配和调整。