认识达内从这里开始

随着双十一的过不，不知不觉之间双十二就要来临了，今天我们就一起来了解一下电商平台在进行产品推广和用户维护上面都采用了哪些的方法。

首先，我们先来了解一下关于用户运营平台中的积分制度问题。

与常见的电商、社交等平台相比，兑吧平台在功能上的特点是：多样性与时效性。

多样性是指活动工具的多样性。目前日常运作的活动工具达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多个，解决了业务多样性的问题。

第一阶段：单体架构。和很多创业公司一样，公司成立初期，我们选择了java的Grails框架。业务探索期，grails单体架构发挥了很大的作用。简单、易上手。

第二阶段：SOA架构。随着业务量的不断增加，单体架构慢慢暴露很多问题。首先，代码工程越来越大，所有的业务代码都在一个工程里面，每次部署，发布都是一件非常漫长、痛苦的事情。

其次，随着团队的壮大，大家都在一个工程里写代码，研发效率低下，在一个工程里，大家的依赖是代码，或者接口级别。A同学写完了代码，依赖了B同学的代码，但是B同学还没写完，不能一起提交，需要等待。

在提交的过程中，经常会出现代码冲突，抢开发环境的事情。如何解决这些问题呢?首先要从架构中进行拆分，把原来的单体应用，拆成分布式的多服务应用。这个时候，整个平台的业务访问量已经达到亿级别，业务也处于高速发展期，拆分服务，相当于给高速行使的跑车换轮胎。架构可以拆，但是不能影响业务。让业务在无感知的情况下，完成架构的演进。

我们的解决方案是：技术上，尽量选择成熟的方案，缩短技术探索周期。最终我们选择了springboot+dubbo的SOA方案。业务上，先保持原来的单体工程不变，继续提供服务。在原来的单体工程中，先拆分出相对独立的商品中心，再慢慢拆分出来活动中心、商城中心、库存中心以及一些非业务属性的基础服务。

第三阶段，容器化架构。经过第二阶段的架构改造，目前我们的系统非常稳定，在此基础上，我们也在调研新技术，利用容器化，进一步提升研发效率，降低研发成本。

而在架构演进过程中，从单体架构到SOA架构，遇到了很多坑，把其中几个分享给大家，如果大家也处于架构升级和演进的阶段，可以从中吸取经验，减少踩坑。

1、基础服务。监控和日志是最基础、最重要，也是最容易忽视的服务。我们从单体架构迁移到SOA架构的时候，一开始没有监控系统，都不敢动手。不清楚迁移后服务怎么样?是不是稳定?接口的性能如何?响应时间怎么样?

监控系统就像雷达，没有雷达系统，都不敢贸然让战斗机飞出去。所以在系统完善的过程中，一开始，就要搭建一套完备的监控系统和日志系统。我们的监控系统是开源的CAT实时分析平台，可以清晰地看到各个系统调用，接口性能等参数。日志系统是loginsight，基于ELK的一整套日志解决方案。这两个系统，在我们迁移架构，日常系统完善过程中，发挥了很大的作用。

2、系统未动，业务先行。系统的拆分，要基于业务的拆分。一开始，从这么庞大一个单体应用中要拆分出系统来，我们无从下手，拆什么，都是动一发而牵全身。既然无从下手，就开始讨论业务架构，划分业务边界，再来拆分系统。经过充分的讨论，我们发现“商品”这个业务，相对独立，可以第一个拆出来。慢慢的，业务架构的边界就清晰了，系统架构也成型了。

3、技术要有前瞻性。如果非要等到架构撑不住了，再去优化架构，那真的太晚了。从单体架构，演进到SOA架构的时候，我们就有点吃力了。业务快速增长，老系统要维护，新系统要拆分，这是一场与时间赛跑的游戏，对技术团队的挑战非常大。所以从SOA架构演进到微服务架构，我们吸取了经验。在业务稳定增长，系统平稳期，就开始进行架构选型。

受访嘉宾：武彻

作者：雨多田光

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。