发布移动互联网程序灰度发布

移动互联网程序灰度发布

摘要本文对移动互联网程序在电信行业支撑领域的灰度发布方案进行阐述由原传统方式进行一次性发布、不允许试错的升级模式逐渐转为为互联网灰度发布。针对不同忠诚度的用户提供不同的版本通过接受用户的反馈确定迭代发布版本提供用户更好的使用体验

关键词移动互联网灰度发布电信行业微信公众号业务支撑系统

1 .概述

1 .1系统现状

目前湖北联通互联网程序发布方式采用传统的发布方式。在每次发布新功能时需要停止服务才能够发布新的版本。发布成功后再次收集新版本的反馈信息在下一次发布中进行优化。此流程不光用户体验差并且对于用户的反馈响应较慢不适合快速更替的互联网程序发展需求

1 .2建O背景

随着互联网经济进入全面发展期移动终端设备同生活结合越来越紧密因此迫切需要一个互联网系统支撑业务发展。但是互联网程序必须7*24无间断服务。传统支撑系统可以在无业务服务的过程中进行停系统更新。此种方案不能

1

满足互联网程序的服务要求并且互联网程序的更新频率较高基于此种要求就迫切需要一种能够全新的发布方式。能够提供用户更好的体验无缝衔接

2.建设目标和总体说明

2.1建设目标

将湖北联通对外服务的互联网程序实行灰度发布能做到7*24小时不中断无缝升级。全面提升用户使用感知。并且通过灰度发布可以尝试新的功能点并且及时获取用户使用的反馈信息

2.1 .1提高产品发布的效率

在传统发布的方式中每发布一个版本要经过大量的审核流程。一个版本时在上一个版本发布成功后再进行下个版本的设计研发发布。通过灰度发布可以迭代开发。快速更替版本

2.2总体说明

2.2.1传统软件发布

传统软件开发流程通过需求分析后交由研发人员进行开发。此阶段开发完成后由测试人员进行内部测试.当测试通过后交由合并主版本好。进行Beta版发布由测试组、相关人员按照需求要求进行前面测试。如果测试无误则在正式环境发布Release版本。发布过程中需要停止服务。造成用户感知下降。如果用户发布过程中存在测试阶段未能发现

2

的问题并且不能在短期进行问题修复。则需要进行版本回退

传统发布模式优点a由于传统发布模式是属于全量发布所以在代码维护上只会存在一个版本避免多个版本代码维护n 由于后端只是适用一套数据源在数据的避免数据转模型转换c系统架构简单维护工作量较少

传统发布模式缺点a发布模式决定只能全量发布所有的测试都在发布前完成但是由于内部测试人员较少的问题故会存在测试不全面导致的BUGb发布版本由于前期设计的问题在用户体验或者流程上的不足只能在下一个版本中修正。造成版本发布周期延长c用户对新老版本的兼容性使用习惯有段适应的时间有用户流失的风险

2.2.2互联网程序发布

由于电信营业软件都是为运营提供服务要求在工作时段提供无缝服务并且使用者都是内部员工故在非工作时段可以通过停止服务的方式进行全量升级。避免带来分段升级的造成的系统不同步问题

但是由于电信行业部分软件开始对互联网提供服务为

3

用户自助服务针对此类业务系统需要支持7*24小时无间断服务不允许长时间停业务进行升级维护并且互联网程序更新较为频繁也造成了现有发布方案不便

为了解决以下三点问题需要优化发布流程

1 能够不中断服务或者减少中断服务的时间和频率的情况下发布版本

2能够在全面发布新版本的前进行全方位的测试针对不同的维度对用户提供相应的功能

3对用户进行分维度区分按照忠诚度年龄段等维度区分向不同维度的用户提供不同的功能收集用户的反馈获取真实用户的体验及建议。可以导向后续的功能。并且防止新旧版本兼容性的风险防止用户使用习惯改变而造成的用户流失风险

3.灰度发布的方案

在实际生产运营的过程中根据用户的维度进行定向发布根据系统发布关注点的不同设定不同的灰度发布策略

我们可以根据用户号码用户归属地域入网时间终端特性或者按照其他的策略来区分用户对用户进行分块。提供不同的软件版本

灰度发布管理员按照策略生成不同的用户域功能覆盖点进行个性化发布。并且提供数据反馈入口。根据反馈结果进行产品完善制定新一轮的灰度发布到最后的完整发布

4

3.1灰度发布规则制定

1 筛选用户a规则生成按照用户的地域归属入网时间终端特性内部用户种子用户活跃用户等维度划分用户可以按照不同的用户特性分发给不同的测试环境。比如对于内部用户种子用户这类流失率滴的用户提供比较激进的功能收集反馈信息。评估用户的接纳度b手动导入灰度管理人员可以导入指定用户的维度将其路由至指定的测试发布环境中

