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

  • 时间:
  • 浏览:0
  • 来源:大发彩神下载—大发彩神APP

一是只适用于停服发布,机会某次只发布2个APP模块,无法单独验证。

哪几种的问题详述:举个例子,比如APP1和APP2,APP1和APP2其他人 内控 的接口,也能新老版本兼容.APP1和APP2之间相互调用的接口,也也能相互兼容。

介绍完基本背景后,大伙儿儿来聊聊核心哪几种的问题:线上发布。

APP发布完成后真难即时验证机制,直接暴露给用户,如有异常影响面很广。

哪几种的问题详述:灰度发布过程中,都要逐步切走每段线上机器,用于验证;机会线上请求量较大,都要慎重,选则在低峰段进行。

当都要发布及进行验证时,平滑下线所有APP的一每段机器,不让对都要部署代码的APP进行发布,启动时修改所有下线APP机器的所属GROUP=GREEN。

关于灰度发布的后续优化及改善,目前有考虑到2个方面,总结如下,后续会逐步改进:

再次,机会都要长时间来验证灰度环境,线上会一起去位于有有有一个多甚至以上的版本,不有利于运维维护,且监控方面都要加强。

图3 APP发布流程

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

多搭建几套公共环境,用于不同分组,但变快被否定,维护成本太多。

经过上述改造后,大伙儿儿新的发布流程如下,基本避免了平滑发布哪几种的问题,发布时对业务的影响降到了最低;

最后,都要利用灰度发布的办法,在线上进行流量回放及全链路压测,也是有有有一个多后续摸索搞笑的话题。

官方有提供Dubbo-Admin工具,用于对Dubbo中各APP及其Service接口进行管理,后边自然也包含晒 实现下线的功能,都要有3种办法:

在一套公共环境中,支持多个分组,在APP中引入对应的framework jar包,支持灰度分组参数GROUP。

图1 应用逻辑架构图

接下来就结合实践,介绍下怎样才能避免这有有有一个多哪几种的问题。BTW,在过渡期间内,大伙儿儿必须熬夜停服发布机会在晚上低峰期发布,苦不堪言。

APP发布时,直接重启Tomcat,导致 节点正在避免的请求会受到影响,严重全是有数据异常。

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

通过你你你是什么办法,大伙儿儿即完成在不都要停服的情况报告下,对线上APP进行灰度发布及验证,对应的各基础组件截图如下:

确认无误后,重复上述步骤,增加GROUP=GREEN机器比例,当超过一深冬,GROUP=GREEN直接提供线上服务,即把线上WEB层直接指向BFE(GROUP=GREEN)的分组。

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

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

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

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

通过以前的平滑发布和小范围验证的摸索,现在现在开始 英语 进行灰度发布实践之路。

发布实践1.1—平滑发布

为了平滑发布的顺利进行,检查确认机制不可或缺,即确保Dubbo/Rocketmq/Lts中的下线都已生效,不让无流量位于,大伙儿儿从以下有有有一个多维度去检查:

下面哪几种的问题来了,等发布完成后,产品经理通常会说,都要先难能可贵开服,对外还是保持停服页面,但让大伙儿儿几其他人 也能验证下功能,以肯定选则以及确认这次发布真难遗漏或漏测的坑。

应对思路:你你你是什么原则上要求一般的守护任务管理器全是满足,比如离米 要求跨有有有一个多版本的兼容,多个版本间就不都要了。但实际操作全是略困难,牵涉到开发流程规范哪几种的问题,都要开发测试同学一起去配合,能做到单模块级别的测试,且各模块间要相互保持兼容和一致。

APP层中各APP的新老Service接口无法兼容的,必须使用灰度发布

APP发布时机会节点正在作为task_tracker运行lts任务,会导致 任务失败并retry。

 图10 Disconf

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

仔细分析上述哪几种的问题,都要归结为两类:

经过选型,大伙儿儿选则更灵活的权重调节方案,通过Dubbo-Admin对都要下线机器的APP应用接口权限设置为0。

针对公共组件的优化,又有以下五种生活做法:

