支持前端的客户端自定义微服务是什么？后端到后端架构模式描述了一个世界，其中每个客户端应用程序都有自己的服务器端组件——特定前端的后端。如果您有多个客户端接口具有完全不同的需求并且都使用相同的底层资源，则此模式很有效。最常见的现实示例是同时具有Web和移动客户端的应用程序。为了理解为什么“后端到前端”有用，让我们来看看网络架构的一些发展。单个通用服务器上的多个客户端>具有多个客户端的整体应用程序（来源：作者）简单吧？实际上，那只是……但只是在一定程度上。如果您的应用程序足够小，那么这种架构绝对可行！然而，单体往往会随着规模的扩大而崩溃。您可能会听到您的团队开始说诸如...我们的服务器臃肿！客户端特定的控制流无处不在，我们正在努力添加功能而不引入副作用。如果没有合并冲突，我无法提交任何更改。N个团队正在更改这个确切的代码。我们几乎不谈论的事情！构建和测试将永远运行，调试间歇性测试失败将花费数天时间。这些类型的问题催化了微服务的兴起。具有微服务架构的多个客户端>微服务！（来源：作者）如果在适当的范围内实施，微服务非常适合扩展和帮助解决一系列问题。后端团队通常负责一个服务，不再互相绊倒。单个微服务是轻量级的、可定制的、解耦的并且易于扩展。但是，前端团队之间仍然存在边界问题。处理多个客户端的责任仍然编码在一个或多个服务中。前端工程师努力将多个用例塞进一个API层，客户体验开始受到影响。Web和移动团队之间的紧张关系正在加剧。为什么我们不能像处理微服务那样围绕不同的客户划定技术和组织界限？具有专用后端和微服务架构的多个客户端>BFF！（来源：作者）为前端输入后端！我们利用这样一个事实，即我们的客户有不同的需求，从而划定有用的界限。BFF应用程序是轻量级翻译层，可将单个客户端与下游服务分离，并且仅服务于一个前端。BFF的好处前端团队可以享有其客户端应用程序及其底层资源消耗层的所有权；从而实现高速发展。移动团队终于能够进行更改，例如负载大小和频率降低，而无需扩展和分派最初为基于Web的用例开发的API。客户端应用只需要知道一个资源服务器——封装规则！BFF是特定于客户的、一维的和语言无关的。选择正确的API技术从未如此简单。客户端应用程序不受下游服务中API更改的影响。Web和移动团队不再为谁先合并以及谁必须处理合并冲突而争吵。TL;DR，如果……您有多个具有不同需求的客户正在使用相同的基础资源，请使用BFF。您希望针对每个客户优化您的后端API、数据处理或技术堆栈。您的客户需要使用需要大量后端聚合的数据。在功能交付方面存在冲突的开发团队可以从增加的自主权中受益。...但要确保避免跨BFF复制逻辑的陷阱。重复代码是解决相同用例的相同代码的多个实例，并且将经历相同的更改。例如，执行特定的业务规则。没有遵循良好的DevOps实践。更多的后端意味着更多的可部署服务和更高的操作复杂性。不经意间将您的BFF转变为具有业务逻辑、数据库、安全性和厨房水槽的功能齐全的API服务器。保持BFF轻量级并专注于主要用例：高效地将数据转换为客户。未能认识到或适应您的BFF是单点故障这一事实。您的BFF可能与许多服务通信这一事实意味着任何下游服务的故障都可能传播到您的BFF。考虑使用冗余和异步来解决这些问题，就像处理其他类型的微服务一样。