2通过以上两类用户群生成规则可以灵活动态的制定发布策略。动态的分流。以此达到迭代开发灰度发布的快速更新的方式

3当灰度发布管理员通过管理系统制定了分发规则。按照规则将生成具体的分发的用户明细。待测试环境部署完毕后将此分发用户的明细同步到负载均衡的路由cache中。完成灰度发布规则的制定以及执行

3.2湖北联通微信公众号灰度发布概述

针对湖北联通微信公众号灰度发布的模式介绍

湖北联通对外服务的APP微信公众号WAP页面等公众系统通过前置中转代理将用户请求转发到后端服务器在转发的过程中通过灰度管理员制定的分发规则将用户分发到不同的服务器。应用服务器根据配置查找后台对应的数据

5

源。部分需要用到内部系统的接口信息则通过DMZ区的中转服务器进行消息转发。 调用核心网络数据服务。

3.2.1公网服务系统

此模块主要是对公众模块湖北联通对公众服务的信息都从此窗口提供能力。WAP程序手机APP程序以及微信公众号等互联网程序。此类应用通过后端接口同业务数据进行交互。以此完成对公众的服务请求

3.2.2负载权衡路由分发

原始负载均衡主要是为了平衡各个应用服务器的压力将访问的用户通过预先制定的规则进行分流

为了满足灰度l布在原始负载均衡上必须新建一套规则。需要将用户群再次进行区分。在原来负载均衡的策略上增加一层灰度发布的分流规则

通过灰度发布管理制定的规则将用户群按照规则路由到测试服务集群和正式环境服务集群中。此路由规则表需要导人到cache中并且支持动态加载避免由于全量加载导致服务的中断

灰度发布的路由集群可以有多套并不局限于一套测试环境一套正式环境的配置。根据发布软件的需要可以设置多套发布环境

3.2.3灰度发布服务器集群

服务集群根据业务要求分为测试服务集群正式环境服

6

务集群。但是测试服务集群并不局限只有一个可以根据业务的要求。生成相应的多套环境

不同的服务集群可以针对不同分组的用户并且这些集群可以很方便地横向扩展。在灰度发布的过程中可以在测试环境中动态增加访问的用户数。以便达到更全面的测试

通过多用户的多群体的用户测试。收集测试用户的反馈信息进行及时的更新。加快版本的迭代更替。使用户可以更新认可度较高的版本

3.2.4灰度发布数据层

在传统网络发布过程中对于数据库数据存储层面的变更一直是持相当谨慎的态度因为数据库的变更。一般都伴随着业务的停止服务。这个情况是发布版本会尽量避免的或者通过在前期数据库设计中预留一部分字段以备后续的不时之需

在部分的灰度发布方案中也不能够覆盖到数据库的修改的情况。在此方案中我们可以通过用户的数据的实时转换的方式来达到灰度发布的目的。在发布测试环境后在数据库层面建立需要转换的用户数据。建立两套数据样本对于测试用户采用测试样本对于正式用户还是采用正式样本。当测试用户通过发布规则进入到测试环境中系统检测到当前用户的数据存储才用的正式版本中的存储结构。测试提醒用户需要进行数据转换此时通过调用后台的单用户数据转换

7

脚本将用户有变化的数据转移到新的存储表中。这样就实现了数据的无缝对接。在后续发布正式版本时也可以通过批量转换的方式实现数据的转换

3.2.5后端消息转发

前端用户通过发起业务请求转发到后端核心系统请求。由于后端服务接口变更升级较少并且前端业务请求对后台请求的高度依赖性。后端业务转发无需做灰度发布的设置

4.总结及展望

4.1全文总结

本文对移动互联网灰度发布详细的介绍分析如何快速迭代更新发布程序并且做到7*24小时不中断服务给用户更完善的体验

4.2展望

本文介绍的移动互联网程序的灰度发布源于通信行业向互联网企业转型发展的迫切需要结合湖北联通市场的互联网发展而设计和实现。系统的使用会提高联通用户感知大大促进业务办理的便捷性并且通过灰度发布能够尝试激进的功能允许大胆创新试错。在灰度测试用户基数的基础下能够对预上线的功能进行全面的测试避免传统发布模式中对于测试不全面而导致的BUG以及功能业务流程设计不合理的方面对用户的反馈及时响应。在移动互联网业务模式不断创新的未来如何进一步优化和改善系统

8

适度超前的完善系统框架和主要功能以快速响应市场变化和需求个人认为还有很多需要深入探索的方面。

9