从无到有，我司CRM的演变史

来到现在这公司已经近5年，能拿得出手项目仅有CRM和消息网关。本篇文章主要讲CRM的演变史。

一、孽缘。

        15年12月21日来到公司，团队新组建，算我仅4人，最长到仅半年而已，当时公司购买了sugarcrm系统，创建模块确实很方便，但开发起来很困难，举个例子，当时的实施方做统计报表功能耗费了一个月的时间，丢过来的功能还无法使用。这让我们一时之间也无从下手，大家熟悉的框架也各不相同，有人熟悉tp、ci,有人laravel、yii，最大的问题是sugarcrm自动生成很多无用的表或者字段，让这帮以性能最优为天职的人无法忍受。

二、萌芽

         大概到了2016年1月的中下旬，产品经理(也是新人)要给sugarcrm加很复杂的功能，要求系统能筛选用户、创建活动、审批活动、消息发送。短短的16字需求包涵了很多的细节，比如说筛选用户。因为有很多的条件，需要把用户有关的属性打标签，累计和进行计算等。创建活动需要能任意组合短信、站内信、礼品卡发送，支持定时发送功能。发送需要支持多种消息同时发送，如果用户选择了礼品，必须先发送礼品，再发送短信，发送的结果必须要落盘，用以分析。这么多的功能，以目前对sugarcrm掌控程度,根本无法实现，大家商量决定写一套系统嵌入到sugarcrm，完成业务需求。从1月底到2月中旬(中间过年,找财务另了88元红包)主要就是两个任务，了解需求，对接需要的业务方和选择开发使用的框架。最终采纳龙龙(微博老司机、和鸟哥一起吃饭的人)提出的yaf作为开发框架。用户数据从大数据(新团队)获取。短信、站内信发送使用架构组接口，礼品发送使用用户组接口，其他功能自己开发。可笑的是，当时都尚未评定开发周期，运营直接一封邮件给了大boss,信中说到，4.1号上线。

三、破土

      知道运营报备上线时已经2.25号，测试团队评估近3周，留给开发提测的时间是3.11号。这里要介绍下组内人员了，Andy(组长，出身搜狐）帅帅（出身头条）龙龙(出身微博)。Andy负责服务器的安装及业务协调，龙龙负责yaf方面的环境搭建，我和帅帅负责业务梳理及表结构设计。这里也的提一个坑，其他组的人大部分是从某东过来的。用的是innodb引擎，用户主键是36位的串，这其实为以后的业务还是留了点坑，此处不细表。 

      需要的环境搭建完毕后，大家过了下整理的业务诉求，明白需求后，帅帅领了筛选、龙龙领了活动创建和审批活动、我领了消息发送。

      主要讲下筛选这块的实现方案吧。大数据团队新组建，所有的数据都灌到es中，让活动这块直接从es中取数据。初衷是好的。可以减少两方的交互，解耦。在测试环境数据量少，测试时功能可以实现，但并未覆盖海量数据的场景。不管怎样，从开始开发到正式上线这段期间内，我们几个人每天都是9点到单位晚上10点或者晚上12点之后才回去,周六日只歇一上午或者一下午在家洗洗衣服。那年3月我媳妇来北京开会，等到她住的地方已经快1点了。就这样每天喝着单位买的牛奶花生乳、晨光烧饼、大王家的酸辣汤艰难的熬着，这段痛苦的往事每每回忆起都是甜蜜的，记得帅帅在那段时间发了一个截图，上面写着“每天过需求进度，那个程序员都说进度正常，离上线还有3天时间，联系不上程序员了，在线求解决办法”。我们三个人总会调侃这个段子总会说“咱们还有大招，是时候放大招了”，直到现在这大招都未用过。就这样到了3.31号晚上准备上线，当把所有的功能运行了后，产品经理说大家可以回去了。大家并没有想象中的那种轻松，只是吃了几个串，收拾收拾打车回家。

      ps: 3月中旬谭总(出身腾讯)、然然总(出身360)相继加入了团队。

四、修剪

      上线之后，并没人使用，大概在4.15左右运营开始使用，发现了上面说的拉取数据的问题，由于都是通过http方式拉取数据，导致一个用户筛选大概要3-5个小时，有的甚至要一天才能完成一个筛选任务，这不是任何人想要的效果。因此大家决定改进数据拉取方式。谭总的出现解决了sugarcrm的js问题。然然总的出现解决了数据筛选的效率问题。具体方案如下：

      1、继续沿用原来的筛选条件表。把原来的交互做的更为流畅。

      2、与大数据同事沟通，数据改为推文件的方式从hive推到指定的某台服务器上。

      3、对当前的业务梳理，把数据拆分为66张表，同时增加了一张userId和int的类型转换表。

      4、66张表的设计全都做了优化，字段90%都是int类型。减少磁盘空间，提高了查询效率。

      5、对推过来的数据做解析，生成表需要的文件，采用load data infile 入库，这种方式极大提高了入库效率。

      6、把原来一条极为复杂的sql,拆分为几条简单的sql(谭总在前端用js已经处理好切割的标签)，然后通过交、并、补的方式算出符合的人数。

      当这几个步骤完成之后，线上的运行已经飞一般的感觉。

五、施肥

      这种方式持续到了2016年12月份。运营提出来需要支持周期性活动。所谓周期，是把一段时间内的活动按照天的方式，每天动态生成活动、每天动态生成用户组。这个时段解决了消息发送效率不高的问题，从原来边发边入库到先发后入库。极大提高了效率。运营使用量的增加，我们也开始了筛选及结果的分表。2017.1.2日还拉着测试童姨加班测试，2017年1月5日上线用了一整夜，虽然中间有出问题，总算到天亮的时候上线完成。此后CRM已经成为了运营以及整个公司不可或缺的系统了。

六、风吹雨打

      经历了这些后，CRM也接入了push消息等。随着飞琦的加入，组内人员越来越壮大。系统承接的业务越来越多。筛目前已经有500多个纬度的指标了。随之而来的问题是，大数据推送的文件越来越大目前已经到了150G，系统可用的时间越来越晚，终于爆发了运营投诉技术的事。运营要求尽快推送，大数据表示现在业务越来越多，需要更多的机器，运维回复手中无多余机器使用。公司处于濒临倒闭的边缘。无采购打算。有点屋漏偏逢连夜雨的意思。

七、再度起航

      经过多方调节，同意采购5台机器给大数据，此外CRM决定把数据从mysql 迁移到clickhouse。这个方案也是然然总提出来的，不得不佩服然然总。之所以选clickhouse基于以下这几点考虑：

      1、列式存储

      2、多核cpu并行运行

      3、写入速度特别快，特别适合大批量数据写入。

      因此2019年10月。开始调研clickhouse的可行性，梳理这几年来筛选的任务及处理逻辑。到此时，随着业务的重新划分，人员的变动，CRM维护的人就我一个人了。为了对CRM的未来负责，决定采用java实现筛选。因此，从10月份调研，11月、12月程序开发，让大数据向mysql和clickhouse同时推送数据的同时，利用canal收集mysql的binlog同步运营的筛选条件，也开发了筛选对比的小工具。对相同条件的筛选结果比对，找出差异，经过3个月的对比，发现没有异常，4月份完成了线上切换。切到clickhouse后，筛选性能比原来提升了4-7倍。感谢期间付出努力的各位同事。

      至此，CRM的开发和优化已经完毕，虽然目前公司不是很景气，但不会因为这些原因停止演变。希望能有后续演变过程与您分享。