关于后端:标准化思想及组装式架构在后端BFF中的实践

1. 前言

在本地生存服务畛域，面向 C 端的信息展现类性能存在着类生物零碎的复杂性，具体体现在以下三个方面：性能多 ，为了帮忙用户高效找店、找服务，信息会在尽可能多的中央展现； 差别大 ，同样的信息，在不同客户端、不同页面及模块下的展现逻辑会存在一些差别； 性能易变，产品逻辑常常调整。以上三个方面的特点给研发同学带来了很大的挑战，比方当咱们面临数千个功能模块，数十个行业产品的继续需要时，如何疾速响应呢？

进入互联网“下半场”，靠“堆人力”的研发形式曾经不再具备竞争力了，真正可行且无效的形式是让零碎能力变得可积淀、可组合复用、可灵便应答各种变动。在多业态、大规模定制需要的背景下，本文分享了如何通过组装式开发的办法来晋升业务的竞争力。

2. 背景与问题

2.1 业务背景

先来讲一下咱们的业务和产品，美团到店是一个生存服务平台，通过“信息”连贯消费者和商家，帮忙用户升高交易成本，这是信息产品性能的业务价值。当咱们关上美团 / 点评 App，搜寻“美发”，就能够看到一个搜寻后果页，展现着基于关键词召回的美发商户（如下图左所示）。商户上面挂着以后门店所提供的团购、会员卡概要信息，咱们抉择一家门店进入商户详情页，自上而下滑动，能够看到商户的地址模块、营业信息模块等根底模块（如下图右所示）。持续往下还能看到商品货架模块、会员卡模块、发型师信息等等，以上就是信息展现产品的具体状态。

前文咱们提到过本地生存服务行业信息类产品性能的外围特点是性能多、差别大、性能易变，为了帮忙读者更好地理解相干的业务背景，针对这几个特点咱们进一步补充：

• 性能多：在多业态背景下，信息展现性能总体上体现为功能模块十分多。次要是因为同样的内容会在多个中央展现，比方某个行业的商品信息会在 App 的首页、搜寻后果页、频道页、详情页、订单页、经营页等多个页面进行展现。并且当新行业新内容呈现的时候，又会全面铺开，进而导致减少更多的性能。截至目前，咱们已有上千个展现性能，呈规模化势态。
• 差别大 ：差异化次要体现在雷同的内容，在不同行业、不同客户端、不同模块、不同版本甚至是不同用户条件下，都会有不同展现逻辑。比方商户详情页货架的商品题目这个字段，有的行业展现的规定是“服务类型 + 商品名字”，如“[玻璃贴膜] 龙膜全车车窗隔热膜套餐”。有的行业的展现规定是“服务个性 + 商品名字”，如“[洗吹]单人明星洗吹 + 造型”。再比方跳转链接这个字段，H5、小程序和 App 内的跳转链接的拼接规定都不一样。诸如此类的差别简直贯通所有的性能。
• 性能易变：次要体现在产品逻辑会常常产生迭代。剖析变动起因来自多个方面，首先是这类信息产品面向海量互联网用户，用户体验敏感度高，轻微的展现规定差异都可能会导致不同的转化成果，到底是哪个展现规定成果比拟好，产品只能通过一直的调整来进行验证。其次，本地生存服务标准化水平低，内容自身的构造也在一直迭代，内容变更同时也决定了展现性能要跟着变。最初一点，互联网行业中产品的职责也会常常进行调整，不同的产品对性能的了解是不一样的，这也是导致性能更迭的起因之一。

以上是生存服务行业信息产品的特点，面对大规模、差异化的信息展现类性能的挑战，产品在继续迭代，研发同学又面临怎么的问题和挑战呢？

2.2 研发挑战

在分享技术挑战之前，能够先看看研发同学的日常。这里有两个小场景：

• 场景一，由 B 端（商家 / 经营）间接生产进去的信息，不能间接展现给用户。B 端次要关注信息是否高效录入，录入的信息不适宜间接展现给用户，须要通过一些逻辑加工，同一份 B 端录入的信息可能会有多种加工展现规定。
• 场景二，因为 B / C 端业务畛域问题差异较大，为升高开发难度，B/ C 端个别会做精细化分工，一拨人专一 B 端的信息录入能力建设，一拨人专一 C 端的信息展现。

