40

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

 4 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzU4MDUxOTI5NA%3D%3D&%3Bmid=2247484865&%3Bidx=1&%3Bsn=91a48b370bf0575d2361f115d2178234
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

前言

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

业务特征

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

vUFfMv6.jpg!web

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

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

m2Q7z2N.jpg!web图2-普通C2C交易正向交易流程

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

ymyI3au.jpg!web图3-交易链路业务特征

演进过程

手淘的方案

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

qAVni2r.jpg!web图4-手淘新奥创

闲鱼的问题

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

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

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

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

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

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

AJbeMfv.jpg!web图5-闲鱼交易链路演进方向

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

UjANJj2.jpg!web图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完成,实现逻辑归一,完成端到端的研发闭环,实现资源配置的优化。

Mni6bmu.jpg!web

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

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

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

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

bMbIzqJ.jpg!web

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

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

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

ZnmQRzq.jpg!web图9-渲染接口设计

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

YnAJVzJ.jpg!web

图10-交互接 口设计

效果

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

后续计划

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

闲鱼团队是Flutter+Dart FaaS前后端一体化新技术的行业领军者,就是现在! 客户端/服务端java/架构/前端/质量工程师 面向社会招聘,base杭州阿里巴巴西溪园区,一起做有创想空间的社区产品、做深度顶级的开源项目,一起拓展技术边界成就极致!

*投喂简历给小闲鱼→ [email protected]

quQ3Mn7.jpg!web

ZriEn26.png!web

开源项目、峰会直击、关键洞察、深度解读

请认准 闲鱼技术


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK