0 背景

重运营的应用。对于App里的顶导航、我的页面、弹窗等，需要根据模式、版本、平台、语言、渠道等不同的维度进行运营管理。随着业务快速发展，版本快速迭代，如何：

• 保持运营资源能够被高效、稳定和灵活地配置
• 高效稳定的为新的运营需求提供支持

通过打造一个稳定、灵活、高效的运营配置平台来解决前面遇到的问题。本文主要分享我们在建设高效的运营配置平台过程中积累的一些经验以及面临的挑战和思考。

1 配置资源拆解

运营类配置分类：

• 运营资源
• 基础数据

运营资源范例：弹窗	基础数据：底部导航

1.1 运营资源

运营资源可理解为App中经常变动的一些广告、运营活动等。比如上图中弹窗广告，就是一个典型的运营资源。

1.1.1 特征

① 时效性强

只在一定时间范围内显示在C端固定位置。

② 模式强相关

每个活动、广告都只会出现在固定的某些模式。

③ 数据变动频繁

特别是活动类数据，展示的图片文案等变动较为频繁

④ 支持多语言展示

基于公司海外站面向全球用户的情况，不同模式需展示不同语言文案。

1.2 基础数据配置

基础数据配置相对于运营资源来说其变更的频率相对较低，与时间、版本的关系也没那么强。譬如下面爱奇艺海外App-底部导航栏（样式如上图）。

1.2.1 特征

① 多维度

需要针对不同的模式、语言做不同的配置。

② 长期有效

这种类型的配置一般长期存在，过期场景较少。

2 实践痛点

面对接二连三运营配置需求，最初实现不同的配置界面来对接各类运营产品需求。但这必然很大问题

2.1 运营效率低

新运营配置需求，研发要开发对应配置页面，然后转给运营同学进行配置的管理，最后运营人员对资源进行配置上线，流程图：

每个运营配置需求都经需求评审、页面开发、配置管理、上线。配置页面开发，少则1到2天，问题就在：

• 研发成本高，每个需求要开发新的配置管理页面
• 研发周期长，运营效率低，从需求的提出到运营上线周期长
• 灵活性差，对不同的运营维度（模式、版本、时间等）都需要事先确定好，无法动态调整

2.2 频繁重复开发

通用型的运营配置后台，某些特有功能特别对于前后端来说重复开发工作明显。如操作记录，审核机制，根据不同的模式版本语言过滤数据等功能，在每次出现的配置需求中都需重复开发。

3 实践中的思考

希望设计一个通用解决方案，去解决上文阐述的各种运营资源管理的问题。我们把这个项目称为运营位。

调研确认

3.0 项目设计原则

• 一切数据皆可配
• 运营数据高可用
• 接口性能高效

不断实践和总结，抓手如下：

3.1 数据JSON化

随业务迭代，无论采用啥数据字段组成，都很难满足业务变化字段（标题、副标题、图片、跳转链接等）要求。对底层数据进行JSON化，对应数据字段即可实现可动态扩展，满足业务迭代需求。JSON化带来运营位字段管理问题，在运营后台提供字段管理功能即可解决。

3.2 运营数据多点存储

持久化存储，分布式缓存，以及接入业务方的本地缓存，运营数据的多方存储，保证极端情况都有降级数据获取，降低系统异常损失。

3.3 接口SDK化

运营数据，无论通过数据库的落地方案、还是分布式缓存，都无法彻底解决服务中心化和服务抖动。通过接入的SDK化，实现数据的本地缓存更新机制，解除对中心化服务的依赖，提升服务稳定性和性能。同时整个运营位服务变成可水平扩展，在扩展过程中也不会影响中心服务的稳定性。

调用方请求流程图

4 运营位架构

运营位配置系统整体框架图。从功能角度，大体上分为四层：数据层、服务层、接入层和监控层。

4.0 运营位架构图

4.1 数据层

主要存储接入运营位的各类运营数据。

难点

• 数据量大
• QPS高

可通过redis集群做中间缓存，通过SDK使各业务方接入本地缓存、通过消息监听异步更新，以解决中心服务的流量压力。

4.2 服务层

服务层向下对底层数据进行操作；向上为接入层获取数据提供接入能力。提供四个服务能力：

• 运营后台，面向运营人员和产品，提供数据的配置后台
• 开放平台，收归开发技术人员，提供一个增加运营位配置的后台
• 数据服务，主要是为调用数据的开发提供一个统一的、高可用的、高性能的api接口
• SDK，服务于数据服务，主要简化开发人员的接入成本，提供数据服务性能和可用性

4.3 接入层

4.3.1 C端接入咋方便？

为简化开发接入成本，调用逻辑在SDK内实现，用户只需引入maven包，注入OppkitClient，封装OppkitRequest，通过OppkitClient直接调用即可返回过滤并且翻译后的数据。

4.3.2 B端配置咋更便捷？

设计项目时，后台配置的唯一原则：一切皆可配置。通过开放后台来配置运营位，每个运营位相当于一个业务形态，如导航栏，而运营位包含多个数据，如title，link，title包含多种语言，需配置多语言key：

• 开放平台就是创建运营位，为运营位配置字段
• 运营后台，配置开放平台创建的运营位数据

4.4 监控层