而咱们就是专一信息展现的这拨人。这类零碎业界也有一些规范的术语，叫 BFF（Backend For Frontend）。BFF 的主要职责是组合应用底层数据，额定解决 C 端展现逻辑。综上所述，咱们研发同学具体的工作通常是：通过内部数据源将原始数据查到，而后依照产品的要求，把查到的原始信息加工成能够展现给用户的信息，最初发送给客户端应用。如下图所示，这部分工作次要由两头的 BFF API 服务负责：

看到这里，咱们猜你可能会这么想：就这么简略的工作，能有啥技术挑战？的确，如果是站在纯编码的角度，代码“撸上”就完事了，的确没什么挑战。但，这不是一个简略的敲代码问题，而是一个工程问题。当有上千个这样的性能，产品需要继续涌入时，如何用无限的研发资源满足有限的业务需要，同时可能控制系统的复杂性及运维老本，还要思考人的成长问题，这才是咱们面临的要害挑战。

• 问题 1 – 效率：天下文治，唯快不破。产品性能谋求疾速上线仿佛是个永恒的命题，在互联网行业 C 端海量用户的背景下，这个命题尤为突出。此外，很小一个性能点的改变就会对用户体验产生十分大的影响。在人力无限的状况下，如何满足大量产品需要疾速上线是研发团队面临的首要挑战。
• 问题 2 – 复杂性：略微有点谋求的工程师都会思考代码复用的问题，不论代码写得优不优雅，相对不能允许反复，于是代码中就充斥着各种if…else…，因为有的逻辑只有当某些特定状况下才会运行。然而，复用须要良好的建模，嵌入过多的逻辑，只会让零碎的复杂性变得越来越高，进而让零碎难以进行下一步的演进，这通常会耗费大量的隐性老本。如何管制好零碎的复杂性，让零碎长期保持可了解、可批改，是咱们面临的又一挑战。
• 问题 3 – 运维老本：如果短少形象的过程式开发，还会导致系统性能变得十分繁多，接口就好几百个，平时这些接口的运维工作也要消耗大量的人力。如果性能的开发短少对立的章法，代码逻辑简单交织，就会给运维工作带来十分大的挑战。
• 问题 4 – 成就感：依据马斯洛需要档次的实践，顶层是“自我实现”的需要。如果落实到工程师的日常，大家也须要在工作中找到成就感。可问题在于，如果每天都“过程式”地编写数据的查问、加工和组装的业务，对大家来说，很难产生什么成就感。

导致这些问题的根本原因是什么呢？这里想借用美团联结创始人王慧文在知乎上说的一句话，以迷信和工程追求真理。真谛是什么难以定义，但咱们肯定要使用迷信的、工程的办法。上面将会进一步介绍对这个问题的思考以及咱们的解决思路。

3. 问题剖析与解决思路

3.1 问题思考

惯例编程的根本工作，总是基于某种编程范式开展的，比方面向对象、过程式、函数式。咱们很容易就想到，如果解决问题的范式不能很好地和问题相匹配，那么就会引起矛盾。所以历史上有很多应用汇编语言难以完成大规模我的项目、应用结构化编程难以应答超大规模我的项目的故事。

那么，前文提到的问题，是不是因为开发方式和业务问题不匹配而导致的呢？举个艰深的例子，好比咱们当初要做的是一道西红柿炒蛋，然而拿出的工具却是电烤箱，结果可想而知。当然，有人说可能会说“真正的高手是能够的”，但毕竟绝世高手是极少数。而如果咱们拿的出是平底锅，必定会更容易一些。所以解决问题不能一味地谋求成为“绝世高手”，升高解决问题的门槛才是真正卓有成效的形式。

静心反思，咱们认为真正起因在于：咱们所应用的开发范式与业务问题不匹配。换句话来讲，咱们对问题短少针对性的建模，短少针对性的方法论。比方在业务层面，咱们的诉求是可能疾速交付，可能满足需要的多样性，并且可能疾速响应产品性能的灵便变动。在技术层面，咱们的诉求是在人力无限的背景下，让零碎复杂度可控，且代码复杂度不会与业务逻辑出现“乘积式”关系的减少。此外，还要保障运维老本可控，零碎数不会和性能数出现“线性关系”的减少。

