nginxlua脚本_实战 | ​基于“Nginx+Lua”组件的应用系统灰度发布

欢迎广大金融科技工作者积极投稿！

表达你的看法！

投稿邮箱：

——金融电子化

文/熊军军、彭小刚、郑晓勇、军法

近年来，随着公司业务的快速发展和客户要求的不断提升，中国人寿IT系统建设逐渐呈现出两个特点。一是系统版本数量快速增长，由于部分版本质量不高，可能影响系统可用性，研发和运维人员在版本上线后需要投入大量精力保障系统稳定性。二是业务创新质量要求高，系统需要将某一类型的新功能交付给特定用户，在预定的验证周期内尽早获得用户反馈，快速验证产品设计理念，推动产品快速迭代优化。为稳定优化应用系统产品，支撑快速业务创新，研发中心统一制定了基于“Nginx+Lua”组件的技术方案，并对重点系统进行架构改造，使其能够灰度发布。

工作目标

制定统一的灰度发布技术方案，通过技术改造，使20余个重点系统具备灰度发布条件，实现了以下目标。

1. 提升系统可用性。​​根据部署策略，控制新特性的使用范围，避免新特性缺陷影响所有用户，造成系统全局故障。

2、提升应用产品迭代能力。将某些新功能交付给特定用户，在预定的验证周期内尽早获取用户反馈，快速验证产品设计理念，促进产品快速迭代改进。

技术方案

1、灰度发布的含义。灰度发布是将特定产品功能交付给特定用户的系统版本发布方式，有利于保证系统稳定性，提高产品迭代效率。应用系统灰度发布的基本原理如图1所示，图中应用系统当前版本1部署在正式环境，应用系统新版本2部署在灰度环境，服务路由控制集群配置了访问两个环境的策略，当用户请求到达服务路由控制集群时，控制节点会根据服务访问策略将用户请求转发到正式或灰度环境。访问灰度环境的用户将体验到系统的新功能。

图1 应用系统灰度发布基本原理图

2、灰度发布的主要实现方式，根据灰度发布的内容，我们将灰度发布分为服务端灰度和客户端灰度，服务端灰度是指应用系统服务端程序的灰度发布；客户端灰度是指应用系统客户端程序、静态资源的灰度发布，比如APP升级包、JS文件、图片等静态资源的发布。

按照灰度发布的技术实现方式，我们进一步将灰度发布实现方式分为：“通用路由组件灰度实现”、“开发框架路由组件灰度实现”、“其他灰度实现方式”和“客户端升级服务灰度组件实现灰度”。具体参见图2。

图2 应用系统灰度发布主要技术方案

（1）“通用路由组件实现灰度”。借助Nginx等通用路由组件，将部分用户请求分发到灰度环境。

本文使用的Nginx是一款轻量级开源软件，可以用来搭建反向代理服务器、Web服务器、邮件代理服务器等，具有并发性能好、资源利用率低等优点，其架构特点是“事件驱动、异步”，即通过事件驱动的方式动态申请或释放资源，提高CPU、内存等资源的利用率，通过高效的复用IO技术，显著提高程序在大量并发连接下的CPU利用率，使多个线程可以并发执行，不被阻塞。

为了扩展Nginx的能力，通常会引入Lua脚本语言。Lua是一种轻量级的脚本语言，旨在通过灵活地嵌入到应用程序中，为应用程序提供灵活的扩展和定制能力。功能强大，代码简洁，易于集成，运行速度快，易于扩展。一个完整的Lua解释器不超过200KB，具有实时编译的能力。通过安装Lua-nginx-，，可以在11个Nginx处理阶段使用Lua指令。两个基于Nginx+Lua的开源软件，可以用来快速搭建灰度环境。

（2）“开发框架路由组件实现灰度发布”。 Dubbo、Cloud 等开发框架都提供了支持灰度发布的路由组件。

Dubbo 的灰度路由机制：服务注册服务器将服务提供者信息推送给服务消费者，服务消费者在调用服务时，首先按照一定的路由规则从本地服务器列表中选择一组合适的服务提供者，然后根据自定义的负载均衡策略选择一个服务提供者。这个自定义策略可以通过实现接口或者继承类来重写，实现复杂的灰度控制逻辑。

灰度路由机制：用户请求统一通过API网关Zuul访问内部服务，网关接收到请求后从注册中心获取可用服务列表，然后通过API中的路由策略选择正式或者灰度服务，将请求发送到后端服务。自定义路由策略需要集成ule或者其子类。

（3）“其他方式实现灰度”。在通过专用路由组件实现灰度之前，一些比较传统的方法也可以实现灰度效果。例如：在程序中通过硬代码分支来控制调用的服务；通过将程序部署到不同省份，分批上线，可以实现灰度发布。

（4）“客户端升级服务组件实现灰度”。客户端APP升级包、JS文件、图片等静态资源的发布一般通过专门的升级服务实现。升级服务器访问灰度发布配置库，获取灰度发布配置库。用户登录APP时，首先访问升级服务器，判断是否为灰度用户，若是，则从内容分发服务器下载升级包或静态资源，实现客户端的灰度发布。

项目实践

在重点系统改造过程中，我们先进行技术选型论证，随后组织技术验证，进而分批推进项目实施，取得了一定成效。

1、技术选型。为了满足不同技术框架的应用系统的灰度发布需求，我们采用“使用通用路由组件实现灰度”的方案。

在具体实现上，路由组件采用基于“Nginx+lua”组件的工具，同时引入组件来保证高可用性，具体原理如图3所示。

图3 基于

使用虚拟路由冗余协议，将N台功能相同的路由器组成一个路由器组。这个组里有一台或多台路由器，有一个VIP对外提供服务。它会发送组播VRRP包告知自己工作正常。当收不到VRRP包时，就认为不可用，此时需要根据VRRP优先级选举出一个继任者。这样保证了路由器的高可用性和业务的连续性。最快接管速度可以小于1秒。

2、技术验证。为确保上述方案的可行性，项目组采用“+”方案进行验证测试，主要评估集群的并发性能、高可用性以及对后端服务的影响。

（1）并发性能。挡板测试显示，对于单笔交易而言，当并发用户数从50增加到1500时，集群处理能力保持在9800笔/秒以上，CPU使用率保持在17.17%左右，内存使用率为上一次交易的1.28倍，使用率保持在23.48%左右，并发性能良好，系统资源利用率较低。

（2）高可用性。200个用户并发执行两个事务（比例为100:100）。场景稳定运行几分钟后，手动关闭一个服务器节点，观察是否所有用户请求都能快速分发到剩余运行的节点上。通过查看日志，手动关闭一个节点后，用户请求快速切换到另一个节点，场景继续稳定运行。

（3）转发对后端服务的影响。选取了4个典型事务，50个用户并发连接后端服务，通过对比两组数据可以看出，转发对吞吐量的影响比较明显，而对响应时间的影响相对较小。加入Open Resty转发之后，后端服务性能下降在2%以内。

3、系统改造。根据以上规划，我们对20余个重点系统进行了架构改造，增加了灰度路由层和灰度管控对象，主要选择用户请求中的“IP、角色、组织机构、系统来源”。

在灰度发布实施过程中，需要注意以下问题。