重运营的应用。对于App里的顶导航、我的页面、弹窗等,需要根据模式、版本、平台、语言、渠道等不同的维度进行运营管理。随着业务快速发展,版本快速迭代,如何:
通过打造一个稳定、灵活、高效的运营配置平台来解决前面遇到的问题。本文主要分享我们在建设高效的运营配置平台过程中积累的一些经验以及面临的挑战和思考。
运营类配置分类:
运营资源范例:弹窗 | 基础数据:底部导航 |
---|---|
1.1 运营资源
运营资源可理解为App中经常变动的一些广告、运营活动等。比如上图中弹窗广告,就是一个典型的运营资源。
只在一定时间范围内显示在C端固定位置。
每个活动、广告都只会出现在固定的某些模式。
特别是活动类数据,展示的图片文案等变动较为频繁
基于公司海外站面向全球用户的情况,不同模式需展示不同语言文案。
基础数据配置相对于运营资源来说其变更的频率相对较低,与时间、版本的关系也没那么强。譬如下面爱奇艺海外App-底部导航栏(样式如上图)。
需要针对不同的模式、语言做不同的配置。
这种类型的配置一般长期存在,过期场景较少。
面对接二连三运营配置需求,最初实现不同的配置界面来对接各类运营产品需求。但这必然很大问题
新运营配置需求,研发要开发对应配置页面,然后转给运营同学进行配置的管理,最后运营人员对资源进行配置上线,流程图:
每个运营配置需求都经需求评审、页面开发、配置管理、上线。配置页面开发,少则1到2天,问题就在:
通用型的运营配置后台,某些特有功能特别对于前后端来说重复开发工作明显。如操作记录,审核机制,根据不同的模式版本语言过滤数据等功能,在每次出现的配置需求中都需重复开发。
希望设计一个通用解决方案,去解决上文阐述的各种运营资源管理的问题。我们把这个项目称为运营位。
调研确认
不断实践和总结,抓手如下:
随业务迭代,无论采用啥数据字段组成,都很难满足业务变化字段(标题、副标题、图片、跳转链接等)要求。对底层数据进行JSON化,对应数据字段即可实现可动态扩展,满足业务迭代需求。JSON化带来运营位字段管理问题,在运营后台提供字段管理功能即可解决。
持久化存储,分布式缓存,以及接入业务方的本地缓存,运营数据的多方存储,保证极端情况都有降级数据获取,降低系统异常损失。
运营数据,无论通过数据库的落地方案、还是分布式缓存,都无法彻底解决服务中心化和服务抖动。通过接入的SDK化,实现数据的本地缓存更新机制,解除对中心化服务的依赖,提升服务稳定性和性能。同时整个运营位服务变成可水平扩展,在扩展过程中也不会影响中心服务的稳定性。
运营位配置系统整体框架图。从功能角度,大体上分为四层:数据层、服务层、接入层和监控层。
主要存储接入运营位的各类运营数据。
可通过redis集群做中间缓存,通过SDK使各业务方接入本地缓存、通过消息监听异步更新,以解决中心服务的流量压力。
服务层向下对底层数据进行操作;向上为接入层获取数据提供接入能力。提供四个服务能力:
为简化开发接入成本,调用逻辑在SDK内实现,用户只需引入maven包,注入OppkitClient,封装OppkitRequest,通过OppkitClient直接调用即可返回过滤并且翻译后的数据。
设计项目时,后台配置的唯一原则:一切皆可配置。通过开放后台来配置运营位,每个运营位相当于一个业务形态,如导航栏,而运营位包含多个数据,如title,link,title包含多种语言,需配置多语言key:
除了数据存储层监控及烽火台对数据层与服务层的监控,还监控SDK内实现的本地缓存。
C端的接入即数据的获取在SDK内部实现,SDK内部实现功能:
运营后台稳定性与性能保障方案。
各类运营数据配置的运营后台,稳定性很重要。
除了操作机制即运营流程化数据配置机制、多级数据存储使用分布式缓存及分布式数据库,还提供SDK方案来对服务故障进行降级。来看该方案落地过程。
缓解中心服务的流量压力,更多流量请求到本地服务的内存
基于海外站业务特点,国外网络环境不可预测,环境差,尽可能减少网络请求链路
一旦中心服务故障,周知各业务方不要重新部署,以本地缓存实现数据降级
一旦有运营后台数据更新,各业务方无法实时获取最新数据。对此,SDK开始迭代:
系统流程 | 说明 |
---|---|
架构简单,实现方便。但并发差,稳定性不够。 | |
本地缓存,部分缓解中心服务的流量压力。但造成数据不一致。 | |
实现OPPKIT-SDK,在SDK内部实现本地缓存,同时SDK内部通过消息监听机制。 |
架构三版,较好解决中心服务流量问题,使运营后台流量由用户请求量决定改为后台的数据更新频率决定,从而解决流量过载问题。但该版也要解决:
各业务方本地缓存的使用情况种类繁多,如何进行提供系统监控?
针对问题1,SDK内部通过scheduledexecutorservice定时任务,周期性将缓存使用情况拉取到库内,通过后台界面根据时间展示本地缓存使用情况。可掌握各业务方缓存使用情况,给业务方内存申请和分配提供数据支撑。
针对问题2,涉及难点:
业务服务机器一般集群部署,一个消息的更新需要被多台部署相同代码的服务器同时消费,确保每台机器都获取到最新的数据
消息Producer是运营后台服务,而一个消息要被所有业务方监听,即所有业务方的每台机器。所以,每台机器应属不同消费组。所以要找到一个每台机器都不一样的标识节点,以该节点做消费组。显然,最好的就是机器地址,可保证每台机器所在分组不同
运营位有多个,但对于业务方,没必要在未接入的运营位更新数据时去异步请求运营后台中心服务更新数据(因为这些数据这个业务方根本没接入)
提供一个配置文件,各业务方在配置文件内写入各自业务方使用的运营位名称,当一个消息来临,先判断消息中的运营位名称是否包含在配置文件:若不在,则这条消息被忽略(空消费);在,则请求响应的运营位更新本地数据
SDK提供本地缓存可提高后端服务性能。运营位实践配置中发现,运营人员更改运营数据情形相比网络请求来说非常低频,如基础运营数据。因此,数据缓存在客户端可避免客户端与后端服务网络消耗,极大提高性能。
可为每个运营位数据提供一个版本。通过保存各运营位的操作最新时间,在客户端开屏时发起一次请求,将所有运营位最近数据更新时间返给客户端,客户端将该时间戳缓存本地,当下次开屏请求时,同样获取到服务端返回的运营位最近更新时间戳,将本地的与服务的进行匹配,确认是否去更新各运营位数据,如果客户端缓存的运营数据时间与运营后台返回一致,则直接展示缓存在客户端的数据。
这方案另一好处是极端时如对外暴露API4故障,通过禁止运营后台的数据更新,可使业务数据正常展示,避免运营数据消失的严重故障。
本文主要介绍了运营位设计开发,先根据痛点提出运营后台设计原则,针对原则去思考与实现具体技术方案:
如错误码配置举例,错误码需要给客户端返回各类错误码以及对应的相关文案,文案是多语言场景的,通过运营位配置化实现,只需要在分析需求,拆分业务字段和数据露出的条件后,很快就可以给出相应的运营后台。
关注我,紧跟本系列专栏文章,咱们下篇再续!
作者简介:魔都技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。
负责:
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考:
本文由博客一文多发平台 OpenWrite 发布!