而咱们以后的开发方式却是“过程式”的，这种“过程式”体现为面向产品需要文档的直译式编程。但这种开发模式和咱们的诉求并不匹配。因而，咱们须要取寻找适宜咱们本人的开发范式。

3.2 标准化及组装式思维

John Ousterhout 曾说过：复杂性是由模糊性和依赖性引起的。模糊性次要源于对事物短少清晰的概念形容，因而复杂性通常会通过利用很多要害概念来解决，这些概念通过形象、合成、迭代和细化这样的办法来进行表白，建设明确的概念是打消模糊性的要害，也是咱们解决简单问题的惯例思维办法。

在这个过程中，合成指的是把一个较大的问题分解成较小的、可治理的单元，每个单元都能够独自解决，这些单元被称为模块、包或组件。这个思路能够追溯到哲学上的“还原论”，目前已成为软件工程的很多方法论的外围。依赖性指的是模块之间依赖关系的多少以及强弱水平，比方一个模块是否依赖另一个模块的实现，模块之间的依赖是否遵循对立的契约，这些都会影响到零碎的复杂性。

组装式开发指的是将零碎合成为规范组件，再由规范组件组装成零碎，以此造成的架构被称为组装式架构。跟传统代码复用技术要害的不同点在于组件的含意。组件是高度标准化的单元，具备可复用性、标准化、可替换性、可包装及独立自治这些特色。组装式开发背地的外围逻辑是基于标准化思维的代码复用。

对于标准化，历史上还有这样的一个故事：18 世纪末，美国刚建设不久，因为国内外战火尚未平息，政府放心会与法国作战，急需筹备大量的军火。然而，过后的传统制枪形式是依附纯熟的工匠采纳磨、削、锤等工序制成一个个非标准的枪机整机，而后将它们组装成枪支，这种制作方法即便全部都是“能工巧匠”，生产效率也十分低下。于是，在政府的催促下，伊莱·惠特尼（美国发明家、机械工程师和企业家，创造了轧花机、铣床）把整个工序分成若干工序，并把一个整机都对比规范来福抢的样品纺制成通用的整机，由此在军火生产中胜利地引进了整机可替换性的原理，这是工业标准化划时代的开始。尔后，标准化的互换性原理促成了工业的迅速倒退，惠特尼也被誉为古代工业的“标准化之父”。

再举一个例子，乐高积木玩具咱们都晓得，玩具厂商制作了一批规范的积木，孩童能够基于这些积木组装成不同样式的玩具，喜爱飞机，就组装飞机，喜爱坦克，就组装坦克，这也是利用了标准化的可换性原理。再回到软件行业，基于组件实现大规模的软件复用这个概念，最早来源于 Doug McIlroy 在 1968 年的一次软件工程学会上的演讲，演讲名为“大规模生产的软件组件”，之后这被公认为软件复用的起源。基于这个思维，如果咱们可能引入组装式开发的思维，将业务代码分解成标准化的组件，而后再基于这些组件组装成不同的性能，进而满足不同场景下的业务需要，这不就是合乎咱们需要的开发方式吗？

但知易行难，因为它疏忽了很多事实的细节，咱们在理论利用的时候总是要面临各种事实问题的挑战。柏拉图曾对人生的终极问题做了定义：我是谁？我来自哪里？我将要到哪里去？这些问题连续至今，始终困扰着人们人类。而软件工程也向工程师门提出了软件设计的终极问题：什么是抽象层次？什么颗粒度？以及如何应答变动？

所以，组装式开发的历史崎岖起伏，更难的是在每个技术畛域这些问题的答案还都不一样。比方在颗粒度的问题上，组件的颗粒度到底要多大，颗粒度越大，被批改的危险也就越大，而过小的颗粒度能够让组件更稳固，然而会带来组装的复杂性。再比方在应答变动这个问题上，这段逻辑到底是通用的还是共性的，十分难以分别，然而咱们的零碎设计又强依赖于这个判断，如果最后的判断失误，就有可能导致系统最终的失败。咱们就遇到过这种状况，有一次自信满满地封装了一个组件，感觉应该能够满足各种简单的状况，刚好就在下一个需要来长期，发现不太匹配。

