写点什么

一个多业务、多状态、多操作的交易链路?闲鱼架构这样演进

  • 2019-11-29
  • 本文字数:2601 字

    阅读完需:约 9 分钟

一个多业务、多状态、多操作的交易链路?闲鱼架构这样演进

前言

双十一刚刚结束,成交额 2684 亿震惊全世界,每秒订单峰值达 54.4W 笔。在闲鱼 2000 万 DAU,交易数额同样增长迅速的今天,我们如何保障交易链路的稳定与快速支撑业务?这篇文章从客户端开发的角度,介绍闲鱼交易链路业务的架构演进过程,在保证性能的前提下,不断提升研发效率,与大家一起交流过程中的思考。

业务特征

我们今天定义闲鱼交易链路,从闲鱼特有的交易模式“边聊边买”,由交易聊天为入口,下单、订单详情、订单列表及相关二级页面,包含契约签订、履行、违约服务。履约区分为正向交易流程(付款、发货、收货、评价等)、逆向交易流程(退款、退货等)。



图 1-交易链路关键场景(聊天-购买-订单)


交易链路所承接的业务有:普通交易、见一见交易、担保交易、闲鱼币交易、玩家交易、回收交易、寄卖交易等。不同业务在不同状态下提供不同的交易操作。以普通 C2C 交易正向交易流程为例:



图 2-普通 C2C 交易正向交易流程


交易链路具有多业务、多状态、多操作的特征。作为应用的关键链路中的一环,业务相对固化,需要保证性能与体验,同时也需要一定的动态性,能够快速地承接新增业务类型、新增业务状态、新增交易操作,视觉不常改变,对页面组件动态性无强诉求。



图 3-交易链路业务特征

演进过程

手淘的方案

类似的交易场景,手淘提出来不错的解决方案——新奥创。新奥创通过页面区块化与行为通信协议,提供基于业务的页面、组件、规则,前端实现动态模板,后端根据业务将页面进行编排,实现跨端、组件动态化。



图 4-手淘新奥创

闲鱼的问题

在闲鱼业务场景中,特有的 C2C 交易模式,与手淘 B2C 交易模式下差别较大,没有购物车、没有多商品聚合订单。手淘的交易流程可以在天猫、飞猪、盒马等通用。但闲鱼的交易模式,出于业务特征,不适合在手淘完成闲鱼交易流程。


闲鱼 C2C 交易链路业务相对固化,没有强页面动态化的需求。在这样的背景下,前后端向新奥创迁移,成本较高且收益较少。并且,新奥创的后端开发仍然需要关心页面编排,并不是更终态的研发模式。因此,闲鱼没有将新奥创作为技术选型。闲鱼交易链路的侧重点是:


  • 稳定:保证双端一致,减少双端逻辑不一致的场景;

  • 支持一定的动态化能力:端侧仅处理页面渲染,业务逻辑上云;

  • 新研发模式:前端深入业务,实现服务端页面渲染相关逻辑,后端领域下沉,专注领域建设,云端一体;


为达到这个目标,交易链路架构演进经过 3 个阶段:



图 5-闲鱼交易链路演进方向


我们来简单看一下闲鱼交易链路的架构演进过程:



图 6-闲鱼交易链路架构演进

第一阶段:业务解耦

在 2017 年-2018 年,交易链路由原有业务快速迭代时期的简单代码结构,进行了页面区块化改造。此时,服务端大致分为 3 层:底层数据模型、闲鱼 C2X 交易域、业务解决方案。后端基于底层数据模型,根据闲鱼不同业务特性与业务逻辑,搭建闲鱼 C2X 交易域,再以业务解决方案提供不同场景业务数据。


而端侧分为两层,业务数据解析将后端的业务数据,根据不同业务类型、不同交易状态进行解析、整合,转换为页面渲染协议 ViewModel,同时将页面区块化,抽离出不同业务通用组件,根据 ViewModel 直接渲染。


  • 页面区块化

  • 操作 Action 化

第二阶段:两端一体,逐步上云

2019 年,在第一阶段的基础上,我们首先解决双端逻辑不一致的问题,选择了 Flutter 作为跨平台解决方案,同时通过 FishRedux 进行页面区块化改造。交易操作也通过 CommonAction 完成逻辑一致,实现端上的交易操作中台,提供给交易链路多业务场景进行调用。


  • Flutter&Fish Redux

  • 交易操作中心

  • 业务上云


此时,服务端仍分为 3 层:底层数据模型、闲鱼 C2X 交易域、业务层。业务层包含业务解决方案、页面渲染解析。客户端上仅保留渲染层。

第三阶段:云端一体

在前一阶段,客户端将端侧业务逻辑完整上云,但同样出现了瓶颈,在交易业务场景,后端需要更多的精力进行领域建设和沉淀,更少关心页面渲染交互的逻辑,我们希望能有更高效的研发模式,减少各端研发之间的大量的协同, 提升整体研发效率。


