互金平台灰度发布的三段式探索与实践【转载】

http://dbaplus.cn/news-72-1441-1.html

作者介绍

小亚，互联网金融公司应用运维主管，参与运维工作九年，涉及领域包含航空、金融、广告等。近两年主要负责金融业务运维的线上业务发布、维护等工作。

分享目录：

应用逻辑架构
发布实践1.0及问题
发布实践1.1—平滑发布
发布实践1.2—灰度发布及验证
发布实践—后续探讨

本文将从某互联网金融平台的线上版本发布工作出发，介绍了整个发布过程的优化及改造，以及对于灰度发布的探索及最终实践。

先要说明一点，任何脱离实际业务的技术工作都是耍流氓，技术需要服务于业务。因此，本文尽量淡化了业务方面的因素，聚焦于技术层面，建议在实际运用中还是要根据各自的业务场景去变化和调整。

其次，本文重点描述了线上发布的实施改造思路及演进过程，但对于其它相关联的一些点，比如发布规范流程、配置管理、监控、自动化工具的实施等不做过多涉及，如有兴趣可后续交流。

应用逻辑架构

图1 应用逻辑架构图

客户端

包含手机APP、Web页面（主站/营销站等）、H5页面等，即访问发起方，来自于真实用户。

WEB

主要实现转发功能，利用Nginx实现，同时包含一些业务策略和跳转设置。

BFE

Business Front End，业务前端，实现接入和业务聚合功能，有点类似于API网关，但和业务有一定耦合，用Tomcat war包发布。

APP

业务应用层，实现具体业务功能，目前几十个APP模块，用Tomcat war包发布。

Data

数据层，如数据库、缓存、分布式文件系统等。

公共组件

包含配置中心，任务调度中心，服务注册发现中心，消息队列等（这4个公共组件和灰度发布有一定关系，后续会单独介绍）。

注意：

WEB->BFE：通过Nginx反向代理转发流量，HTTP请求；
BFE->APP和各APP间调用：通过在服务注册中心内注册，进行RPC调用，由BFE统一返回。

公共组件介绍

公共组件各家公司差异较大，有自研、纯开源或二次开发，我厂综合各方面因素后，选型如下：

配置中心

Disconf，百度的开源产品，用起来一般，更新较慢，基本满足配置管理需求。各APP启动时会从Disconf中获取配置信息，也支持热更新。

任务调度

Light task scheduler，简称LTS，用于Job类的统一管理调度，相当于统一管理的Crontab，业内相似的有当当网开源的Elastic-Job，不过LTS相对来说比较轻量级。各APP启动时会在lts中注册为任务节点，执行计划任务。

服务注册发现

Dubbo，阿里开源产品，有一定年数了，经受过考验。如果重度依赖Spring的，可以考虑Spring Cloud系列。各APP启动时会在Dubbo中进行注册Provider和Consumer 的Service接口，用于相互调用。

消息队列

RocketMQ，也是阿里的产品，性能不如Kafka，但用在金融行业应该没问题。各APP启动时会连接到RocketMQ中，进行后续消息的消费。

发布实践1.0及问题

介绍完基本背景后，我们来聊聊核心问题：线上发布。

这里的线上发布指上文中的BFE和Service服务，都是基于Java开发，部署方式是war包，容器是Tomcat。

原始发布方式如下：

图2 BFE发布流程

图3 APP发布流程

大家可以发现，BFE只是多了一部分切换Nginx的操作，因此后续重点对APP的发布进行说明。

上述APP的发布方式实施不久后，就遇到了几个问题，而且对业务造成了一定影响，总结有如下几条：

APP发布时，直接重启Tomcat，导致节点正在处理的请求会受到影响，严重时会有数据异常。
APP发布时如果节点正在作为task_tracker运行lts任务，会导致任务失败并retry。
APP发布时如果节点正在消费RocketMQ中的消息，会导致消息消费异常，甚至进入retry或dlq队列。
APP发布完成后没有即时验证机制，直接暴露给用户，如有异常影响面很广。
线上无法同时存在新老版本的APP来用于长时间的验证。

竟然有这么多问题，泪崩~~

仔细分析上述问题，可以归结为两类：