3.3 咱们的解决思路

前文讲，组装式开发看起来正是咱们所须要的开发模式，而后咱们也探讨了组装式开发面临的要害挑战。那么，在咱们的理论业务中，组装式开发真的可行吗？如果可行，咱们又怎么应答随之而来的挑战？特地是本地生存行业细分行业多、性能多。当然在业务给技术带来了挑战的同时也蕴含着微小的机会。因为波及行业越多，零碎性能越多，代码复用的机会也会越高（如下图左所示）。虽说不同的性能在感官上给人的感觉差异很大，然而有很多性能的底层存在着太多的共性。咱们认为，解决问题的关键在于对颗粒度的把控，以及对可变性的解决。

而后，咱们次要从粒度及可变性两个方面着手。在粒度问题上，咱们引入多层次多颗粒度的组件体系设计；在可变性问题上，咱们通过可变性建模让整个性能具备灵便应答变动的能力，最终造成了如上右图所示的概念模型。除此之外，咱们还通过可视化组装的形式来简化组装过程，总体思路如下：

• 产品性能归类之系列化：福特 T 型车生产的案例通知咱们，繁多的产品无奈满足市场化的需要，多样性更具备市场竞争力。然而高效的多样性须要范畴的束缚，所以古代汽车生产商会对产品进行系列化，比方宝马轿车有 7 系、5 系、3 系，系列化是厂商在效率和多样性之间谋求均衡的产物。在软件开发畛域亦然，组件的复用应该是有范畴的，咱们首先将产品性能进行系列化归类，进一步升高了零碎整体的复杂性及设计难度。
• 性能组件提取与预组装：组件标准化是组装式开发的前提，所以咱们须要先将组件提取进去。在最终组装性能的时候，为了升高组装的复杂性，咱们引入了“预组装”的概念。针对每个系列的产品性能，咱们将通用局部提前组装好，将定制局部提前预留进去，定制局部包含性能和个性的定制，这部分可提早到须要的时候再组装。
• 变动应答之可变性建模：在电动车呈现以前，所有的汽车简直都须要燃油来动员，因而燃油机属于共性功能的需要。然而咱们发现，有的车主是老手，对车子十分顾惜，因而须要全景的倒车仪。有的车主是老司机，他们基本不须要全景的倒车仪，所以全景倒车仪就属于变动性能的需要。不仅如此，咱们还发现对于同样有全景倒车仪诉求的车主，他们也会抉择具备不同个性的设施性能，这部分属于更细粒度的定制需要。所以，变动自身是简单的，是有档次的，变动须要被独自建模，才可能被无效治理。
• 可视化组装与配置填充：细颗粒度的组件带来了肯定的组装复杂性，为简化组装过程，咱们将可用组件出现在用户的界面上，开发同学通过点击鼠标即可实现组件的组装，而对于性能个性组件的配置填充，也是在用户界面上间接实现的。

通过以上几个策略，咱们将信息展现场景的研发模式打造成一个多系列产品的生产线，每个生产线都反对组装式生产一个系列的定制性能。下一章节咱们将介绍更多的技术细节。

4. 标准化思维及组装式架构在后端 BFF 中的实际

4.1 产品性能归类之系列化

1）产品系列化

在官方语言里，系列化指的是“对同一类产品的构造模式和主要参数规格进行迷信布局的一种标准化模式”。在咱们这里，系列化指的是对信息类产品性能进行归类，目标蕴含两个方面，一方面是为了升高零碎整体的复杂性，另一方面也为建设组装这些性能的“生产线”做筹备，一个系列的性能由一个“生产线”来组装，组件能够在不同范畴内进行复用。

信息类产品展现的内容通常来自多个畛域，比方一个商品展现模块，可能要聚合门店的信息，很难间接通过畛域来进行划分，那么怎么划分系列呢？显性的差别咱们能间接看进去，次要包含两方面，首先是展现内容方面，咱们可能比拟容易地发现每个展现模块都有次要的展现内容的差异，比方次要内容别离是门店信息、评估信息、内容信息、商品信息等内容，其余信息往往从属于次要内容。其次展现款式方面，有的展现款式差异很显著，比方商品详情页和商品货架模块；有的展现款式差异没那么大，比方同样是商品货架模块，只是个别字段有差别。隐性的差异次要是外部的实现，因为这些实现直观上是看不出来的。

