闲鱼交易链路架构演进过程
君爱
讲述：丁婵大小：7.74M时长：05:38
近日，公众号“闲鱼技术”发文介绍了闲鱼交易链路业务的架构演进过程，其特点是在保证性能的前提下，不断提升研发效率。以下为重点内容。
业务特征
闲鱼 C2C 交易链路具有多业务、多状态、多操作的特征。作为应用的关键链路中的一环，业务相对固化，需要保证性能与体验，同时也需要一定的动态性，能够快速地承接新增业务类型、新增业务状态、新增交易操作，视觉不常改变，对页面组件动态性无强诉求。
在这样的背景下，闲鱼交易链路的侧重点是：
稳定：保证双端一致，减少双端逻辑不一致的场景；
支持一定的动态化能力：端侧仅处理页面渲染，业务逻辑上云；
新研发模式：前端深入业务，实现服务端页面渲染相关逻辑，后端领域下沉，专注领域建设，云端一体。
为达到这个目标，交易链路架构演进经过 3 个阶段：业务解耦；两端一体，逐步上云；云端一体。
第一阶段：业务解耦
在 2017 年 - 2018 年，交易链路由原有业务快速迭代时期的简单代码结构，进行了页面区块化改造。此时，服务端大致分为三层：底层数据模型、闲鱼 C2X 交易域、业务解决方案。后端基于底层数据模型，根据闲鱼不同业务特性与业务逻辑，搭建闲鱼 C2X 交易域，再以业务解决方案提供不同场景业务数据。
而端侧分为两层，业务数据解析将后端的业务数据，根据不同业务类型、不同交易状态进行解析、整合，转换为页面渲染协议 ViewModel，同时将页面区块化，抽离出不同业务通用组件，根据 ViewModel 直接渲染。
第二阶段：两端一体，逐步上云
2019 年，在第一阶段的基础上，闲鱼首先解决双端逻辑不一致的问题，选择了 Flutter 作为跨平台解决方案，同时通过 FishRedux 进行页面区块化改造。交易操作也通过 CommonAction 完成逻辑一致，实现端上的交易操作中台，提供给交易链路多业务场景进行调用。
此时，服务端仍分为 3 层：底层数据模型、闲鱼 C2X 交易域、业务层。业务层包含业务解决方案、页面渲染解析，客户端上仅保留渲染层。
第三阶段：云端一体
在前一阶段，客户端将端侧业务逻辑完整上云，但同样出现了瓶颈，在交易业务场景，后端需要更多的精力进行领域建设和沉淀，更少关心页面渲染交互的逻辑。闲鱼希望能有更高效的研发模式，减少各端研发之间的大量的协同，提升整体研发效率。
此时闲鱼选择统一技术栈 Dart，通过 FaaS 无服务器能力建设，采用 Flutter+FaaS(Dart Runtime) 云端一体的研发模式，让客户端同学来写服务端胶水层代码，同时还无需关心传统服务端运维、扩容等工作。原有的业务聚合、渲染协议解析，由客户端同学在 Server 完成，实现逻辑归一，完成端到端的研发闭环，实现资源配置的优化。
在云端一体的研发模式中，Server 进行了重新的分层，后端能够专注领域建设，客户端开发完成原有的业务解决方案以及到渲染协议的解析。当然，在实际开发过程中，FaaS 与领域的边界因实际业务有一定交集。
同时，在交易链路，闲鱼将后端接口划分为渲染接口与交互接口。渲染接口提供页面渲染数据，完成接口校验后，定义页面协议，同时根据业务需求，将多领域数据进行聚合填充。
前文中，我们介绍过，交易包含多操作，在不同业务中，时常有新增操作的需求。渲染接口就可以实现操作动态可配置，例如“已下单未付款”C2C 普通交易订单，包含“付款”、“关闭交易”操作。操作触发后的实现，需要业务校验、触发领域服务的交互行为，由端侧完全迁移至 FaaS，通过闲鱼的 Nexus 框架使用 Logic Engine 的 Action 通信协议，例如，用户触发创建订单行为，即触发 CREATE_ORDER 的 Action，FaaS 部分调用下单的领域服务后，通过 NativeApI，触发端上相应的操作唤起收银台、跳转链接。
效果
当前闲鱼交易链路在云端一体的阶段不断深耕，目前已经落地了下单页面，由原有的前后端 3 人开发变为 1 人开发，减少协同显著提升研发效率，其他场景也已经在规划落地中。
以上就是今天的内容，希望能给你带来参考价值。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
LXS似乎好像类似Graphql Serverless的架构方式，Apollo Server Lambda
收起评论