运满满运营平台的架构升级之路

运满满在货运领域已成为国内最大城际整车物流与车货匹配信息平台运营企业之一，平台上承载了超过 500 万司机和 100 万货主用户。

由于业务变化很快不断有新的业务支撑需求, 经常出现当需求提出时，由于新、老业务有一些逻辑区别，为了实现快速上线，每次都新起一套功能, 长期下来给系统的维护带来很大的挑战。 同时业务同事还不停抱怨需求兑现慢。 那么运满满的运营平台是怎么解决这些问题的呢? 进行了怎样的技术变革和组织变革呢？为此，我们采访了运满满运营平台和技术学院负责人刘洋岐，听他如何解读运满满运营平台的技术架构升级之路。

运满满的运营平台的主要功能在于通过数字化、智能化的方式支撑起日常运营，提升运营效率，同时兼顾部分创新项目。目前，整个运营平台包含营销、 CRM、 客服支撑、内网系统和探索业务等几个模块。其中：

• 营销模块涵盖了目前常见的一些活动，如优惠劵、 积分和广告， 同时还有会员计费系统，它支持了运满满的线上运营和会员费业务的开展；
  

• 探索业务模块是一些新业务形态的摸索，包含对新车 / 二手车，商城，满满卡和话费等业务的支撑；

• CRM 模块包含前线地推和中台电销的系统，支撑了平台、交易和购车等业务线；

• 客服支撑模块则包含客户服务和客户投诉系统，不仅有传统的电话客服还有在线客服的功能；

• 内网系统提供了公司内部系统的基础功能，如内部网关，SSO 和权限，还有综合工单服务来实现内部审批流程。

在这几大模块功能基础上，运营平台还抽象出了底层的服务给运满满内部使用，如电子合同、电子发票、流程引擎、MDM(主数据管理、提供内部基础数据、如组织架构信息) 等内容。

此前，运营平台所面临最大的挑战就是业务变化过快所带来的业务支撑要求。由于新、老业务有一些区别，当需求提出时，为了实现快速上线，很容易每次都新起一套功能，这就是所谓的“烟囱式”系统建设。 其带来的第一个痛点就是重复功能建设和维护带来的成本浪费；第二个痛点就是没有能力沉淀，导致新业务支撑速度还是不够快。

例如，活动系统中每次的活动逻辑和页面都很类似，但运营同学每提一个活动方案都需要两三天的时间来开发活动页面，期间要和前端反复沟通样式和效果。 有时还需要花更多时间改代码来支持新玩法，响应速度慢，不利于针对突发热门事件做营销推广。

另一个是 CRM 系统， CRM 之前功能按业务线是独立的。新车 CRM 需求提出的时候，必须完整实现报单和客户流转的所有逻辑，哪怕类似的功能在车货匹配平台和交易业务线是现成的。因此，CRM 就是典型的烟囱式系统建设。 首先，之前的功能按业务线是独立的，类似功能每条业务线都要重新开发，功能无法内聚，存在重复建设； 其次，由于历史原因，针对前线地推和中台电销的系统是两套， 客户在前线地推和中台电销人员之间流转很复杂，容易出问题。

针对以上问题，解决方案就是平台化和中台化。 平台化就是把业务需求的变化点抽象出来，通过配置化的方式，实现对不同的业务需求的支撑。 其中常见的一种配置方式是使用流程引擎配置工作流。 在新的活动系统中，通过平台化实现玩法的配置化和页面的自助生成。一般来讲，中台化的本质是将公共的、通用的业务以服务的方式沉淀到为基础服务，并实现服务的重用。 在 CRM 系统中就通过中台化实现了在车货匹配平台，交易和新车几个业务间基础服务的重用。

首先，拆分 CRM 系统为业务服务与基础服务两层。将其中稳定的、具有通用能力的共享功能放到基础服务中；将偏向具体业务的功能建设到业务服务层，以适应快速业务试错的需要。客户信息是各个业务线都需要的，抽象出了客户服务。 销售的公私海，客户的流转也是通用的功能，抽象出了客情服务。 客情服务中通过规则引擎和流程引擎，能实现客户流转和报单流程的灵活定制。

其次，抽象出了独立的报表服务，实现了报表的配置化。 大数据将数据推送到对应的数据表后，只需要做一些配置，就可以完成报表的展现，大幅提升了对业务报表需求的响应速度。