咱们次要从展现内容、展现款式及展现逻辑实现等几个方面来对性能进行归类合并：

• 基于内容：一个模块展现的内容通常分为次要内容和从属内容，不同展现模块最大的差异来源于展现次要内容的差异。比方以展现门店为主的模块和以展现商品为主的模块，不论是零碎实现，还是性能状态，都存在比拟显著的差异。因而咱们首先把展现内容的主体是谁作为归类根据，将不同内容的展现性能辨别开来。
• 基于款式：性能展现的款式差异往往会决定展现数据的差异，如果展现数据差异较大，那么接口则不容易做标准化。比方商品详情页和商品货架模块，商品详情只展现一个商品，同时会展现更多的商品信息。商品货架模块会展现多个商品，然而每个商品只展现少部分的信息，商品货架模块还会展现筛选项。显然它们的接口很难对立，因而展现模式是一个重要的归类维度。
• 基于实现：最初要从实现层面看好不好形象，另外两个维度的形象曾经为这个维度打好了良好的根底。怎么形象呢？比方有两个性能的步骤和依赖性能的组合可能形象的大抵类似，那么这两个性能能够归为一个系列。

以上维度并不是相对的优先级关系，但能解决绝大多数的问题。也存在例外情况，比方有的性能也可能同时展现多种信息，但找不到次要展现的对象，那么咱们能够基于实现这个因素来进行抉择。通过下面一波操作，咱们根本能够失去产品性能的系列化全景，上千个性能通过系列化之后，也就仅仅只有几个系列。以上只是业务层面的划分，那么零碎对应有怎么的设计呢？

2）接口标准化

在产品性能系列化归类之后，同一系列内的产品性能之间依然会存在逻辑差别，这些差别次要体现在展现模型以及外部实现上。展现模型是后端吐给前端的数据结构，次要的职责是承载展现数据，不同性能存在字段上的差异，所以导致模型会有差异。比方一个简略的例子，有的性能有标签字段，有的没有，那在标签这个字段上就造成了差别。外部实现次要包含数据的查问逻辑、加工逻辑等。针对这两方面差别，咱们的外围思路是接口模型标准化及对立业务身份来串联差异化逻辑。

系列化自身更有利于接口模型做对立形象，因为同一系列外部的性能在结构上的差别不会太大，咱们只须要略微做一些形象，大多数字段都能够收敛。对于极少的个别情况，比方某个字段就个别性能才有，咱们就通过 K - V 构造来进行应答。

模型设计的具体细节在这里不过多开展，重点是接口统一化、标准化之后有显著的益处。前后端的合作效率进步了，前端和后端不再须要在每次需要变更的时候都当面沟通一次接口。不仅如此，零碎层面接口的标准化也可能让前端的代码和后端接口的集成关系变得更加稳固。

在搞定接口之后，外部的差别怎么办？下文会介绍咱们在这部分的组装式思路。在这个思路下，外部实现方面的差别最终会体现为一系列不同颗粒度组件的汇合差别，所以这里外围要解决的问题是如何可能辨认性能差异化组装组件的问题。针对这个问题，咱们的思路是引入“业务身份”这个概念，这个概念目前利用得也比拟宽泛，咱们通过业务身份来串联不同业务场景的数据组装组件，从而实现差异化逻辑的解决。

4.2 性能组件提取与预组装

1）性能组件提取

零碎划分办法在业界利用的比拟多的是畛域驱动办法（DDD），基于畛域驱动办法，咱们个别会依照实体或者聚合根来划分子系统或模块，然而对于信息展现类的零碎来说，很难应用领域驱动的办法。因为咱们开发的不是一个单畛域的小零碎，而是一类跨多个畛域的、属于由几千人共同开发的简单分布式系统之上的一个子系统。这个零碎负责查问和组装由底层零碎提供的数据，而后将数据加工、裁剪、组装展现模型给到前端。这类零碎间隔业务实体很远，因而对于这类零碎的组件化合成，不能利用传统畛域驱动的办法，而须要应用一种非凡的办法。咱们的根本的思路是梳理现有流程步骤，将现有性能按相关性归类，同一类性能封装成一个性能组件，而后再由多个组件组合成一个系列性能。这里举个例子：

