一、闲鱼的业务特色
据巴滕介绍，闲鱼是一个典型的双边市场，买家和卖家规模相互影响，“如何同时服务好买家和卖家双方，这是咱们一直努力的方向”。前端
对买家来讲，要提高商品发现效率，帮助他们尽快地买到商品。web
对卖家而言，要下降发布门槛，帮助他们尽快地把商品卖出去。算法
对于平台，要持续优化用户的使用体验，好比下降纠纷和欺诈问题，同时持续扩大市场规模。数据库
二、闲鱼服务端最初的架构设计
众所周知，闲鱼的前身是 PC 时代的淘宝二手，它属于淘宝的一个小频道。当时，闲鱼总体业务规模和用户量都很是小。基本上，单一应用就支撑全部业务，而且总体架构和服务彻底是面向 PC 设计的。后端
“当时，服务端同窗须要时常编写 Velocity 模板代码，又因为部分前端代码也部署在业务服务器中，前端和服务端同窗还要常常须要修改同一个应用。”巴滕说。缓存
当时，闲鱼服务端的基本架构以下图所示：服务器
据悉，webx 是阿里内部大量使用的一套基于 Java Servlet API 的通用 web 框架，能够类比为 Spring MVC，“在阿里 PC 站点上通过多年应用，不只成熟可靠，并且具有极高的扩展性和开放性”。微信
巴滕称，“这套架构当时跟淘宝的 PC 架构是基本一致的。因为业务规模小，还未作服务化拆分，而且负责维护开发的技术同窗常常调换，因此采用这种单一服务架构，维护成本相对较低又能支撑业务诉求。”架构
三、闲鱼服务端架构演进
刚创立时，闲鱼的定位是作移动端独立 App。这样，他们在作架构设计时就面临两大问题：app
-
总体架构必须从 PC 全面切换为无线，这须要进行大量的 0 到 1 的技术基础设施的完善和引入； -
业务形态复杂化，单一应用带来的耦合问题和开发效率问题，所以要进行服务端的服务化改造。
不过，手机淘宝当时已经积累了一些无线端的基础设施，例如统一无线网关、开关系统、hotpatch 等。
这样，第一波的改造更多的是接入和集成阿里集团的这些无线中间件。客户端（包括前端）和服务端的工做界面也以无线网关的接口为分割线，服务端主要负责基础的数据返回，客户端则完成数据到 MVC 模型的绑定和控制。
服务端则进行了一些服务化改造，从单一应用进行横向拆分（按业务拆分）和纵向拆分（对数据层的访问进行收敛，并根据服务能力让一些基础能力下沉造成公共服务）。业务层作薄，更轻量化的支撑业务快速迭代，拆分独立业务网关层来对接无线接入层网关，收口完成全部的客户端业务数据，最后拼装。
此时，闲鱼服务端的架构基本以下图所示：
在第一轮无线化和服务化改造后，闲鱼服务端初步可以应对 App 的正常迭代。可是业务发展速度太快，用户规模以极快的速度增加，业务团队的需求快速膨胀，这让技术又面临新的挑战：
-
线上服务性能不足 -
迭代速度不够快
用两个典型例子来讲明。
案例 1：闲鱼商品量从数十万快速膨胀到数千万，而闲鱼原来用 Lucene+solar 搭建的搜索引擎出现问题：不管是服务能力，仍是算法能力接入，以及运维成本，都已经不堪重负。闲鱼必需要升级整个搜索引擎。“当时，咱们的选择是升级到集团的大规模搜索引擎 HA3 上，同时接入集团统一推荐平台 TPP 上“。
案例 2：随着业务需求的不断增多，大量的活动类型开发须要前端上线，可是每一个活动对服务端数据又有略微的差别。若是所有都须要服务端人员每一个接口定制开发，服务层网关开发以及发布等工做量和周期都较大。所以，团队在服务端上参考 Facebook 的 GraphQL 作了一套本身的 MBaaS 的解决方案。它被称之为 Card 模型，其核心思想是基于 MVVM 的概念，将一部分 Model 和 View Model 以及部分的 View Controller 前置到服务端下发，客户端作薄。
在巴滕看来，应对服务能力不足，他们更多的是在作一些基础能力的升级，好比更完全的业务服务化拆分和解耦、存储层优化（数据库拆分和扩容，大规模多级缓存等）和一些关键服务的升级。而应对研发迭代速度慢的问题，更多的是作一些动态化和复用性的尝试，尽量下降协同成本，提升代码和模块的复用性。
当时的系统架构以下图所示：
通过第二轮的升级改造，服务端在性能上已经不惧任何规模的流量。基本上，只要作好容量规划和采起各类高可用措施，就能保障系统的服务能力足以应对业务增加。
而在这一轮的改造中，团队又看到从原来纯粹的工程主导，开始逐步有更多算法能力的接入，“咱们在整个搜索和推荐链路中初步具有智能化的能力”。
很快，服务端又面临新挑战：来自业务须要带来的新增加点的压力。巴滕表示，“近几年来，最大的技术红利莫过于 AI 和数据，如何让 AI 和数据在闲鱼有效地落地和发挥价值，这是算法和工程团队共同面临的问题，所以第三轮的技术优化应运而生。”
想拥抱 AI 和数据，首当其冲的是透彻的分析业务自己面临的核心问题。由于算法最擅长的是解决明确目标下的优化问题，因此团队又对闲鱼的业务进行抽象，分析找到闲鱼最核心的业务问题。
下图是将闲置市场和新品市场作的对比。由图可知，在新品市场上，因为商品和服务的肯定性，价格基本上能够反映商品自己的价值。可是，在闲置市场上，不管是卖家，仍是买家，都面临较高的信任成本。信任成本不只仅体如今防范欺诈，还有买家和卖家对商品自己新旧程度认知差别带来的纠纷。
从图能够得知，闲置市场的特色决定了团队扩大市场空间的两个核心路径：
-
提升匹配效率 -
下降信任成本
所以，闲鱼的不少工程和算法就开始围绕这两个核心方向展开，并构建一整套的产品技术体系。
巴滕称，“对于下降信任成本，暂且按下不表，由于信任的解决和构建涉及到大量的琐碎和细致的工做，甚至依赖于整个社会的进步，咱们主要介绍如何提高交易效率的一些思路。”
首先分析致使闲鱼交易效率低的关键要素：
-
轻发布。商品发布门槛低，只需少许图片 / 视频和简单的描述便可发布成功，可是轻发布带来的核心问题是商品自己有效信息量太少。举个例子，用户发了一张图，写了八个字——刚买的苹果转手出。系统就没法准确判断用户发的是苹果手机，仍是真的水果，这样商品在搜索推荐链路的准确率必然受到影响。 -
商品单库存。商品只有一件，售出当即就下架了，那么整个搜索推荐链路对实时性要求就极高，否则就会带来大量的流量浪费。
基于这两个问题，“咱们作了两个关键系统：一个是系统解决商品结构化问题，一个是系统解决整个流量分发链路上的实时性问题”。
与此同时，在面临团队进一步扩大、协做成本和稳定性风险增高的前提下，他们还孵化出一系列支撑业务解耦和隔离（SWAK 解耦框架）、线上故障实施定位（神探系统）等一系列的服务端系统和工具。
此外，他们在端上全面拥抱 Flutter，逐步构建了一系列基于 Flutter 和 native 混合栈一系列工程化和规模化开发框架，同时还在端上进行了一些智能化的探索。
这时候，闲鱼服务端架构演化成下图模样：
如今，除了继续解决业务领域的问题，团队还在进一步持续探索适应将来多端一体化的研发架构，但愿经过底层技术的升级，进一步压缩业务开发同窗在客户端双端加上服务端这三个端上的协同成本。
这套架构的核心思想是基于 dart 语言完成三端在协议层和通讯层的统一，将传统服务端最后一步的数据拼装的胶水层工做所有交由一个客户端的一位技术人员就能完成。
巴滕说：“得益于 Serverless 的快速发展，咱们的胶水层服务端接口已所有托管在阿里自研的 FAAS 平台 GAIA 上，能够实现很是低成本的运维开发，让业务开发同窗更多的聚焦在业务上。”
四、在服务端架构上的新尝试
据巴滕透露，闲鱼服务端架构目前在一体化开发模式和智能化上进行一些尝试。
对他们来讲，Serverless 更可能是基础设施。他们的工做重点是基于集团不断构建的 Serverless 能力上，持续迭代和演化他们的一体化业务开发架构。而 Serverless 自己仍是交给更专业的中间件和阿里云的相关团队。“一体化开发模式有可能改变咱们总体的研发模式，先后端工做边界将再一次改写”。
智能化有两个含义：一个是在业务各类场景和工程环节中，如何充分的融入算法能力。这须要充分考虑算法能力边界，构建服务于算法的实时 / 离线数据能力、ab 能力等基础设施。同时，他们还在进行云智能和端智能结合的探索、商品和内容结构化工程体系等。
智能化的第二个含义是经过智能化提高研发效率。众所周知，整个研发流程链路是很是长的，从脑图到 PRD 到视觉交互再到开发测试，每个环节均可能因为信息传递差带来的效率下降和 bug 出现。他们但愿经过一些自动化的方式下降整个研发流程中一些信息传递的损失，下降重复性劳动，好比一直不断优化的 UI2Code 项目但愿把视觉稿经过图像识别自动转化为可读性高的代码。
五、对服务端架构的思考
在巴滕看来，服务端架构目前最火的就是 Serverless，“可是咱们要透过现象看本质，服务端架构永远在作两个方向的优化”。
-
研发效率。如何让业务开发效率更高，更少的人能够作更多的事，而且保证作的又快又稳又好。其实，Serverless 只是给出了一个解法，且目前尚未事实上的行业标准（作到相似 Spring 同样），这也是他们一个持续探索的方向。 -
业务赋能。技术要想在公司财报上不只仅体现为成本，就要持续的创新，尤为是在 AI 浪潮下，服务端架构如何更全面的拥抱算法，让算法在工程平台上能够充分的发挥价值，这也是尤为要关注和思考的。“能够不作算法工程师，可是不懂算法的业务架构师必定作很差业务架构，这是我我的最近的一个认知。”他说。
六、写在最后
从闲鱼创立至今，巴滕见证了闲鱼从无到有、从小变大的过程。回首这 6 年，他这样总结——凡是过往，皆为序章，闲鱼依然有大量的问题须要解决，还有更广阔的空间须要探索。而在架构方面，他如今更多的思考：一是如何真正的赋能业务，如何让不可能成为可能，让在发生的事情变得更高效；二是如何进一步解放技术，让咱们的时间和精力花费在更使人愉悦的 coding 上，而非简单的消费型代码。
本文分享自微信公众号 - K8S中文社区（k8schina）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。