现在重构完成后，通过底层基础服务的重用，可以保证两周内接入一个新的业务，能支撑集团新业务的快速开展。

在新的系统上线后，活动玩法就可以抽象成：用户行为（发货、支付等）+ 行为条件（对用户行为的约束规则）+ 奖励方式（抽奖、送礼）的模式。彻底跟具体的玩法解耦，扩展性高，新增玩法只需要配置新的用户行为即可，开发维护成本大大降低。

所有的玩法采用统一的配置流程，选择不同的用户行为，配置不同的行为条件和奖励方式即可配置不同的活动。 这样让运营配置更加方便。

用户在活动中的每个状态，都被抽象为一个节点。 在调度模块中按预设的流程调度。每个节点内部使用流程引擎来灵活组合不同的模块，来实现不同的活动玩法。

主要有以下几个大的节点类型：

• 通用主流程节点：一般是活动的主体流程，例如发货后抽奖，主要涉及活动校验模块，用户校验模块，计数器模块和抽奖模块；

• 分支流程节点：主要用于催动用户跟进活动流程，主要涉及计数器模块、触达模块和抽奖模块；

• 分享流程节点：用户分享后奖励，或者邀请拉新，主要涉及计数器模块、邀请模块和抽奖模块；

在此期间，运满满还上线了码良平台来提升整体效率。码良平台是一个在线 H5 编辑器，用于快速制作 H5 页面。用户无需掌握复杂的编程技术，通过简单拖拽、少量配置即可制作精美的页面，可用于营销场景下的页面制作。同时，也为开发者提供了完备的编程接入能力，通过脚本和组件的形式获得强大的组件行为和交互控制能力。码良上线后 95% 的营销页面可以由运营人员自己在码良平台创建。 InfoQ 上已经有相关文章详细描述了码良的设计思路 (如何设计高扩展的在线网页制作平台)。

（https://www.infoq.cn/article/A4610ba*mtsd2Jr5leHV）

通过活动系统的平台化建设，现在可以在 2 个小时左右完成从页面创建，页面评审到活动配置的全流程，并支持在活动未开启的情况下，进行活动全流程测试，提升了响应速度，降低了活动配置出错的概率。

随着满帮集团的体量扩大，稳定性和安全性就越来越受重视。 车货匹配业务的一大特征是流量高峰在早上 7~9 点，而大家通常是每天晚上发布。 这样很多性能问题会在早上直接爆发。 所以在流程上，需要规定了核心链路上的服务，比如发货、搜货、交易和会员的服务发布之后，必须进行生产环境的全链路压测， 通过这种方式来提前发现性能问题。

其次，在提交代码过程中加上了代码 Peer Review 的环节，保证了代码逻辑有人复查。 持续集成中加入了 Sonar 的静态扫描和依赖包的版本管控，代码不符合规范或者使用了企业不允许的依赖包版本会无法打包。 同时，核心流程还实现了自动化测试的覆盖，平均成功率 97.53%。

最后，也加强了组件化的建设，将一些逻辑封装成组件。一方面是减少了重复造轮子，提升代码复用率 ; 另一方面规范了基础中间件的使用，统一封装了常见解决方案，减少了出错的可能性。

在组件的选择方面，比较成熟的组件有 YCache。 YCache 是一套缓存应用解决方案，能够对缓存使用更加合理，更加方便，更加简单。它有如下几个特点：

• 易使用：接入的应用只需要配置相应注解，即可使用，简洁方便。 并强制要求加上过期时间，规范了对缓存的使用方式。

• 防穿透：当对应 key 的数据为 null 时，会在缓存中插入特殊字符来表示值为空，防止访问压力落到数据源。

• 防雪崩：首先，通过异步刷新缓存的机制，避免大量缓存集中在某一个时间段失效，减轻给后端服务带来的压力。 其次，当有多个请求访问同一个数据时，如果数据失效，只有一个会去数据库加载，其他的请求会等待其拿到数据。

• 整合本地缓存和 Redis: 通过注解指定缓存是在本地还是在 Redis，还是两个都有。 能很方便的实现多级缓存体系。 并且可以让本地缓存特定的 key 失效时，可以同时让集群中对应的 key 都失效。