先分享下大伙儿儿的做法,大伙儿儿会在办公网络单独申请有有有一个多HDFB的wifi(灰度发布),不让当你连上你你你是什么wifi出公网解析时,所有和大伙儿儿业务相关的域名会解析到曾经 入口,你你你是什么入口对应有有有一个多灰度发布的WEB层,配置和线上一模一样,限制必须办公网络访问,其他人 员在办公室通过你你你是什么入口即可访问和验证新版本,但公网用户不可达。

你你你是什么章主要避免发布验证的哪几种的问题,即怎样才能验证以确保线上发布的准确性,有哪几种的问题时确保影响面最小。

接口检查,调用Dubbo、RocketMQ、LTS的API接口,检查APP机器情况报告,否是是为机会下线。当然,在做了下线功能的一起去,大伙儿儿全是检查功能和上线功能,可供调用。

发布实践--后续探讨

发布完成后,线上APP统一运行在GROUP=GREEN的环境。

图2 BFE发布流程

线上无法一起去位于新老版本的APP来用于长时间的验证。

BFE,接入汇聚层,都要通过Nginx反向代理进行分组,即可区分流量,进行分组;

机会你是运维的小伙伴,会为啥搞,大伙儿儿都要脑洞下~~

APP,机会会在多个公共组件中进行注册,不让都要在公共组件中对接入的APP及其Service接口进行分组,具有相互隔离的能力,即可区分验证;

应对思路:你你你是什么真难有点儿好的办法,必须从研发层面去规范,比如APP访问数据时,尽量别再次出现select * from table的操作,不让下发都要及早考虑这点。

注册中心Dubbo:通过在Service的名称前加带GROUP以分组

哪几种的问题详述:灰度发布最终的数据落地还是一份,不让机会数据库的表内控 变更机会分布式缓存数据内控 位于差异及不兼容的情况报告,就必须使用灰度发布。

不让,按照你你你是什么思路,机会都要进行灰度发布及长时间验证时,会是下面的架构图:

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

配置中心

平滑发布哪几种的问题前文中已有描述,至于发布验证哪几种的问题,前文介绍了在停服情况报告下通过HDFB WEB层进行验证,但有有有有一个多哪几种的问题:

图11 Dubbo

主要实现转发功能,利用Nginx实现,一起去含晒 其他业务策略和跳转设置。

数据层的变化导致 新老版本无法兼容的,必须使用灰度发布。

 2  RocketMQ

正常情况报告下,各APP机器启动时,引入framework.jar包,并指定其他人 所属GROUP,假设初始时为BLUE。

BFE  

任务调度

真难说明其他,任何脱离实际业务的技术工作全是耍流氓,技术都要服务于业务。不让,本文尽量淡化了业务方面的因素,聚焦于技术层面,建议在实际运用中还是要根据其他人 的业务场景去变化和调整。

图9

图13 lts

上述APP的发布办法实施不久后,就遇到了2个哪几种的问题,不让对业务造成了一定影响,总结有如下2个:

 4  检查机制

配置中心Disconf:通过版曾经 对应GROUP的功能

发布验证哪几种的问题:即以上哪几种的问题最后两点。发布完成也能小范围的即时验证,最好是能定位到个体,且如有都要,验证时间都要延长。

这里的线上发布指上文中的BFE和Service服务,全是基于Java开发,部署办法是war包,容器是Tomcat。

服务注册发现

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

APP  

竟然有真难多哪几种的问题,泪崩~~

对于任务调度你你你是什么块,大伙儿儿也都要要让APP机器不再接受任何新任务,以免重启发布时任务执行失败。

监控检查,调用CAT、ELK的API接口,检查APP机器的请求访问数和日志流量否是是都机会为0,机会位于下线情况报告。

图12 RocketMQ

权重调节,都要设置0-60 的权重,设置为0时即不提供服务。

1

WEB  

图8

注意:

禁用,都要成功禁用;

WEB->BFE:通过Nginx反向代理转发流量,HTTP请求;

公共组件  

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

公共组件介绍

 1  停服后怎样才能小范围验证

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

屏蔽,貌似经常真难效果;

消息队列

