Linuxeden开源社区作者
关于业务、架构，我们一直在聊电商平台或社交平台等系统的相关内容，有一类平台我们平时见得比较少，但是却在各个活动中扮演了重要的角色，那就是“用户运营平台”，像我们常见的商城中的转盘抽奖、积分兑换等活动，很多是由这种平台来外接去支撑的。
兑吧正是这样一个平台，它的定位是做用户运营的服务平台，业务包括积分商城管理、活动配置、签到等可以帮助 APP 提升用户粘性和活跃度的运营服务。InfoQ 此次采访了兑吧的技术副总裁武彻，以兑吧为例，请他带我们简单了解这种类型的平台。
武老师告诉我们，这种类型的平台在功能、用户情况和技术实现等方面相比常见的电商、社交等平台有一些特别之处。
与常见的电商、社交等平台相比，兑吧平台在功能上的特点是：多样性与时效性。
多样性是指活动工具的多样性。目前日常运作的活动工具达 60 多款，包括用户非常喜爱的大转盘、砸金蛋、刮刮卡等。这是根据积分业务和用户的行为决定的。
如果仅用一款，或者几款活动工具来运作积分业务，时间长了，用户很容易产生疲劳，所以需要有大量的、创新的活动工具，让用户保持新鲜感。再者，兑吧平台对接了很多用户体量很大的 APP，这些 APP 需要一些个性化定制活动，这些活动工具进一步提升了多样性。
常见的活动工具：
时效性是指兑吧平台在节假日，会给各个 APP 平台制作应景的活动工具。比如中秋节、国庆节、9 月份开学季、暑假等等。这些活动工具有很强的时效性，过了节日就会下线。
从用户行为来看，兑吧提供 SaaS 服务平台，把积分商城通过 H5 的形式，接入到各个 APP 中，用户通过访问 APP 中的“积分商城”入口，跳转到由兑吧提供的积分商城，在商城页面中可以进行“抽奖活动”、“兑换”等活动。
以外卖 APP 为例。用户在 APP 上购买了下午茶，签收、点评后获得了 20 个积分。访问 APP 的“积分商城”，来到兑吧提供的积分商城服务，并拥有 20 个积分。用户看到一个“消耗 10 积分参与 iphone8 抽奖”活动，参与活动后，消耗 10 个积分，剩余 10 个积分。当用户返回 APP 的时候，就剩下 10 个积分了，“积分商城”在维护着用户的积分数据。
业务多样性和时效性，对技术的最大挑战就是如何快速支撑业务，保证用户体验。一开始，兑吧发布一个活动，需要经历这些流程：
- 设计并制作一套活动工具
- 运营在此活动工具的基础上进行活动信息配置和部分展示内容配置
- 发布后，获取活动的数据，进行页面呈现
活动工具的发布，需要经历：设计、前端制作、后端套页面、测试、发布。
同一个类型的活动工具，仅仅修改颜色，或者部分元素修改，技术也需要花 2 个工作日左右。而我们的多样性业务属性又决定了每周有大量的定制化活动工具需要设计、发布。
目前，我们采用模板化技术，内部叫“手脚架工程”，来提升开发效率。如下图所示：
现有的活动工具中，html 部分内容，可以通过页面内配置来获取内容信息，比如：主题图、活动规则。把活动工具，拆成模板和元素。把公共的 js 模板化，背景图、活动图、颜色、活动规则等多变的属性变成元素，而存储元素的这个文件，作为这个活动工具的配置文件。类似于：
每个活动都有一份默认的配置文件，当活动被保存时，根据配置文件的内容生成一份此活动特有的副本。当活动页面被加载时，相关元素读取副本中的内容，进行页面渲染。流程图如下：
这样做的好处是，同样类型的活动工具，只需要通过不同色彩和图片的搭配，可以展现出不同的活动页面，满足各类定制化需求。模板化之前，我们每周只能支持 20 多个需求，模板化后，支撑的需求量已经达到每周 60 多个，解决了业务多样性的问题。
其中的积分业务是大多数人都会遇到的场景，但是大家对它背后的东西又是很陌生的，可能会比较好奇和感兴趣，武老师为我们具体介绍了这块业务的情况。
兑吧的积分业务，主要是帮助开发者（APP），消耗已有的积分，比如把 APP 上通过签到，购买商品等行为产生的积分，在兑吧的积分商城进行兑换、抽奖等活动，消耗积分，形成积分的良性循环。
整体对接图
积分，有非常丰富的业务。下面用积分兑换这一场景来帮助大家理解，开发者 APP 的积分，是怎么在兑吧的积分商城玩转的，这背后又涉及到了哪些系统？一图胜千言，用图的形式来展示积分的兑换业务。
功能流程图
目前，兑吧的平台全部采用 SOA 架构，一次积分兑换，会涉及到好几个业务系统，这些业务系统又是采用分布式部署，来保证 7*24 小时提供服务。详细的技术实现，请看下图：
时序图
具体到兑吧的平台系统，武老师向我们介绍了其早期的架构设计和后来的演进过程。
兑吧的系统功能架构主要分成 3 个阶段。
第一阶段：单体架构。和很多创业公司一样，公司成立初期，我们选择了 java 的 Grails 框架。业务探索期，grails 单体架构发挥了很大的作用。简单、易上手。
第二阶段：SOA 架构。随着业务量的不断增加，单体架构慢慢暴露很多问题。首先，代码工程越来越大，所有的业务代码都在一个工程里面，每次部署，发布都是一件非常漫长、痛苦的事情。
其次，随着团队的壮大，大家都在一个工程里写代码，研发效率低下，在一个工程里，大家的依赖是代码，或者接口级别。A 同学写完了代码，依赖了 B 同学的代码，但是 B 同学还没写完，不能一起提交，需要等待。
在提交的过程中，经常会出现代码冲突，抢开发环境的事情。如何解决这些问题呢？首先要从架构中进行拆分，把原来的单体应用，拆成分布式的多服务应用。这个时候，整个平台的业务访问量已经达到亿级别，业务也处于高速发展期，拆分服务，相当于给高速行使的跑车换轮胎。架构可以拆，但是不能影响业务。让业务在无感知的情况下，完成架构的演进。
我们的解决方案是：技术上，尽量选择成熟的方案，缩短技术探索周期。最终我们选择了 springboot+dubbo 的 SOA 方案。业务上，先保持原来的单体工程不变，继续提供服务。在原来的单体工程中，先拆分出相对独立的商品中心，再慢慢拆分出来活动中心、商城中心、库存中心以及一些非业务属性的基础服务。
历时 1 年左右，到 2017 年的第二季度结束，完成了从原来的单体架构演进到 SOA 架构。研发效率和系统稳定性，都得到了很大的提升。
第三阶段，容器化架构。经过第二阶段的架构改造，目前我们的系统非常稳定，在此基础上，我们也在调研新技术，利用容器化，进一步提升研发效率，降低研发成本。
而在架构演进过程中，从单体架构到 SOA 架构，遇到了很多坑，把其中几个分享给大家，如果大家也处于架构升级和演进的阶段，可以从中吸取经验，减少踩坑。
1、 基础服务。监控和日志是最基础、最重要，也是最容易忽视的服务。我们从单体架构迁移到 SOA 架构的时候，一开始没有监控系统，都不敢动手。不清楚迁移后服务怎么样？是不是稳定？接口的性能如何？响应时间怎么样？
监控系统就像雷达，没有雷达系统，都不敢贸然让战斗机飞出去。所以在系统完善的过程中，一开始，就要搭建一套完备的监控系统和日志系统。我们的监控系统是开源的 CAT 实时分析平台，可以清晰地看到各个系统调用，接口性能等参数。日志系统是 loginsight，基于 ELK 的一整套日志解决方案。这两个系统，在我们迁移架构，日常系统完善过程中，发挥了很大的作用。
2、 系统未动，业务先行。系统的拆分，要基于业务的拆分。一开始，从这么庞大一个单体应用中要拆分出系统来，我们无从下手，拆什么，都是动一发而牵全身。既然无从下手，就开始讨论业务架构，划分业务边界，再来拆分系统。经过充分的讨论，我们发现“商品”这个业务，相对独立，可以第一个拆出来。慢慢的，业务架构的边界就清晰了，系统架构也成型了。
3、 技术要有前瞻性。如果非要等到架构撑不住了，再去优化架构，那真的太晚了。从单体架构，演进到 SOA 架构的时候，我们就有点吃力了。业务快速增长，老系统要维护，新系统要拆分，这是一场与时间赛跑的游戏，对技术团队的挑战非常大。所以从 SOA 架构演进到微服务架构，我们吸取了经验。在业务稳定增长，系统平稳期，就开始进行架构选型。
嘉宾介绍
武彻，目前在兑吧负责基础架构团队，主要负责架构选型，性能优化，系统稳定性等工作。2010 年加入阿里巴巴淘宝网，负责淘宝网的性能测试和性能优化，经历了 10 年~12 年的双 11 性能压测以及性能自动化平台 PTS 的研发工作。2013 年，加入来往团队。历任来往 Android 客户端负责人，来往项目总负责人。2014 年，加入钉钉团队。钉钉初创团队成员，历任钉钉的开放平台项目负责人，smartwork 项目 & 技术负责人，带领项目组从零开始孵化钉钉考勤、签到、日志、审批等办公协同平台。2016 年，离开阿里巴巴，加入兑吧。
转自 http://www.infoq.com/cn/articles/something-about-online-reward-points