此时我们选择统一技术栈 Dart,通过 FaaS 无服务器能力建设,采用 Flutter+FaaS(Dart Runtime)云端一体的研发模式,让客户端同学来写服务端胶水层代码,同时还无需关心传统服务端运维、扩容等工作。原有的业务聚合、渲染协议解析,由客户端同学在 Server 完成,实现逻辑归一,完成端到端的研发闭环,实现资源配置的优化。



图 7-云端一体化工程体系


在云端一体的研发模式中,Server 进行了重新的分层,后端能够专注领域建设,客户端开发完成原有的业务解决方案以及到渲染协议的解析,即下图标红部分。当然,在实际开发过程中,FaaS 与领域的边界因实际业务有一定交集。


  • 服务端开发:完成领域建设;

  • 客户端开发:聚合多域信息,实现渲染协议,端侧直接进行 UI 渲染;



图 8-云端一体阶段详细架构


同时,在交易链路,我们将后端接口划分为渲染接口与交互接口:


渲染接口提供页面渲染数据,下图为 FaaS 部分的代码结构,完成接口校验后,定义页面协议,同时根据业务需求,将多领域数据进行聚合填充。



图 9-渲染接口设计


前文中,我们介绍过,交易包含有多操作,在不同业务中,时常有新增操作的需求。不同订单类型不同订单状态包含哪些操作,由渲染接口实现操作动态可配置,例如”已下单未付款“C2C 普通交易订单,包含“付款”、”关闭交易“操作。操作触发后的实现,需要业务校验、触发领域服务的交互行为,由端侧完全迁移至 FaaS,通过闲鱼的 Nexus 框架使用 Logic Engine 的 Action 通信协议,例如,用户触发创建订单行为,即触发 CREATE_ORDER 的 Action,FaaS 部分调用下单的领域服务后,通过 NativeApi,触发端上相应的操作唤起收银台、跳转链接。



图 10-交互接口设计

效果

当前闲鱼交易链路在云端一体的阶段不断深耕,目前已经落地了下单页面,由原有的前后端 3 人开发变为 1 人开发,减少协同显著提升研发效率,其他场景也已经在规划落地中。下单页云端一体版本闲鱼 11 月版本开始灰度,有兴趣的同学可以亲身体验。

后续计划

本文介绍了闲鱼交易链路的架构演进的过程与思考,不同业务场景适用不同的业务架构,在业务发展过程中,会遇到各式各样的问题或瓶颈,针对业务当前问题与发展方向,选用合理的、收益与成本得宜的技术方案,是顺势而为。闲鱼云端一体化应用架构的落地场景不仅是交易链路,后续会以交易链路为范例不断演进与扩展。


本文转载自公众号闲鱼技术(ID:XYtech_Alibaba)。


原文链接


https://mp.weixin.qq.com/s/eIxbvg-alClmrBmLk13qyQ


2019-11-29 08:002900

评论

发布
暂无评论
发现更多内容

第1周 学习总结

安阳

架构师训练营-Week1-作业2

车小勺的男神

SpringBoot分布式任务中间件开发 附视频讲解 (手把手教你开发和使用中间件)

小傅哥

小傅哥 中间件 springboot 分布式任务

使用VSCode连接到IBM Cloud区块链网络

程序那些事

智能合约 hyperledger fabric ibm cloud

食堂就餐卡系统设计 - 简陋版

X﹏X

食堂就餐卡设计说明书

【第一周】学习总结

黑莓

架构师训练营第一周学习总结

常江舟

极客大学架构师训练营

架构师训练营——食堂就餐卡系统设计

养乐多

第一周:架构方法-架构师如何做架构学习总结

DZ

架构师训练营——第一周总结

Andy风

《第一章:架构师如何做架构》总结

尔东雨田

极客大学架构师训练营

架构师训练营——第一周总结

养乐多

架构师第一周上课总结

种个大西瓜

食堂就餐卡系统设计文档

秤须苑

极客大学架构师训练营

小师妹学JavaIO之:NIO中Channel的妙用

程序那些事

io nio 小师妹 buffer channel

week01总结

seki

极客大学架构师训练营

架构师课程学习第一周心得

秤须苑

极客大学架构师训练营

架构师训练营-Week1-作业1

车小勺的男神

架构师训练营--第1周总结感想

芥菜

架构方法

shangyu

极客大学架构师训练营

week01作业

seki

架构师训练营作业一:食堂就餐卡系统设计

常江舟

极客大学架构师训练营

玄姐公开课总结【构建基于ServiceMesh的普适业务中台架构】

魔曦

架构 Service Mesh

【总结】架构师如何做架构

小胖子

架构方法:架构师如何做架构

让独立思考成为习惯

Neco.W

学习 深度思考 思考

量子技术到底有哪些突破值得重点关注?

蔡芳芳

就餐卡系统设计

小胖子

Week 01 食堂饭卡系统设计

Geek_165f3d

【第一周作业】食堂就餐卡系统设计

黑莓

一个多业务、多状态、多操作的交易链路?闲鱼架构这样演进_架构_君爱_InfoQ精选文章