应用不停机发布的思考与初识 - 运维

应用不停机发布是一项综合性能力，当明确好一种发布模式后，就需要逐步识别会涉及到哪些技术组件，以及明确技术组件在整个解决方案中所担任的职责边界，从而使它们能够相互协同工作。

如下列举了一些主要的技术组件：

• 应用管理平台

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

• 负载均衡（4层）

主要负责服务请求的流量接入，可根据所识别的流量特征，负载分发到不同的负载均衡（7层）。

• 负载均衡（7层）

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

• 容器/虚拟机平台

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

• 域名解析系统

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

• 注册中心

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

在明确技术组件后，还需要对技术组件进行合理的架构规划，以适配不同的网络架构要求。

本次主要将对负载均衡进行特别说明，一方面它是负责处理流量的核心技术组件，另一方面网络架构的不同，对它的部署架构影响可能也是最大的。

在传统的网络架构环境中，出于对网络安全或其他考虑因素，通常会划分出多个不同的网络区域，网络区域间的访问需要通过开设防火墙访问策略才可以进行互通。

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

所以，一般都会考虑使用负载均衡（代理模式）来解决这个问题。

建议前期优先选择方案三，虽然链路较长会小幅影响性能，但此部署方案相对较为成熟，一方面可以避免流量负载不均的问题，另一方面对于应用的改造成本也会相对较低。

注：除网络区域隔离会遇到这种情况外，在某些网络架构中，不同的容器集群间也同样无法访问，所以也同样适用。

另外，除必要情况下，也应尽量减少跨网络区域或跨容器集群间的访问，例如：优先容器集群内路由访问，跨网络区域频繁交互的应用服务建议迁移至同一网络区域等。

负载均衡通常可以分为4层模式和7层模式，其中4层更关注流量负载，而7层更关注流量路由。

一般建议将负载均衡（4层）和负载均衡（7层）进行分层部署，以充分发挥它们的强项。

建议前期优先选择方案二，虽然无法实现多容器集群间的全局流量调度，但对于当前可观测性和排障能力还不够健全的组织，通过物理隔离降低运维难度也是一种不错的选择。

综上架构决策，最终的全局流量链路大致如下，默认情况下，数据中心间流量隔离，即：单数据中心流量收敛，但可根据实际情况进行选择性放行。