我一直在想我要写点什么,最后想想还是写一篇关于系统的技术设计文章。来说说对运营活动的思考。
概述
一个产品业务的发展总是离不开运营二字。随着业务快速的发展以及新业务的扩充,运营需求越来越大,并且很多时候需要追热点,因此在有限的资源下,如何做到快速、准确、灵活、稳定的满足日趋增多的运营需求,成了个问题。我们根据运营的四个基本要数(目标、人群、门槛、激励)通过对活动的抽象、建模、组件化,实现了能满足80%的运营需求的自动化运营系统,运营产品同学只需要通过一份配置文件就可以生成一个新的活动。
他山之石
- QQ会员活动运营平台架构设计实践:cloud.tencent.com/developer/a…
- 转转运营活动高效开发有哪些秘诀:mp.weixin.qq.com/s/VFQKuDwA0…
- 运营做的活动都有哪些?:www.zhihu.com/question/37…
- 读懂APP用户运营的四要素:拉新、留存、促活、营收:www.woshipm.com/operate/647…
引子
通常,我们做一个活动,我们需要做什么?我们需要UI设计、前端排版、接口定义、数据库创建、测试流程等等。这样下来整个流程快一点上一个活动大概一周左右,慢一点可能两周左右。但很多时候,一个活动的生命周期可能就一周、一个月左右。我们是否有必要花如此大的开发代价去做这样事情?一个活动如此,那十个,一百个呢。
我们先来通过三个活动来了解一下活动的本质
![](https://i-blog.csdnimg.cn/blog_migrate/76d90e4b7a2e2ab05c1686e317f8d55e.png)
活动1,为了拉新,针对老用户,每拉来一个人,奖励20元的额度提升。 活动2,为了拉GMV,针对老用户,每还款xx元,奖励多少优惠券。 活动3,为了拉绑卡,针对全部用户,完成绑卡,就有机会抢100张1000元现金券。 … 我们可以发现活动的四个要素:人群、目标、门槛、激励 我们可以用一句话概括运营活动:
针对什么人群,我们想要达到什么目标,设置什么样的门槛(规则),最后给用户什么样的激励措施。
活动生命周期这么短,我们是否可以以比较小的开发代价来完成活动的开发呢? 是否针对某个业务的一个活动开发完?我可以快速的复用到其他业务上呢?
在这些活动的开发中,我们遇到了挑战和难题:
- 可维护性差:活动的生命周期短,活动下线,接口、数据库废弃,但代码遗留,代码维护性差。
- 开发效率低:重复开发、开发效率低、无法复用。每个活动新建接口、新建数据库表
- 可扩展性不高:每个活动只能运用到自己的业务上,无法快速复用到其他业务。
- 性能和监控: 无可靠的数据监控、性能低下。
- 安全低:没有做接口签名、接口限流等等,容易被刷。
运营要做什么?
于是我花了一段时间来系统性的来梳理运营体系相关东西,通过已经做了什么,来思考,我们将来怎么做?
![](https://i-blog.csdnimg.cn/blog_migrate/9fc94b2b376599d0835c00f65df2eebb.png)
- 接入业务:具体的产品,我们才有运营他的基础。
- 运营活动:有了具体的业务,通过运营活动来运营业务。
- 用户触达:活动出来后,我们需要告知用户才行。
- 数据分析:活动效果如何,我们需要分析数据,改进我们的方案。
- 监控告警:系统本身不是100%可靠,我们需要一些仪表盘来监控我们的系统。
- 安全/防刷:运营是有激励措施的,有利益,需要防止恶意侵入。
- 基础能力:通过抽象化、工具化提高开发效率。
- 组件化系统:是否有个可视化的界面,以便于运营人员的快速接入呢。
根据已做的活动经验和遇到的问题,让我不断的思考,我该如何去优化该运营系统,来提高开发效率、安全、和性能。最后,确定的一个大方向:
平台化、标准化、配置化、组件化。
系统架构设计
![](https://i-blog.csdnimg.cn/blog_migrate/741f2b78807c30cd6f244b9b0f52afa2.png)
从上往下看:
- 前端层:做前后分离,动静分离、接入按钮触发统计系统、组件化模块。
- 网关层:接入协议适配、签名校验,接口监控统计、限流等等。保障接口安全。
- 逻辑层:分三个子层。* 第一层:接入统一配置中心,接口标准统一化、插件化、组件化常用模块。消息处理引入观察者,抽象公用模块。* 第二层:根据运营四要素,抽象出规则集(绑卡?还款等等)、奖励集(优惠券、实物?等等)构成活动主逻辑。* 第三层:抽象所有活动储存结构(标签服务)、配置、监控、分布式锁计数器以服务形式提供给上层调用。
- 基础平台:一些依赖的基础能力:比如用户信息、订单信息、平台优惠券系统、基础推送能力等等。
- 存储层:所有活动数据以统一结构存储。
从左往右看:
- 一个活动可以快速复用到其他业务。
- 将活动通过广告系统、消息推送系统等推送出去。通过数据分析系统做数据分析和优化活动流程。
说明几个点:
1.活动路由
- 所有接口统一通过SaleService.handler接入
- 根据活动ID与方法找到对应执行方法。
- 参考MVC的路由方式
- 通过反射+代理模式实现
![](https://i-blog.csdnimg.cn/blog_migrate/9d88e7b9fd3af7a3ec66387e9a9007ee.png)
这样做的一些好处:
- 由于活动的什么周期短,可以通过对配置的更改,调整接口的有无。维护方便。
- 可以很方便的做一些公共校验或埋一些钩子,(比如是否限制登录、是否过期等)
- 可以与配置系统深度整合。
- 做一些接口监控和拦截。
2. mq消息(消息的解耦)
- 观察者模式
- 对修改关闭,对扩展开放
![](https://i-blog.csdnimg.cn/blog_migrate/cb7ea9772a13b9a5d27149caa611e8a1.png)
3.统一配置中心
可以参考之前写的 【180425】统一配置中心:www.jianshu.com/p/edce8e8c1…
这里可以优化的点是,引入版本号,先更新配置+新的版本号到redis,然后再更新每个配置的版本号id, 客户端来取配置的时候,先取配置的版本,在根据版本号+配置key去redis中取配置内容,这样可以平滑的将缓存配置切换到新的缓存配置。
4.关于组件化
一个活动通常可以看成若干个组件组成。
![](https://i-blog.csdnimg.cn/blog_migrate/a37e0a0835a26487f73fdfcefd770d84.jpeg)
每一个组件又有他自己的特性。
前后端如何通过组件交互?
![](https://i-blog.csdnimg.cn/blog_migrate/f6aaa912ce0d9b1d833fd61f9b2bd434.png)
最好能,在OA编辑就完美了
![](https://i-blog.csdnimg.cn/blog_migrate/760578a940b8cde0f8a3a4becbca02d0.png)
最后,通过一些配置,可以快速的上线一些活动,无需开发接入,做到自动化运营。
一些个人观点
- 程序的开发,应该是一个搭积木的过程,一些小的模块组合成一个中等模块,若干中等模块组合成一个系统,若干系统组合成一个业务等等。
- 一个大的问题,可以分层分模块成若干小问题,解决若干小问题,最后解决大问题。
- 了解业务,才能做出更好的系统设计。
- 性能、可用性、可扩展性、可伸缩性、安全。
最后,预祝大家新年快乐。