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