平滑发布问题：即以上问题前三点。发布时要尽可能平滑，对用户及业务影响最小（补充一句，当然也可以通过幂等及自动或人工补偿机制去完善，这是另一个维度）。
发布验证问题：即以上问题最后两点。发布完成要能小范围的即时验证，最好是能定位到个体，且如有需要，验证时间可以延长。

接下来就结合实践，介绍下如何解决这两个问题。BTW，在过渡期间内，大家只能熬夜停服发布或者在晚上低峰期发布，苦不堪言。

发布实践1.1—平滑发布

平滑发布，即发布时尽量减少对业务的影响，能够柔和地对服务进行下线。为做到这一点，必须要结合现有公共组件的特点，在代码部署前先对服务进行平稳下线，确认下线完毕后再进行发布工作。

Dubbo

由于所有APP的接口都有在Dubbo中进行注册，因此需要有办法能够对其Provider Service接口进行下线或屏蔽，使其不提供服务，即其它服务无法调用它的接口。

Service接口下线后，此APP机器自然无任何流量流入，因此也无流量返回，达到下线APP机器的目的，然后即可部署代码。

官方有提供Dubbo-Admin工具，用于对Dubbo中各APP及其Service接口进行管理，里面自然也包含有实现下线的功能，可以有3种方法：

屏蔽，貌似一直没有效果；
禁用，可以成功禁用；
权重调节，可以设置0-100的权重，设置为0时即不提供服务。

经过选型，我们选用更灵活的权重调节方案，通过Dubbo-Admin对需要下线机器的APP应用接口权限设置为0。

图4 Dubbo权重调节

2 RocketMQ

同理，如果要被重启的APP机器正在消费消息队列中的消息，也需要等消费完成后才能进行发布，因此需要查询该APP机器所对应的Consumer Group及绑定的Queue，然后下线，即解除绑定。在RocketMQ的web-console中我们增加了对应接口，进行下线。

图5 RocketMQ控制台

3 LTS

对于任务调度这一块，我们也必须要让APP机器不再接受任何新任务，以免重启发布时任务执行失败。

我们的做法是在ZooKeeper里对需要停止跑Job任务的APP机器，增加一个Znode，比如”机器ID=offline”，当JobTracker去调度TaskTracker执行任务时，一旦检测到包含有此Tag的机器，就不会再给这些APP机器分配任务，以此达到任务解耦。

4 检查机制

为了平滑发布的顺利进行，检查确认机制不可或缺，即确保Dubbo/Rocketmq/Lts中的下线都已生效，并且无流量发生，我们从以下两个维度去检查：

接口检查，调用Dubbo、RocketMQ、LTS的API接口，检查APP机器状态，是否为已经下线。当然，在做了下线功能的同时，我们也有检查功能和上线功能，可供调用。
监控检查，调用CAT、ELK的API接口，检查APP机器的请求访问数和日志流量是否都已经为0，已经处于下线状态。

经过上述改造后，我们新的发布流程如下，基本解决了平滑发布问题，发布时对业务的影响降到了最低；

图6 发布流程图解

发布实践1.2—灰度发布及验证

这一章主要解决发布验证的问题，即如何验证以确保线上发布的准确性，有问题时确保影响面最小。

1 停服后如何小范围验证

这里先来个小插曲，不知道各位有没有碰到过类似情况，大版本发布时通常会挂停服公告，把请求切断在Web层，然后运维小伙伴会进行APP发布，此时通常会把所有APP都进行代码部署，因为是大版本，十分凶残。

图7 停服页面

下面问题来了，等发布完成后，产品经理通常会说，能不能先不要开服，对外还是保持停服页面，但让我们几个人能够验证下功能，以肯定确定以及确认这次发布没有遗漏或漏测的坑。

如果你是运维的小伙伴，会怎么搞，大家可以脑洞下~~

先分享下我们的做法，我们会在办公网络单独申请一个HDFB的wifi（灰度发布），然后当你连上这个wifi出公网解析时，所有和我们业务相关的域名会解析到另一个入口，这个入口对应一个灰度发布的WEB层，配置和线上一模一样，限制只能办公网络访问，所有人员在办公室通过这个入口即可访问和验证新版本，但公网用户不可达。