左图所示的是一个商品货架的场景，右图展现的是要生产这个货架所需展现数据须要经验的流程步骤。通过上图咱们能够看到，货架的展现数据的生产过程次要包含以下几个步骤：

1. 依据查问条件查问商品 ID，比方查问门店下可售卖的团单 ID；
2. 聚合商品维度信息，这些信息包含商品的题目、价格、服务流程、优惠促销、标签等等；
3. 查问货架的筛选数据及商品的摆放规定，比方举荐、热销、新品等标签数，以及哪些商品放在哪些标签上面的摆放规定；
4. 组装后果展现模型，波及聚合数据的再加工，如题目、标签的拼接。

以上流程步骤绝对比拟清晰，并且可能适应一类场景，只是不同场景在步骤内存在局部差别而已。所以咱们能够将这几个步骤抽取进去，每个步骤别离封装成独自组件负责解决一类问题，同时组件能够组合复用。值得强调的是，这些组件的封装都是基于规范的接口实现。

2）性能组件预组装

传统的业务流程编排适宜于流程类业务场景，比方 OA 办公审核零碎，基于业务流程引擎的益处，一方面是容易实现能力的复用，复用现有能力编排出新的流程。另一方面是更容易应答流程的变动，因而特地适宜流程类且流程易变动的场景。组件相似业务流程编排类零碎中的“能力”，如果通过业务流程引擎，也能够实现相似的成果。然而实际上，信息展现场景的业务流程更像是一个图，咱们权且称之为“流动图”，而不是一条长长的管道流程，如下图所示：

流程引擎适宜应答流程的变动，而咱们业务场景中，变动之处不在于流程自身，而在于在这个流动图上执行的步骤汇合。如上图的示例，左侧是有筛选的货架，须要查问筛选标签数据，所以执行的是整个流动图。右侧是没有筛选的状况，不须要查筛选标签数据，所以执行的是流动图的子图，理论业务场景更简单一点的流动图也有，这里只是举个简略的例子。

咱们会发现，不同状况的不同之处在于遍历这个流动图的节点的汇合不同，总体相似在一个残缺的图中选取一个子图。因而，咱们抉择以图的形式组织咱们的组件，而不是传统的流程，这样更贴合咱们的理论状况，也更容易了解。

另外，为了进步组件组装的效率，咱们将一个系列性能应用到的所有组件提前组装好，失去一张全景图。那么在须要的时候，咱们只须要对着这个残缺的图抉择子图即可，而后再基于子图组装定制局部的组件。预组装不仅可能晋升组装的效率，同时也可能防止谬误，让零碎变得更稳固。传统业务流程编排中，能力的利用上下文其实是有限度的，尽管流程引擎足够灵便，然而实际上在编排能力时依然须要人工对能力做检测，确认是不是可能满足以后的流程。而预组装能够从根本上防止这个问题，因为只有是存在的门路，都是能够执行的。

4.3 变动应答之可变性建模

通过将性能组件组织成一个个流动图，每个流动图负责解决一个系列的产品性能展现信息组装问题，此时的组件颗粒度还是较大的。组件颗粒度大的问题在于，容易不稳固，从软件设计的角度来看，是因为变动的因素太多。比方在组装展现模型环节，展现模型组装组件负责将数据组装成发给前端的展现模型，理论业务场景中不同状况对于同一个展现字段的组装存在不同的拼接策略，咱们拿开篇的例子来解说：

左侧丽人行业商品题目的组装规定是“服务类型 + 商品名字”，右图养车 / 用车行业商品题目组装规定是“服务个性 + 商品名字”。其实这个组件的颗粒度刚刚好，因为它让咱们的流动图看起来不至于太简单，但怎么应答这种变动呢？作为有教训的程序员，可能天然会想到条件分支语句if…else…，而且理论中很多我的项目针对这种问题的解决形式都是if…else…。

对于简略的状况，应用这种形式无可非议，咱们这里探讨更简单的状况，过多的应用条件分支至多存在两个方面的问题。一方面是代码将会变得非常复杂，就像稀稀拉拉缠绕在一起的电线，这样的代码难以了解和保护。另一方面，这种模式自身会让共享组件变得极其不稳固。如果咱们的零碎建设在常常有变动的根基上，那么咱们很难保证系统的稳定性，每一次共享组件的变更都面临着故障危险，为了让变动可管控，咱们要对变动进行建模。

