如何设计一个高可用的运营系统

转载自如何设计一个高可用的运营系统

这是一篇来自粉丝的投稿，作者【林湾村龙猫】近一年在做关于运营活动方面的设计。本文是他的关于运营活动的总结，Hollis做了一点点修改。

概述

一个产品业务的发展总是离不开运营二字。随着业务快速的发展以及新业务的扩充，运营需求越来越大，并且很多时候需要追热点，因此在有限的资源下，如何做到快速、准确、灵活、稳定的满足日趋增多的运营需求，成了个问题。我们根据运营的四个基本要数（目标、人群、门槛、激励）通过对活动的抽象、建模、组件化，实现了能满足80%的运营需求的自动化运营系统，运营产品同学只需要通过一份配置文件就可以生成一个新的活动。

引子

通常，我们做一个活动，我们需要做什么？

我们需要UI设计、前端排版、接口定义、数据库创建、测试流程等等。这样下来整个流程快一点上一个活动大概一周左右，慢一点可能两周左右。

但很多时候，一个活动的生命周期可能就一周、一个月左右。我们是否有必要花如此大的开发代价去做这样事情？一个活动如此，那十个，一百个呢。

我们先来通过三个活动来了解一下活动的本质。

活动1，为了拉新，针对老用户，每拉来一个人，奖励20元的额度提升。
活动2，为了拉GMV，针对老用户，每还款xx元，奖励多少优惠券。
活动3，为了拉绑卡，针对全部用户，完成绑卡，就有机会抢100张1000元现金券。
...
我们可以发现活动的四个要素：人群、目标、门槛、激励
我们可以用一句话概括运营活动：

针对什么人群，我们想要达到什么目标，设置什么样的门槛（规则），最后给用户什么样的激励措施。

活动生命周期这么短，我们是否可以以比较小的开发代价来完成活动的开发呢？是否针对某个业务的一个活动开发完？我可以快速的复用到其他业务上呢？

在这些活动的开发中，我们遇到了挑战和难题：

可维护性差：活动的生命周期短，活动下线，接口、数据库废弃，但代码遗留，代码维护性差。
开发效率低：重复开发、开发效率低、无法复用。每个活动新建接口、新建数据库表
可扩展性不高：每个活动只能运用到自己的业务上，无法快速复用到其他业务。
性能和监控: 无可靠的数据监控、性能低下。
安全低：没有做接口签名、接口限流等等，容易被刷。

运营要做什么？

于是我花了一段时间来系统性的来梳理运营体系相关东西，通过已经做了什么，来思考，我们将来怎么做？

接入业务：有了具体的产品，我们才有运营他的基础。
运营活动：有了具体的业务，通过运营活动来运营业务。
用户触达：活动出来后，我们需要告知用户才行。
数据分析：活动效果如何，我们需要分析数据，改进我们的方案。
监控告警：系统本身不是100%可靠，我们需要一些仪表盘来监控我们的系统。
安全/防刷：运营是有激励措施的，有利益，需要防止恶意侵入。
基础能力：通过抽象化、工具化提高开发效率。
组件化系统：是否有个可视化的界面，以便于运营人员的快速接入呢。

根据已做的活动经验和遇到的问题，让我不断的思考，我该如何去优化该运营系统，来提高开发效率、安全、和性能。最后，确定的一个大方向：

平台化、标准化、配置化、组件化。

系统架构设计

从上往下看：

前端层：做前后分离，动静分离、接入按钮触发统计系统、组件化模块。
网关层：接入协议适配、签名校验，接口监控统计、限流等等。保障接口安全。
逻辑层：分三个子层。
- 第一层：接入统一配置中心，接口标准统一化、插件化、组件化常用模块。消息处理引入观察者，抽象公用模块。
- 第二层：根据运营四要素，抽象出规则集（绑卡？还款等等）、奖励集(优惠券、实物？等等)构成活动主逻辑。
- 第三层：抽象所有活动储存结构（标签服务）、配置、监控、分布式锁计数器以服务形式提供给上层调用。
基础平台：一些依赖的基础能力：比如用户信息、订单信息、平台优惠券系统、基础推送能力等等。
存储层：所有活动数据以统一结构存储。