• 方便的后台管理：可以查看到集群中缓存的命中情况，并能查询缓存内容，让缓存失效。

目前，运满满在广告服务中已经使用 YCache， 接口访问时间的 99 线 从 55ms，降到 10ms，性能提升近 5 倍。

尽管通过各种方式保证代码质量，但各种偶发性故障还是会出现。 出现故障要求及时响应。 针对业务特征，每天会有人值班。 每天早上 7：00 钉钉值班报道。 每天早上 9：30 发值班情况邮件。 值班人员需要及时处理值班群的告警、业务群反馈的系统问题，按故障处理流程快速处理。

在团队人才的培养方面，首先，定期举行各团队 leader 论坛，讨论了团队的未来的技术方向，项目管理规范，质量管理规范和团队建设哲学。 同时，针对各团队的常见问题，针对性的培训核心成员的架构能力，沟通技巧和敏捷开发流程等。

其次，根据过往内部做敏捷开发的经验，规范化了 Scrum 流程中每个 Sprint 里面的需要查看的数据，同时也标准化了每个 Sprint 的必须流程，然后将其工具化为 Sprint 面板，保证团队的一个 Scrum Master 都能按照轻松的按照标准流程执行。 在 Sprint 面板上可以看到每天的 block issue、燃尽图、需求延期情况，开发中的内容，需求变更情况， 员工的任务饱和度。 同时团队负责人也有一个 Sprint 大盘，可以一目了然的看到团队内各 Sprint 的整体情况。 Sprint 大盘主要包含燃尽图，需求延期情况，各 Sprint 的整体饱和度。

除了人员培养和流程优化之外，平时也不断地打造技术氛围。 鼓励新技术的学习，各团队都会定期展开内部分享和外部交流。同时内部建设了技术兴趣小组，大家脑暴出新想法，用工作外的时间完成原型, 评价高的再正式立项来推进，YCache 就是这样产生的。

运营平台的发展方面，首要任务是通过数字化、智能化来提升运营效率。 其一是打造完整的经营分析系统，整合营销审计等系统，提供实时的经营情况分析，实现运营指标预警和运营成本透明化。另外计划实现从预算审批，AB 测试，快速投放到实时效果的活动平台全流程化，让运营同学能快速得到反馈，调整活动方式，提升活动效果。

其次是继续推进业务系统平台化 / 中台化。 第一步工作台平台化，打通各个运营系统，让内部运营人员看到全面的用户信息。 同时通过底层的工单串联现有各个业务系统中的任务。 这样一个用户在满帮全生命周期的信息就能实现在各个系统之间的流动，能大幅提升运营的效率和客服服务的满意度。 然后由于历史原因现在有多套订单系统，要建设订单中台，将现有的订单系统底层都迁移到订单中台，减少类似系统的维护成本，也为新的业务接入提供更好的支持。

在管理上面，目前运满满的运营平台团队基本上是自管理型，不仅仅能执行上级的命令，也能监控过程和进度。 但团队成员还很少自己去规划团队和与运营相关的组织环境。 希望再用一年的时间来更近一步， 达到“自规划型团队”。 另外还会持续通过“传带帮”的方式持续提升团队成员能力，特别是团队内核心同学。 “传带帮”中，所谓“传带帮”就是先把对应职责需要的方法论和知识总结出来交给对应的同学。 所谓“带”就是自己做，对应的同学在旁边观摩。 所谓“帮”就是对应的同学做，自己在旁边纠正。

在采访最后，刘洋岐还谈到了在负责的技术运营和技术学院的相关工作。 运满满技术学院内部有一整套的课程体系，有面向新人的“追风堂”(追风少年)，面向普通员工的“演武堂”，也有邀请外部嘉宾来分享的“罗汉堂”。 其中“追风堂”是特别重要的一环，主要负责给新人介绍企业的规章制度，宣导研发的——“快， 担当，做精彩”文化，解答新人的困惑。这是新人融入企业很重要的一步。同时, 运满满产研有专门的技术门户，其功能类似阿里的 ATA。技术门户是打造运满满技术氛围的很重要一环，专门发表技术预研、 项目总结、用户调研和专业知识分享类的文章，也会把内外部分享的视频沉淀在上面。

点个在看少个 bug