1）可变性建模

这些年，软件工程在如何应答“变动”这个问题上，最具革命性的翻新是将共性和变动拆散，拆散的变动通过应用扩大点代码或配置化变量的形式实现。这些经典思维真是太棒了。对于咱们也很有启发，如果将容易变动的逻辑和变动的逻辑拆散开来，同时引入配置化能力，那么咱们的组件将会很容易应答变动。因而，对于可变性的治理，咱们通过规范性能组件引入了可变性拆散这个思维来解决。如下图所示，组件自身具备变动点和配置项这两种应变能力：

变动点 这个概念是咱们对扩大点代码的具象化，寓意容易变动的中央；配置项 用来承接变量的抽离。变动点和配置项都是应答变动的实现形式，那么理论利用时怎么抉择？针对可枚举的变动，能够提取变量配置化。针对复杂度多变性，能够通过变动点来扩大。变动点的具体模式是个接口，将变动点的具体实现放到组件之外，组件外部公共逻辑局部只调用变动点接口。这样的话，不论变动点的中央怎么变，即便有一百种变体，都不会影响组件的公共局部。

针对具体案例，比方查问商品 ID 这个组件，咱们实际上有多个查问索引，比方商品举荐索引、商品筛选索引，还有一些强实时索引，但总体还是绝对稳固可枚举的，所以咱们将不同的查问索引建模为查问渠道配置项，应用的时候只有填写查问渠道配置项即可。再比方展现模型组装这个组件，因为题目的拼接规定会有所变动，而且较为不可枚举，产品规定变动多，因而咱们在题目这个中央设定一个变动点，不同题目组装的逻辑作为变动点的不同实现，这样更可能应答变动。

不同变动点的实现能够认为是组件提供的多种性能个性，因而咱们又形象出可选项这个概念来形容变动点实现。一个变动点有多个选项，选项是可复用的，贴合事实世界，更容易了解。在组装的时候只须要“抉择须要的个性选项”即可满足定制需要。以上通过 变动点 - 可选项 - 配置项 这组概念解决了组件的灵活应变的问题，同时可能让组件自身变得更为稳固。

2）可选项爆炸问题

咱们发现如果每个选项都通过硬编码实现的话，有的变动点可能会存在十分多的可选项。比方标签这个字段，标签往往来源于扩大属性，不同商品的模型和扩大属性不一样，造成这个标签的起源差别很大。如果咱们都是通过硬编码实现选项，那么因为标签起源有所差别所导致的选项扩散问题就会很显著，可能有多少种商品，就会有多少种选项。选项实质上是一种更细粒度的组件，这个组件外部自身也须要有应答变动的能力。因而，咱们的解决思路是为选项这个细粒度的组件减少可配置能力，每个选项能够设计本人的配置项，将易变规定通过配置来实现，这样选项就有了肯定水平应答变动的能力，从而失去了收束。

4.4 可视化组装与配置填充

在以前，当咱们须要开发一个展现性能的时候，咱们须要做以下几件事件：

1. 编写将内部数据粘合在一起的代码，包含近程 RPC 的拜访代码和数据的组装代码；
2. 按照 PRD 编写一遍展现加工逻辑；
3. 将加工好的数据字段填充在和前端同学一起定义好的展现模型上；
4. 构建和集成代码。

组装式开发的根本要求是：将零碎性能基于标准接口封装成不同颗粒度的组件单元，这个要求为产品性能的生产过程带来了革命性的转变。性能的组装不再须要手写“胶水代码”，而是通过零碎就能够实现自动化的组装。大部分的性能是复用已有的组件，而不是重头编写，实际上通过性能个性组件的一直积淀，咱们曾经实现了 80% 以上的产品逻辑都是复用已有组件。

此时，咱们的研发过程整体上可分为 组件开发 和组装集成 两个阶段。组件开发环节关注性能的形象和封装，基于已有组件，组装集成环节做的事件就是抉择须要的组件，填充配置，一旦组装后果被保留之后，即实现零碎的集成，不再须要构件和部署。下图展现的是抉择和集成组件的过程：

