bff是什么意思(bff是什么意思)

bff是什么意思(bff是什么意思)

GraphQL是脸书提出的一种数据查询语言。核心功能是数据聚合和需求，目前广泛应用于前端和后端，解决客户端灵活使用数据的问题。本文介绍了GraphQL的另一种方法。我们将GraphQL汇至后端BFF层，结合元数据技术实现数据和处理逻辑的按需查询和执行。这不仅解决了后端BFF层的灵活使用问题。这些现场处理逻辑也可以直接重用，大大提高了研发效率。本文介绍的实际方案已经在美团的业务场景中使用，取得了良好的效果。希望这些经验可以帮助到大家。

1 BFF.

BFF这个词来自于Sam Newman的《模式：前端后端》，指的是前端后端。BFF问题是什么？根据原描述，随着移动互联网的兴起，原本适合桌面Web的服务器端功能想要用于移动应用，过程中存在这样的问题：

移动应用程序和桌面Web之间存在UI差异。移动应用涉及的用途不同，不仅是iOS，还有Android。这些不同端点的ui之间存在差异。原来的后端功能和桌面Web UI之间已经有了很大的耦合。由于末端的差异，服务器的功能是调整和切割差异，而服务器的服务功能相对单一，导致矛盾的服务器单一服务功能和差异末端呼唤末端。矛盾。那么如何解决这个问题呢？这也是文章的副标题“UIS和外部方的单用途边缘服务”，介绍了BFF，适应了BFF的多终端差异，也是这个行业广泛使用的模型。

图1 BFF示意图

在实际的商业实践中，造成这种结局差异的原因有很多，有一个原因。比如用户的客户端是Android还是iOS，大屏还是小屏，是什么版本。比如属于哪个行业，产品形态是什么，投放什么场景，面对的用户群体是谁等等。这些因素会导致功能逻辑的差异。

在这个问题上，团队负责的项目负责演示，同样的产品和服务，C端的展示功能逻辑，深受产品类型、行业、交易形式、投放、群体的影响。同时向消费端加强和深化，进一步加强和深化发展单一稳定性和服务器端的矛盾。这也是商品展示(产品展示BFF必然的商业体系)的原因。介绍了美团后台的一些问题，解决了商品展示场景的问题。

2核心矛盾在BFF背景中

这一层BFF的引入是服务器的单稳和端的矛盾，没有这个矛盾，但是转移了。原来后端和前端的矛盾转移到BFF和前端的矛盾。团队的主要任务就是对抗这个矛盾。下面是一个具体的业务场景。以此为例，结合当前的业务特点，说明BFF生产模式中的具体问题。下图是两个不同行业的团购货架展示模块。我们认为是两个项目的展示场景，是两套独立定义的产品逻辑，每一套都会迭代。

图2显示了

在业务发展初期，并没有太大的前景。BFF层系统的“烟囱”建设发展迅速，满足了业务需求。在这种情况下，这个矛盾就不明显了。随着商业的发展，行业的发展形成了许多这样的商品陈列，矛盾也逐渐激化，主要表现在以下两个方面：

业务支撑效率：随着产品展示方案越来越多，API有爆发趋势，业务支撑效率和关系有限，系统容量难以支撑业务场景规模。系统复杂度高：核心功能不断迭代，内部逻辑被淹没。别的不说，代码流程写出来，系统高度复杂，修改维护困难。那么这些问题是怎么产生的呢？这要结合“烟囱”系统的背景、业务展示场景所面对的业务以及系统的特点来理解。

1.特征

图例显示，两个不同行业的群体购买了货架模块，这样一个看似很小的模块，后端调用后端20多个下游服务获取数据。这是一个。在两种不同的场景下，数据源设置是有区别的，这种区别一般是存在的。这是第二种，比如页脚组镜头需要的数据源是不必要的。美妆集团针对货架需求采购一些数据源，而修脚集团不需要采购货架。虽然依赖下游服务，但也需要保证C端用户体验，也就是三个。

这些特点给技术带来一个小问题：1)聚合难以控制，聚合功能是场景的构建。还是统一建筑？如果构建场景，必然存在不同场景重复编写相似聚合逻辑的问题。如果构建统一，在大而全的数据聚合中会出现无效调用。2)聚合逻辑的复杂度控制。在这么多数据源的情况下，不仅要考虑如何写业务逻辑，还要考虑异步调用的安排。如果复杂性不受欢迎，那么跟进和贡献更改和修改将是一个问题。