除了数据存储层监控及烽火台对数据层与服务层的监控，还监控SDK内实现的本地缓存。

C端的接入即数据的获取在SDK内部实现，SDK内部实现功能：

• 若请求包含某些特定离散字段如设备id，因数据量极大，存入本地缓存会给业务方机器内存压力，则避开缓存直接请求服务
• 为满足数据实时性要求较高业务方，新增不接入本地缓存的逻辑
• 若只包含某些聚合度高字段如平台、版本、模式和语言等，则把请求的数据存入本地缓存。本地缓存通过监听运营平台的方式进行异步更新，当异步更新获取数据失败，则保持之前的数据返回，避免极端情况运营数据全部为空，将业务损失降至最低
• SDK内部通过异步线程，将本地缓存使用情况通过定时线程存入，通过后台界面展示各缓存使用情况，实时监控各类缓存使用

5 稳定性与性能

运营后台稳定性与性能保障方案。

5.0 整体请求流程图

5.1 稳定性保障

各类运营数据配置的运营后台，稳定性很重要。

除了操作机制即运营流程化数据配置机制、多级数据存储使用分布式缓存及分布式数据库，还提供SDK方案来对服务故障进行降级。来看该方案落地过程。

5.2 SDK本地缓存方案

实现本地缓存好处

• 缓解中心服务的流量压力，更多流量请求到本地服务的内存

• 基于海外站业务特点，国外网络环境不可预测，环境差，尽可能减少网络请求链路

• 一旦中心服务故障，周知各业务方不要重新部署，以本地缓存实现数据降级

本地缓存方案缺点明显

一旦有运营后台数据更新，各业务方无法实时获取最新数据。对此，SDK开始迭代：

系统流程	说明
	架构简单，实现方便。但并发差，稳定性不够。
	本地缓存，部分缓解中心服务的流量压力。但造成数据不一致。
	实现OPPKIT-SDK，在SDK内部实现本地缓存，同时SDK内部通过消息监听机制。

架构三版，较好解决中心服务流量问题，使运营后台流量由用户请求量决定改为后台的数据更新频率决定，从而解决流量过载问题。但该版也要解决：

各业务方本地缓存的使用情况种类繁多，如何进行提供系统监控？

MQ方案设计

针对问题1，SDK内部通过scheduledexecutorservice定时任务，周期性将缓存使用情况拉取到库内，通过后台界面根据时间展示本地缓存使用情况。可掌握各业务方缓存使用情况，给业务方内存申请和分配提供数据支撑。

针对问题2，涉及难点：

• 业务服务机器一般集群部署，一个消息的更新需要被多台部署相同代码的服务器同时消费，确保每台机器都获取到最新的数据

  消息Producer是运营后台服务，而一个消息要被所有业务方监听，即所有业务方的每台机器。所以，每台机器应属不同消费组。所以要找到一个每台机器都不一样的标识节点，以该节点做消费组。显然，最好的就是机器地址，可保证每台机器所在分组不同

• 运营位有多个，但对于业务方，没必要在未接入的运营位更新数据时去异步请求运营后台中心服务更新数据（因为这些数据这个业务方根本没接入）

  提供一个配置文件，各业务方在配置文件内写入各自业务方使用的运营位名称，当一个消息来临，先判断消息中的运营位名称是否包含在配置文件：若不在，则这条消息被忽略（空消费）；在，则请求响应的运营位更新本地数据

5.3 性能保障

SDK提供本地缓存可提高后端服务性能。运营位实践配置中发现，运营人员更改运营数据情形相比网络请求来说非常低频，如基础运营数据。因此，数据缓存在客户端可避免客户端与后端服务网络消耗，极大提高性能。

可为每个运营位数据提供一个版本。通过保存各运营位的操作最新时间，在客户端开屏时发起一次请求，将所有运营位最近数据更新时间返给客户端，客户端将该时间戳缓存本地，当下次开屏请求时，同样获取到服务端返回的运营位最近更新时间戳，将本地的与服务的进行匹配，确认是否去更新各运营位数据，如果客户端缓存的运营数据时间与运营后台返回一致，则直接展示缓存在客户端的数据。

这方案另一好处是极端时如对外暴露API4故障，通过禁止运营后台的数据更新，可使业务数据正常展示，避免运营数据消失的严重故障。

5.4 请求流程图

6 总结

本文主要介绍了运营位设计开发，先根据痛点提出运营后台设计原则，针对原则去思考与实现具体技术方案：

• 配置数据Json化实现业务字段可扩展性
• 设计的数据模型来介绍满足多语言下各类运营配置数据方法
• 提供SDK内部实现本地缓存，MQ监听，异步更新解决服务中心化的大流量问题和缓存导致数据不一致问题。针对海外具体情况，提出客户端缓存的相关方案

如错误码配置举例，错误码需要给客户端返回各类错误码以及对应的相关文案，文案是多语言场景的，通过运营位配置化实现，只需要在分析需求，拆分业务字段和数据露出的条件后，很快就可以给出相应的运营后台。

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：

• 中央/分销预订系统性能优化

• 活动&优惠券等营销中台建设

• 交易平台及数据中台等架构和开发设计

  目前主攻降低软件复杂性设计、构建高可用系统方向。

参考：

• 编程严选网

  本文由博客一文多发平台 OpenWrite 发布！