组件的抉择和组装这个过程是围绕流动图开展的，总体通过选性能 - 选个性 - 填配置三个步骤，每个步骤所做的具体工作如下：

• 性能抉择：基于对产品需要性能点的捕获，在事后组装好的组件流动图上抉择以后要开发的展现性能所须要的性能组件，这一步操作决定了大体的性能点，比方这个货架须要筛选性能，那么就把筛选组件选中，不须要就不选。
• 个性抉择：性能确定之后再确定更细粒度的性能个性，比方抉择展现模型组装组件之后，这个组件要组装多个字段，每个字段都有多种展现策略，再比方题目这个字段，到底是要带括号的还是不带括号的，此时须要勾选。
• 配置填充：通过以上两个步骤，根本确定了以后要组装的展现性能所需的组件汇合，但有的组件是有配置项的，比方前文举的查问商品 ID 这个组件，填充查问渠道配置项就是在这一步实现的。

填充好配置就能够公布了，零碎运行时，多个产品性能在运行时候共享一套组件实例，差异在于执行组件的组合和配置不同。这一点是通过前文提到过的业务身份来实现的，不同业务身份关联不同的组件组装 DSL 及组件用户配置，最终实现差异化性能组装和执行。

5. 总结

组装式开发实际有没有解决最后的问题？组件分为大颗粒度的性能组件和小颗粒度的个性组件，不同颗粒度的组件都具备复用性和应变能力，因而在展现性能搭建方面的效率有了显著晋升。外部数据显示，咱们组的开发效率至多晋升 50% 以上。

其次，每个组件单元都是通过良好设计的逻辑单元，单个组件的规模都有所管制，因而代码的复杂度失去显著的升高。实际结果显示，研发同学天然开发的业务组件代码圈复杂度不超过 10。另外，通过信息性能的系列化编制，整个信息展现零碎也有所收束，接口数由上百个缩小到了个位数，大大降低了接口的保护老本。

最初，以前研发人员“过程式”地翻译业务需要，当初则须要思考组件怎么设计。因为架构自身提供了这种条件，并且也有这种要求，研发同学在为零碎“添砖加瓦”的过程中须要思考封装和形象问题，以集成到零碎中。封装和形象是根本的软件工程思维，这就让“膂力流动”变成了“脑力流动”，当初研发同学更像是一个软件工程师，工作上也更有成就感。所以，总体上咱们获得了不错的成果。

每个畛域都有各自畛域的复杂性，比方有的畛域问题在于计算简单，有的畛域在于模型的存储和保护简单。因为软件开发是一个工程问题，咱们不能仅仅思考技术的复杂性，同时还要思考业务及人员的问题。迷信的思维通知咱们，解决问题要考究范式，当一个范式不满足的时候，须要有敢于冲破的勇气。本文次要介绍了咱们在信息展现场景下，如何通过新的开发范式来解决咱们所面临的问题，心愿对大家有所帮忙，也欢送大家在文末留言，跟咱们交换。

6. 参考文献

• [1] Pattern: Backends For Frontends
• [2] GraphQL 及元数据驱动架构在后端 BFF 中的实际
• [3] 福特 T 型车丨成也标准化，败也标准化
• [4] 中台之上（十三）：探讨反对组装式开发的业务架构设计办法
• [5] 美团外部的 Slogan「以迷信和技术追求真理」是什么意思？
• [6] 叶柏林. 标准化. 中国科学技术出版, 1988.
• [7] Alan W. Brown. 大规模基于构件的软件开发. 机械工业出版社, 2003.
• [8] Thomas S. Kuhn. 迷信的反动构造. 北京大学出版社, 2012.
• [9] John Ousterhout. A Philosophy Of Software Design, 2018.
• [10] Tassio Vale et al. Twenty-eight Years of Component-based Software Engineering[J]. The Journal of Systems and Software, 2016.
• [11] Rafael Capilla, Barbara Gallina et al. Opportunities for Software Reuse in an Uncertain World: from past to emerging trends. Software:Evolution and Process, 2019.
• [12] Peter Naur, Brian Randell et al. Software Engineering[R]. NATO Science Committee, 1968.

本文作者

陆晨、致远、陈琦等，均来自美团到店综合技术团队。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。