2.特点：描述逻辑，场景之间的差异，常见的单一逻辑耦合

我们可以清楚地认识到，某种逻辑是常见的，比如群体相关的展示场景。可见，直觉基本上是关于完整性的信息，但只是代表。其实模块的生成有很多不同，比如以下两个不同：

场拼接的逻辑区别：比如上图两个团购货架上的团购标题是一样的，标题和美的团购货架的展示规则是：【类型】群标题和足疗团购货架中的展示规则是：群标题。排序逻辑的不同：比如同一组列表中，一个场景按销售额排序，第二个场景按价格排序，不同场景的排序逻辑不同。比如显示逻辑还是有很多区别的。相似的场景其实有很多差异，如何处理这些差异是个问题。以下是最常见的写入方法，具体条件字段用于确定逻辑路由，如下所示：

if(category==

“beauty”）{　　title =“[”+类别+“]”+ ProductTitle;}如果（类别==“修脚”）{　　title = producttitle;}

在功能实现方面，该解决方案并不存在问题，也可以复用。但是，事实上，在很多场景的情况下，会有很多差异判断逻辑叠加在一起，并且功能将能够始终能够想象，系统会变得更加复杂，越来越难得是修改和维护。

总结：此图层中不同商品显示站点的场景存在差异。在业务发展的早期，系统通过独立建设支持业务快速测试错误。在这种情况下，业务差异所带来的问题并不明显。随着业务的持续发展，有更多和更多的场景需要构建和运行，并且显示趋势。此时，业务提出了更高的技术效率要求。在这种情况的上下文中，场景中存在差异，如何满足场景的复杂性来控制系统，这是我们业务场景面临的核心问题。。

3 BFF应用模式分析

目前，这种解决方案存在两个主要解决方案，一个是后端BFF模式，另一个是前端BFF模式。

3.1后端BFF模式

后端BFF模式指的是BFF由后端学生负责。此模式目前是基于GraphQL的最广泛实施的后端BFF方案。指定：后端将显示显示字段显示为显示服务，并在GraphQL使用前端之后暴露。如下所示：

图3后端BFF模式

此模式的最大特征和优点是，当显示字段已存在时，后端不需要关心前端差分要求，并且GraphQL支持按需查询的能力。此功能可以在不同方案中处理不同的场景，前端基于GraphQL按需数据，后端不需要更改。同时，通过GraphQL布置和聚合物查询能力，后端可以在不同的显示服务中逻辑地分解，因此可以在一定程度上解析该层的复杂性。

但是，基于此模式，仍有几个问题：显示服务粒度问题，数据图划分问题，以及现场扩散问题，下图是基于当前模式的特定情况：

图4后端BFF模式（案例）

1）显示服务颗粒设计问题

此方案需要在一个模块中显示逻辑和数字逻辑包以形成演示服务，如上图所示。实际上显示逻辑和逻辑数是多对多关系，或者作为上一个文本中提到的示例：

背景：有两个显示服务，分别封装了产品标题和商品标记的查询功能。

场景：此时，PM已达到需求。希望在某个场景中显示“[类型] +产品标题”的标题。此时，拼接取决于数据类型，而这种类型的数据产品标签显示服务已被调用。

问题：产品标题显示服务我呼叫类型数据或合并两个显示服务？

上面描述的问题是显示服务粒度的问题，并且我们可以怀疑上述示例是因为显示服务的粒子被证明。然后看看，如果两个服务合并在一起，那么会有冗余。这是难点的显示服务设计，核心原因是显示逻辑和逻辑本身的数量越来越多，并且结果设计在一起。。

2）数据图分区问题

多个显示服务被聚合到GraphQL架构中，形成数据视图，只要根据图所需的图中所需的数据，根据查询所需的图所需的数据，可以根据附图中的所需来进行数据。所以问题在于，这张照片应该组织什么？是一张图片或多张图片吗？如果图像太大，它将带来复杂的数据关系维护问题，并且图片将减少程序本身的值。

3）显示服务内部复杂度+模型扩散问题

商品标题的介绍在商品标题的存在下提出，这种逻辑在商品显示场景中特别普遍。如同样的价格，一个行业展示价格，B行业展出优惠;同样的是标签职位，C行业展示服务，D行业显示商品特征。那么，显示模型设计如何设计？以标题字段为例，它位于显示模型上。标题该字段还可以，或单独放置它标题和titlewithcategory.还如果是前者，则该服务将不可避免地存在。如果别的 ...此逻辑用于区分标题拼接方法，也将导致显示服务的内部复杂性。如果您是多个字段，则可以想象显示服务的模型字段将继续传播。

总结：后端BFF模式可以在一定程度上解析后端逻辑的复杂性，同时为显示字段提供多路复用机制。但是，仍有意想不到的问题，例如服务的粒度设计，数据图形的问题，以及内部服务的复杂性和场地扩散。这种模式实践的代表具有Facebook，喜欢所有，eBay，Iqiyi，携程，去哪里等。

3.2前端BFF模式

前端BFF模式在Sam Newman的文章中具有“和自主权”部分的特殊介绍，这是BFF本身由前端团队负责，如下所示：

图5前端BFF模式

该模型的概念是，可以提供团队的需求，无需将其拆迁到两支球队中，两支球队本身带来了大的沟通和合作成本。基本上，对“敌人的矛盾”进入“人民之间的矛盾”也是一种思考。前端充分接管了BFF的发展，并实现了数据查询的自给自足，这大大降低了前后的合作成本。但这种模式没有提到我们的一些核心问题，例如复杂性交易，如何处理差异，如何显示模型的设计方式。此外，该模型还具有一些先决条件和缺点，例如更完整的前端基础设施;前端需要被关心渲染，但也需要了解业务逻辑。

总结：前端BFF模式独立查询并由前端使用，从而实现减少跨团队协作的成本，并提高BFF研发效率的影响。该模型的实践代表是阿里巴巴。

4基于GraphQL和元数据的信息聚合体系结构设计

4.1整体创意

通过分析后端BFF和前端BFF的两种模式，我们最终选择后端BFF模式，前端BFF方案对当前的研发模型有很大影响，不仅需要大量的前端资源，而且还需要全面的前端基础设施。程序的实施成本相对较高。

上一篇文章中提到的后端GraphQL BFF模式存在一些问题，但存在一些问题，但存在一个非常大的参考价值，如重复使用显示字段，数据上的数据查询思想等。商品显示场景，80％的工作侧重于数据汇总和集成而这部分具有强烈的重用值，因此信息查询和聚合是我们面临的主要矛盾。因此，我们的想法是：基于GraphQL +后端BFF方案的改进，实现数字逻辑和显示逻辑的降水，可以组合，可以重复使用整体架构如下所示：

图6基于GraphQL BFF的改进思想

从上面的图中可以看出，与传统的GraphQL BFF方案的最大区别是我们将GraphQL丢弃到数据聚合部分，由于商品领域的数据，该字段相对稳定，因此数据图形是可控且相对稳定。此外，整体架构的核心设计还包括以下三个方面：1）显示分离次数; 2）查询模型属于; 3）元数据驱动器架构。

我们通过拍摄显示器分开显示服务粒度问题，同时使显示逻辑和数字逻辑可以沉淀;可视化，商业组件自动化，使业务开发学生能够专注于业务逻辑本身。以下将逐一介绍。

4.2核心设计

4.2.1编号显示分离

如上所述，在商品显示场景中，显示逻辑和逻辑数量是多对多关系，而传统的GraphQL后端BFF实际解决方案被打包在一起，这很难设计。根本原因。拍摄逻辑和显示逻辑的注意力是什么？数字逻辑会注意如何查询和聚合数据，以及如何显示如何处理生成的显示字段，它们的焦点是不同的，并且显示服务的复杂性也会增加。因此，我们的想法是分离数字逻辑和显示逻辑，分别封装逻辑单元，并分别进行分别和显示单元。在采用分离分离后，GraphQL也会下沉，并且用于按需实现数据，如下所示：

图7取出显示分离+元数据描述

那么，数量和显示逻辑的封装粒度的大小是多少？不能太小，它不能太大，在粒度的设计中，我们有两个核心考虑因素：1）多路复用显示逻辑和数字逻辑是可以在商品显示方案中重用的资产。我们希望他们能安定下来并单独使用; 2）简单的保持简单，如此简单地修改和维护。基于这两点，粒度定义如下：

单位数量：尝试仅封装1个外部数据源，并负责简化外部数据源返回的模型，以及我们称之为模型的模型的这一部分。显示单位：尝试仅打包1显示字段的处理逻辑。

有利的益处很简单，可以组合使用，具体组合如何使用？我们的想法是通过元数据描述它们之间的关系，基于元数据与统一实现框架相关联，并且特定设计将介绍。通过分离数字和演示，元数据与时间的组合之间的相关性，它可以保持逻辑单元的简单性，并满足多路复用需求，这也解决了传统程序的存在。显示服务粒度问题。

4.2.2查询模型返回

显示单元的处理结果显示哪种界面？接下来，我们将介绍查询界面设计的问题。

1）查询界面设计中的困难

CommonQuery接口的设计模型具有以下内容：

强类型模式：强类型模式指的是查询界面返回POJO对象，每个查询结果对应于POJO中具有特定服务含义的清晰字段。弱型模式：弱类型模式指的是查询结果以k-v或json模式返回，没有明确的静态字段。

以上两种型号在行业中具有广泛的应用，它们具有明显的优缺点。强大的模式为开发人员友好，但业务不断迭代。与此同时，系统地沉淀的显示单元将继续富裕。在这种情况下，接口返回的DTO中的字段将越来越多，每次支持新功能都必须伴随着接口查询模型的修改，jar版本的升级。 jar的升级涉及数据提供商和数据消耗，存在显着的效率问题。另外，您可以想象查询模型不断迭代，最终将最终包括数百个字段，难以维护。

弱类型模式可以弥补此缺点，但弱型模式对于开发人员来说非常不熟悉。在接口查询模型中，在开发过程中没有开发人员的感觉，但程序员性质是通过代码，未配置和文档来了解逻辑。实际上，这两个接口设计模式具有常见问题 - 缺乏抽象，以下两个部分，我们将介绍界面返回的查询模型设计的抽象思路和框架功能。

2）自然模型规范化设计

返回产品显示场景，显示字段具有各种不同的实现，例如产品标题的两个不同实现：1）标题; 2）[类] +产品标题。产品标题与这两个显示逻辑的逻辑之间的关系基本上是一种抽象的特定关系。确定此关键点，考虑一下，我们的想法在查询模型中抽象。查询模型是抽象显示字段，并且显示字段对应于多个显示单元，如下所示：

图8查询模型标准化+元数据描述

在实现水平上，显示字段和显示单元之间的关系也基于电平。基于上述设计思路，模型的扩散可以在一定程度上减慢，但不可能避免膨胀。例如，除了每项项目的标准属性之外，例如价格，库存，销售，不同的产品类型通常都有这个产品唯一的属性。例如，Macropical权重场项目具有“几个人”的描述，这个领域本身并不是很重要，并且在商品查询模型中的一个字段中放置在模型扩展中，对于此类问题，我们的解决方案是引入扩展属性，扩展属性以携带此类非标准字段。通过标准字段+扩展属性建立查询模型，可以更好地解决更好场扩散问题。

4.2.3数据驱动器架构

到目前为止，我们定义了如何分解商业逻辑单元如何设计查询模型并参考元数据之间的关系。基于上述定义实现的业务逻辑和模型，它具有强烈的重用值，可以镇定为业务资产。那么为什么要使用元数据来描述业务功能与模型之间的关系？

我们介绍元数据描述主要有两个目的：1）代码逻辑的自动排列，通过元数据描述服务逻辑之间的关联关系，基于元数据实现逻辑之间的相关性，从而可以消除大量的人工逻辑排列代码; 2）业务功能的可视化，元数据本身描述了业务逻辑提供的功能，如下面的两个示例中：

小组基本销售字符串字符串，例如：30元。

集团市场价格显示领域，例如：100元。

将这些元数据报告给系统，该系统可用于显示当前系统提供的功能。通过元数据描述组件和组件之间的相关性，通过框架解析元数据自动执行服务组件的传输，形成以下元数据架构：

图9数据驱动器架构

整体架构由三个核心部分组成：

业务能力：标准业务逻辑单元，包括提取单位，显示单元和查询模型，所有这些都是关键的无障碍资产。元数据：描述业务功能（例如，显示单元，拍摄单元）和服务功能之间的关系，例如显示单位依赖的数据，单位映射的显示字段。执行引擎：负责基于元数据的消费者元数据，以及调度和执行业务逻辑。

通过组合上述三个部分来形成元数据驱动器样式的体系结构。

5 GraphQL的优化实践

5.1简化

1）GraphQL直接使用问题

引入GraphQL，引入了一些额外的复杂性，例如GraphQL带来的一些概念，例如：模式，Runtimewiring，下面是GraphQL本机Java框架的开发过程：

图10本机GraphQL使用过程

这些概念增加了学习的成本和对没有接触到GraphQL的同学的认识，并且这些概念和商业区通常都没有。我们只想使用GraphQL的点播查询，但是由GraphQL本身拖累，业务开发同学应该专注于业务逻辑本身，这个问题如何解决？

着名的电脑科学家大卫班尔说，一位着名的谚语，“计算机科学的所有问题都可以通过另一个层次的间接来解决。”实质上，无法解决的问题没有问题，有必要对此负责，因此我们添加了一层执行引擎层来解决本机GraphQL上的这些问题。目标是阻止GraphQL的复杂性，让开发人员注意业务逻辑。

2）界面标准化数量

首先简化访问，本地人datafetcher.和DataLoader.它们都是相对较高的抽象水平，缺乏商业语义，和探究景观，我们可以总结一下，所有询问都属于以下三种模式：

1检查1：根据条件查询结果。1检查n：根据一个条件查询多个结果。n检查n：一个检查或记录的数量版本。

因此，我们已经标准化了查询界面，业务开发类是基于场景判断，根据需要使用，并且界面数量的标准化设计如下：

图11查询界面标准化

业务开发同学由您想要的uncercope选择，通过通用指定结果类型，1个检查1和1 Check n相对简单，n Check n我们将其定义为批量查询界面，以满足“n + 1”的场景，在哪里批量化字段用于指定碎片大小，Batchkey.用于指定查询密钥，业务开发只需要指定参数，并且将处理其他框架。此外，我们已经限制了返回的结果。完成用于满足聚合物查询的完整链接是异步的。

3）采购自动化

接口标准化的数量使数据源更清晰的语义，可以根据需要选择开发过程以简化业务的开发。但此时，业务发展写得很好。获取者之后，你仍然需要去另一个地方。架构和写架构也写架构和获取者映射关系，业务发展更令人愉快，并且不愿意编写代码并转到另一个地方进行配置，同时保持代码和相应的配置也提高了错误的可能性，可以使这些更多的掠夺步骤消除？

架构和runtimewiring.基本上旨在描述一些信息，如果以某种方式描述了这些信息，我们的优化思想是：在业务开发过程中，记录同步，并描述注释元数据的信息。给框架。解决方案的示意图如下：

图12注意元数据描述架构和runtimewiring

5.2性能优化

5.2.1 GraphQL性能问题

虽然GraphQL已被打开，但Facebook只开幕相关标准，并没有提供解决方案。 GraphQL-Java框架是一个社区贡献，基于源的GraphQL-Java作为按需引擎程序，我们发现了GraphQL应用中的一些问题，部分原因是姿势不当，以及一些GraphQL本身实施，例如我们遇到的几个典型问题：

消费CPU查询分析，包括架构分析和询问分析。当查询模型更复杂时，尤其是大列表存在的延迟。基于反射的模型转换CPU消耗问题。DataLoader.hiented调度问题。

因此，我们对使用方法和框架进行了一些优化和转换，以解决上面列出的问题。本章侧重于我们在GraphQL-Java中的优化和转型思路。

5.2.2 GraphQL编译优化

1）GraphQL语言原则概述

GraphQL是一种基于直观和灵活的语法构建客户端应用程序的查询语言，用于描述其数据要求和交互。 GraphQL属于现场特定语言（DSL），而我们使用的GraphQL-Java客户端是基于语言编译级别的ANTLR 4，ANTLR 4是基于Java的语言定义和识别工具，ANTLR是一个版本语言，他们的关系如下面所述：

图13了GraphQL语言的基本原理的示意图

GraphQL执行引擎被接受架构和询问GraphQL定义的语言都是GraphQL执行引擎不能直接理解GraphQL，并且必须由GraphQL编译器转换为在执行之前的GraphQL执行引擎可理解的文档对象。 GraphQL编译器是基于Java的，体验表明，在大流程的情况下，该部分将成为CPU热点。架构要么询问更复杂，绩效损失越多。

2）架构和查询编译缓存

架构表达是一个数据视图和模型的模型，相对稳定，并且没有许多数字，并且我们业务场景中的一个服务是一个。因此，我们的方法是基于启动时的时间。架构构造的GraphQL执行引擎被构造为单个案例缓存，用于询问对于每个场景询问一些差异，所以询问分辨率结果不能用作单一案例，并实现了我们的方法。准备服用预防员接口，基于询问是一个关键询问编译结果缓存。如下所示：

图14查询缓存实现原理图

5.2.3 GraphQL执行引擎优化

1）GraphQL实现机制和问题

首先要了解GraphQL-Java执行引擎的运行机制如何。假设我们在实施策略中选择了asyncexecutionstrygy.让我们来看看GraphQL执行引擎的执行：

图15 GraphQL执行引擎执行过程

上述定时映射已经简化，并且一些信息与关键点无关。asyncexecutionstrygy.的执行该方法是对象执行策略的异步模式实现。它是查询执行的起点，以及根节点查询的入口，asyncexecutionstrygy.对象的多个字段的查询逻辑由循环+异步实现执行。asyncexecutionstrygy.的执行触发方法，据了解，GraphQL查询过程如下：

调用当前字段绑定datafetcher.的得到方法，如果字段未绑定datafetcher.默认propertydatafetcher.查询字段，propertydatafetcher.实现基于反射从源对象读取查询字段。从datafetcher.查询包装完善的如果结果本身是完善的然后，那么它就不会包装。结果完善的完成后，致电compledevalue.，基于结果类型的处理。 如果查询结果是列表类型，则会遍历列表类型，并且每个元素都在递归中执行compledevalue.。如果结果类型是对象类型，则执行对象执行，返回起点，即AsyncexecutionStrategy的执行。

以上是GraphQL的执行过程，这个过程有什么问题？基于图中的标记顺序，您将在业务场景中看到我们的业务方案中遇到的问题。这些问题不代表其他场景也仅供参考：

问题1：propertydatafetcher.CPU热点问题，propertydatafetcher.它属于整个查询期间的热点代码，并且在操作期间，它自己的实现具有一些优化空间。propertydatafetcher.实施将成为CPU热点。 （具体问题可以提交给提交和融合：https://github.com/graphqql-java/graphql-java/pull/1815）

图16 propertyDataFetcher成为CPU热点

问题2：列表的计算时间消耗，列表计算是循环，并且在查询结果中存在一个场景，循环将导致整体查询中的清晰延迟。我们给出了一个具体的例子，假设查询结果中有一个列表大小是1000，并且每个元素的处理是0.01ms，然后整体消耗量为10ms，基于GraphQL检查机制，这10ms将阻止整个链路。

2）类型转换优化

GraphQL模型通过GraphQL查询引擎以及业务实现datafetcher.返回的号码模型是相同的，但所有类型的字段都将转换为GraphQL内部类型。propertydatafetcher.CPU热点是问题的原因是，模型转换过程，GraphQL型模型转换过程的商业定义模型如下图所示：

图17 GraphQL模型转换图的业务模式

当查询结果模型中的字段非常多，例如10,000时，它意味着每次数万次propertydatafetcher.操作，实际上反映了CPU热点问题，我们的解决方案是保持原始的商业模式不变，不会propertydatafetcher.查询的结果又填充到业务模式中。如下例所示：

图18查询结果模型的重新填充示意图

基于这个想法，我们得到了GraphQL执行引擎的结果是业务的结果。获取者返回的对象模型，不仅解决了反思转换引起的CPU热点问题，而且还为业务开发增添了友好性。因为GraphQL模型类似于JSON模型，所以这个型号缺乏商业类型，业务发展非常麻烦。以上在场景导频测试中进行了优化，这表明场景的平均响应时间缩短1.457毫秒，并且平均99线缩短5.82毫秒，平均CPU利用率减少约12％。

3）列出计算优化

当列表元素更多时，默认单线程遍历列表元素计算的延迟消耗非常明显，并且在响应时间中的相对敏感方案需要延迟优化。对于此问题，我们的解决方案是充分利用CPU多核计算能力，将列表拆分为任务，通过多线程并行执行执行，并执行以下机制：

图19列出了多核计算思路

5.2.4 GraphQL-DataLoader调度优化

1）Dataloader基本原理

简要介绍DataLoader的基本原理，Dataloader有两种方式，一个是加载，一是派遣在解决n + 1问题的情况下，DataLoader非常有用：

图20 Dataloader基本原理

总体分为2个阶段，第一阶段电话加载，调用n次，第二阶段呼叫派遣，转移派遣当达到大规模查询+碎片效果时，数据查询将真正执行。

2）Dataloader调度问题

GraphQL-Java是在DataLoader的集成支持的实现中实现的FieldleveltrackingApproach.中间，FieldleveltrackingApproach.问题是什么？以下是基于原始DataLoader调度机制的图片：

图21 GraphQL-Java与Dataloader Scheduling的问题

这个问题很明显，基于FieldleveltrackingApproach.实现，下一级DataLoader.的派遣有必要等到这一级别的结果回来。基于此实现，查询总消耗的计算公式等于：总计=最大（级别1延迟）+ MAX（级别3延迟）+ ...，总查询等于每层的最大值，但实际上，如果链接从业务开发同学安排，理论效果是最长链的最长链。消费时间这是合理的。和FieldleveltrackingApproach.成就的结果是传统知识。至于为什么这样做，我们理解设计人员可以基于简单和一般的考虑因素。

问题是，在某些业务场景下，上述实现是不可接受的，例如我们的列表场景的响应时间约束小于100ms，其中几十个MS是原因的。对于这个问题，一种方法是独立地布置用于特别高的响应时间的方式，并且它不使用GraphQL;另一种方法是在GraphQL级别解决这个问题，维护体系结构的统一。接下来，让我们介绍我们如何扩展GraphQL-Java执行引擎以解决此问题。

3）DataLoader调度优化

DataLoader调度的性能问题，我们的解决方案是在最后一次调用某一。DataLoader.的加载在那之后，派遣方法发出查询请求问题是我们如何知道哪个负载是最后一个负载？这个问题也很难解决DataLoader调度问题。以下示例将解释我们的解决方案：

图22剥离器

假设我们查询的模型结构如下：根节点是询问该字段，将调用字段的名称主题那主题报价是一个列表，主题有两个元素，都是梅德阿对象实例，梅德阿有两个领域，实地和FieldB.那主题[0]的实地关联是ModeelB.一个例子，主题[0]的FieldB.副联交模型例子。

为方便起见，我们定义了一些概念，字段，现场实例，现场实例，字段实例值大小，字段实例值对象执行大小，字段实例值对象等：

场地：使用唯一的路径，它是静态的，并且没有与运行时对象大小的关系，例如：主题和主题/ FIELDA.。现场实例：字段的字段，具有唯一路径，是动态的，与运行时对象大小的关系，如：主题[0] / fielda和主题[1] / fielda一个领域主题/ FIELDA.例子。实地实例已执行：与字段实例关联的对象实例全部由GraphQL执行。字段实例值：Field实例引用了对象实例的数量，例如上面的示例，主题[0] / fielda字段实例值大小为1，主题[0] / fieldb字段实例值大小为3。

除上述定义外，我们的业务场景还符合以下条件：

只有一个根节点，根节点是列表。DataLoader.必须属于一个字段，在一个字段下DataLoader.应该执行的对象实例的数量等于下面的对象实例的数量。

根据上述信息，我们可以绘制以下问题：

执行字段实例时，我们可以知道当前字段实例的大小，字段实例的大小等于字段关联DataLoader.在当前实例下执行加载因此执行的次数加载之后，我们可以知道当前对象实例是否是其现场实例的最后一个对象。对象的一个??示例可能挂在不同的现场实例中，因此当当前对象实例是其字段实例的最后一个对象实例时，并不意味着当前对象实例是所有对象实例中的最后一个，而且只有节点实例当对象实例所在的情况下，当建立节点的最后一个实例时，否则为true。我们可以估计从现场实例大小的现场实例数，例如我们知道主题大小是2，那么你知道主题字段有两个现场实例主题[0]和主题[1]我会知道这个领域主题/ FIELDA.有两个实例，主题[0] / fielda和主题[1] / fielda因此，我们可以从根节点推断字段的实例。

通过上述分析，我们可以连接到对象执行的条件是字段实例是，执行字段的所有故障，并且当前执行的对象实例是其现场实例的最后一个对象。该示例是基于此判断逻辑，我们的实现在每个呼叫中??完成。datafetcher.如果是，则判断是否需要启动。派遣如果启动。此外，上述时间和条件缺失派遣问题，存在一个特殊情况，当前对象实例不是最后一个时，但剩下的对象大小为0，然后永远不会触发当前对象关联。DataLoader.的加载因此，当对象大小为0时，有必要判断另一个时间。

根据上述逻辑分析，我们实施了DataLoader.调用优化链接以实现最佳结果。

6对研发型号的新架构影响

生产力决定生产关系，元数据驱动信息聚合体系结构是显示场景的核心生产力，而业务开发模型和流程是生产关系，因此它们也将改变。下面我们将介绍新架构对开发模型和流程的观点的研究与开发的影响。

6.1焦点业务的开发模式

新架构提供了一组基于业务抽象的标准化代码分解约束。以前，培养学生对系统的理解很可能“检查一个支票服务，将数据粘在一起”，现在，学生的研究和开发将与商业理解和代码分解思想一致。例如，显示单元表示显示逻辑，并且单位数表示数字逻辑。与此同时，框架已阻止许多杂项和容易的错误。研发同学可以有更多的能量，专注于业务逻辑本身，例如：业务数据了解和包装，显示逻辑理解和写作，以及查询模型摘要和构建。如下例所示：

图23业务开发焦点服务本身

6.2研发过程升级

新架构不仅影响了所写的代码的研究和开发，还会影响研发过程的改进，基于元数据架构的可视化和配置容量，现有的研发过程具有重要差异以前的研发过程，如下图所示：

图24基于发展框架，在现场之前和之后建立研究和开发过程

它曾经是“杆到底杆”的发展模型。每个显示场景的施工需要需要体验从界面传播到API的开发的整个过程。基于新架构，系统自动具有多层复用和可视化，配置功能。 。

情况一：这是最好的情况，此时，函数和显示功能的数量已经解决，而同学的研究和开发需要做到这一点。只需创建查询计划，基于操作平台按需显示单元，基于查询保持查询方案ID接口可以找到所需的显示信息，可视化和配置界面，如下所示：

图25副本的可视化和副本

第二此时，可能没有显示功能，但通过操作平台，它易于访问，所以它并不困难，只是准备了基于现有数据源的处理逻辑，这个处理逻辑非常酷。纯逻辑的准备，数据源列表如下所示：

图26数据源列表可视化

情况三：最糟糕的情况是系统无法满足当前的查询功能，这种情况相对较小，因为后端服务相对稳定，那么没有必要恐慌，只需要根据标准规范访问数据源，然后可以遵循写处理逻辑，并且可以连续重复使用这些功能。

7摘要

商品显示方案的复杂性反映在：许多场景，依赖性，逻辑和不同场景。在这方面，如果是业务的初始阶段，如何进入，请使用“烟囱”个性化建筑方法而不必质疑。但是，随着业务的不断发展，功能迭代，以及场景的规模趋势，“烟囱”个性化建设的缺点，包括高复杂性等问题，缺乏能力降水。

本文介绍：

行业不同的BFF应用模式，以及不同模式的优点和缺点。基于GraphQL BFF模式的元数据驱动器结构方案设计。在GraphQL练习期间，我们遇到了问题和解决方案。提出了新架构对研发模型的影响。

目前，负责团队负责的核心商品显示方案已进入新的架构。基于新的研发模型，我们已经实现了超过50％的显示逻辑复用且效率超过1倍，我希望这篇文章有一些帮助。

8参考文献

[1] https://samnewman.io/patterns/architectural/bff/[2] https://www.thoughtworks.com/cn/radar/techniques/graphql-for-server-spe-source-aggregation[3]了解电子商务背景系统，看本文就足够了[4]框架定义 - 百度百科全书[5]高效研究与发展的探索与实践数据汇总中的免费鱼类[6]“系统架构 - 复杂系统产品设计和开发”

9招聘信息

美国使命储存综合研发中心长期招聘前端，后端，数据仓库，机器学习/数据挖掘算法工程师，协调上海，欢迎分享简历：Tech@meituan.com（电子邮件标题：我们小组去商店综合研发中心 - 上海）。

本文是美国集团技术团队，版权属于美国集团。欢迎非商业目的，如分享和沟通，请注明“从美国技术团队转载的内容”的内容。未经许可，本文不允许商业转载或使用。请发送电子邮件至tech@meituan.com申请授权。