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