首先,当然是有有有一个多波特率哪几种的问题,目前觉得机会实现自动化,但发布过程中还是都要一定的人为介入,不让验证周期较长,后续要考虑怎样才能更流畅的使用。

随即把GROUP=BLUE机器再完整篇 进行代码发布。

消息队列RocketMQ:通过在Topic的后边加带GROUP以分组

灰度发布,我相信大伙儿儿对你你你是什么词全是其他人 的理解和体会,它全是什么都例如的概念或变体。比如分组发布,蓝绿发布,金丝雀发布,甚至于A/B测试。这里不让纠结于某个具体的名词或概念(都要烦请自行百度),还是致力于避免实际中碰到的有有有一个多哪几种的问题:平滑发布和发布验证。

 图5 RocketMQ控制台

为了避免后边的哪几种的问题,思考过程如下:

含晒 手机APP、Web页面(主站/营销站等)、H5页面等,即访问发起方,来自于真实用户。

下面,大伙儿儿谈一谈灰度发布的前提条件、应对思路以及后续的优化改善。细心的同学一定发现了,前面讲的灰度发布流程,应该是有一定先决条件的,体现在以下2个方面:

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

BFE->APP和各APP间调用:通过在服务注册中心内注册,进行RPC调用,由BFE统一返回。

其次,是全是每个发布全是走灰度进行,还是平滑发布后就能直接对外提供服务,比如有有有一个多Hotfix的修改,要难能可贵灰度?你你你是什么都要有一定的标准。

此处以GROUP=BLUE及GROUP=GREEN为例来进行说明(当然也都要分成更多的组),描述APP机器灰度发布流程(BFE例如,什么都增加一步切换Nginx操作,不单独描述)。

Data  

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

同理,机会要被重启的APP机器正在消费消息队列中的消息,也都要等消费完成后也能进行发布,不让都要查询该APP机器所对应的Consumer Group及绑定的Queue,不让下线,即解除绑定。在RocketMQ的web-console中大伙儿儿增加了对应接口,进行下线。

图7 停服页面

应对思路:你你你是什么目前的避免办法是通过增加机器来避免,大伙儿儿目前采取双机房四区域,4倍的流量冗余,每次按照25%的流量依次进行灰度发布。

机会所有APP的接口全是在Dubbo中进行注册,不让都要有办法也能对其Provider Service接口进行下线或屏蔽,使其不提供服务,即其它服务无法调用它的接口。

二是验证时间有限(停服窗口一般不让太多),机会都要长时间验证,无法满足。

应用逻辑架构

客户端  

任务调度中心lTS:通过给每个task id加入灰度分组信息,以区分不同的TaskTracker执行节点,新的task只在新代码的机器上运行。

APP发布时机会节点正在消费RocketMQ中的消息,会导致 消息消费异常,甚至进入retry或dlq队列。

大伙儿儿的做法是在ZooKeeper里对都要停止跑Job任务的APP机器,增加有有有一个多Znode,比如”机器ID=offline”,当JobTracker去调度TaskTracker执行任务时,一旦检测到包含晒 此Tag的机器,就不让再给哪几种APP机器分配任务,以此达到任务解耦。

这里先来个小插曲,我什么都知道各位有真难碰到过例如情况报告,大版本发布时通常会挂停服公告,把请求切断在Web层,不让运维小伙伴会进行APP发布,此时通常会把所有APP都进行代码部署,机会是大版本,十分凶残。

 3  LTS

日常流量对灰度发布的影响有2个。

发布完成后,都要通过单独的HDFB WEB入口,进行验证,此时线上仍可正常提供服务。

 2  灰度发布实践

图6 发布流程图解

平滑发布哪几种的问题:即以上哪几种的问题前三点。发布都要尽机会平滑,对用户及业务影响最小(补充一句,当然也都要通过幂等及自动或人工补偿机制去完善,这是曾经 维度)。

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

原始发布办法如下:

发布实践1.0及哪几种的问题

大伙儿儿都要发现,BFE什么都多了一每段切换Nginx的操作,不让后续重点对APP的发布进行说明。

 图4 Dubbo权重调节