一.BFF(Backend for Frontend)
所谓BFF其实是Backend for Frontend的简称，中文翻译是为前端而开发的后端，它主要由前端团队开发（后端微服务一般由后端团队开发）。BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。
BFF 只是一种逻辑分层，而非一种技术，虽然 BFF 是一个新名词，但它的理念由来已久。
BFF 解决了什么问题
如下图，在我们的前端页面时常存在，某个页面需要向 backend A、backend B 以及 backend C...... 发送请求，不同服务的返回值用于渲染页面中不同的 component，即一个页面存在很多请求的场景。
此时，每次访问该页面都需要发送 3 个请求。同时为了保障 Android，iOS，以及 Web 端的不同需求，需要为不同的平台写不同的 API 接口，而每当值发生一些变化时，需要 Android，iOS，Web 做出修改。与此同时，当我们需要对一个字符串进行处理，如限定 140 个字符的时候，我们需要在每一个客户端（Android，iOS，Web）分别实现一遍，这样的代价显然相当大。
于是，我们就需要 BFF 作为中间件。在这个中间件上我们将做一些业务逻辑处理：
而当我们有了 BFF 这一层时，我们就不需要考虑系统后端的迁移。后端发生的变化都可以在 BFF 层做一些响应的修改。
例如，我们加入 BFF 层，原本每次访问发送 3 请求页面，变成一个请求。
使用 BFF 的正确姿势
-
多端应用
我们在设计 API 时会考虑到不同设备的需求，也就是为不同的设备提供不同的 API，虽然它们可能是实现相同的功能，但因为不同设备的特殊性，它们对服务端的 API 访问也各有其特点，需要区别处理。 -
服务聚合
随着微服务的兴起，原本在同一个进程内运行的业务流程被拆分到了不同的服务中。这在增加业务灵活性的同时，也让前端的调用变得更复杂。BFF 的出现为前端应用提供了一个对业务服务调用的聚合点，它屏蔽了复杂的服务调用链，让前端可以聚焦在所需要的数据上，而不用关注底层提供这些数据的服务。 -
非必要，莫新增
我们在看到 BFF 带来的各种好处的同时，也要注意到它所带来的代码重复和工作量增加方面的问题。如果与已有 BFF 功能类似，且展现数据的要求也相近的话，一定要谨慎对待新增 BFF 的行为。因此，建议非必要，莫新增。
实战中的玩法
-
访问控制
例如，服务中的权限控制，将所有服务中的权限控制集中在 BFF 层，使下层服务更加纯粹和独立。 -
应用缓存
项目中时常存在一些需要缓存的临时数据，此时 BFF 作为业务的汇聚点，距离用户请求最近，遂将该缓存操作放在 BFF 层。 -
第三方入口
在业务中需要与第三交互时，将该交互放在 BFF 层，这样可以只暴露必要信息给第三方，从而便于控制第三方的访问。
参考:
二.网关Gateway
根据 Gartner 对微服务的定义：“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。”
与将模块高度耦合并部署为一个大的应用程序相比，微服务的目标是将应用程序充分分解或者解耦为松散耦合的许多微服务或者模块，这样做对下面几点有很大帮助：
- 每个微服务都可以独立于应用程序中的同级服务进行部署、升级、扩展、维护和重新启动。
- 通过自治的跨职能团队进行敏捷开发和敏捷部署。
- 运用技术时具备灵活性和可扩展性
在微服务架构中，我们根据各自的特定需求部署不同的松耦合服务，其中每个服务都有其更细粒度的 API 模型，用以服务于不同的客户端（Web，移动和第三方 API）。
客户端到微服务的连接
在考虑客户端与每个已部署的微服务直接通信的问题时，应考虑以下挑战：
- 如果微服务向客户端公开了细粒度的 API，则客户端应向每个微服务发出请求。在典型的单页中，可能需要进行 多次服务器往返，才能满足请求。对于较差的网络条件下运行的设备（例如移动设备），这可能会更糟。
- 微服务中存在的 多种通信协议（例如 gRpc、thrift、REST、AMQP 等）使客户端很难轻松采用所有这些协议。
- 必须在每个微服务中实现通用网关功能（例如身份验证、授权、日志记录）。
- 在不中断客户端连接的情况下，很难在微服务中进行更改。例如，在合并或划分微服务时，可能需要重新编写客户端部分代码。
API 网关
为了解决上述挑战，人们引入了一个附加层，该附加层位于客户端和服务器之间，充当从客户端到服务器的反向代理路由请求。与面向对象设计的模式相似，它为封装底层系统架构的 API 提供了一个单一的入口，称为 API 网关。
简而言之，它的行为就像 API 管理员一样，但重要的是不要将 API 管理与 API Gateway 混为一谈。
API 网关的功能
路由
网关封装了底层系统并与客户端分离，为客户端提供了与微服务系统进行通信的单个入口点。
整合
API 网关整合了一些边缘的重复功能，无需让每个微服务都实现它们。它包括如下功能：
- 认证和授权
- 服务发现集成
- 缓存响应结果
- 重试策略、熔断器、QoS
- 限速和节流
- 负载均衡
- log 日志、链路追踪、关联
- Header、query 字符串 以及 claims 转义
- IP 白名单
- IAM
- 集中式日志管理（服务之间的 transaction ID、错误日志等）
- 身份的提供方，验证与授权
后端服务前端模式（BFF Backend for Frontend）
它是 API 网关模式的一种变体。它提供了基于客户端的多个网关，而不是提供给客户端一个单一的入口点。目的是根据客户端的需求提供量身定制的 API，从而消除了为所有客户端制作通用 API 造成的大量的浪费
到底需要多少 BFF
BFF 的基本概念是为每种用户体验开发利基后端。菲尔·卡尔萨多（PhilCalçado） 的指导建议是“一种体验，一种 BFF”。如果跨客户端（IOS 客户端、Android 客户端、Web 浏览器等）的要求有很大差异，并且单个代理或 API 的发布时间有严格要求，则 BFF 是一个很好的解决方案。还应注意，更复杂的设计需要复杂的步骤。
GraphQL 与 BFF
GraphQL 是一种 API 的查询语言。PhilCalçado 提出 BFF 和 GraphQL 的想法是相似的，但不是互斥的概念。他补充说，BFF 与你端口的形状无关，而在于赋予客户端对应用程序的自治权，您可以在其中构建与许多 BFF 或 OSFA（one-size-fits-all）的 GraphQL API。
著名的 API 网关
Netflix API 网关：Zuul
Netflix 的流媒体服务可在 1000 多种不同类型的设备（电视、机顶盒、智能手机、游戏系统、平板电脑等）上使用，在高峰时段可以每秒处理 50,000 个请求，这种需求是 OSFA （one-size-fits-all）的 REST API 难以满足的，因此他们为每个设备量身定制了 API 网关。
Netflix 的 Zuul 2 是所有进入 Netflix 云基础架构的请求的第一步。Zuul 2 大大改进了架构和功能，使我们的网关能够处理、路由和保护 Netflix 的云系统，并帮助为我们的 1.25 亿会员提供最佳体验。
亚马逊 API 网关
AWS 提供了完备的托管服务，用于创建、发布、维护、监视以及保护 REST、HTTP 和 WebSocket，开发人员可以在其中创建用于访问 AWS 或其他 Web 服务的 API，并将数据存储在 AWS 云上面。
Kong API 网关
Kong Gateway 是一个开源的，轻量级的微服务 API 网关，可提供无与伦比的延迟性能优化和可伸缩性。如果您只需要这些基础能力，那么它就是很合适的选项。只需要增加更多节点就可以轻松横向扩展。它以非常低的延迟来支持大量可变的工作负载。
其他 API 网关
- Apigee API Gateway
- MuleSoft
- http://Tyk.io
- Akana
- SwaggerHub
- Azure API Gateway
- Express API Gateway
- Karken D
选择正确的网关
评估标准里面，一些常见的指标包括简便性、开源还是专有、可伸缩性和灵活性、安全性、后续功能、社区、管理（支持情况、监控和部署）、环境配置（安装、配置、是否支持托管）、定价和文档等。
API 组合与聚合
API 网关中的一些 API 请求直接映射到单个服务的 API 上，可以通过将请求路由到相应的微服务来提供服务。但是，在需要从多个微服务获得结果的复杂 API 操作的情况下，可以通过 API 组合 / 聚合（分散 - 收集机制）来提供服务。在需要同步通信的情况下，如果服务彼此依赖，则必须遵循链式组合模式。组合层必须支持很大一部分的 ESB / 集成功能，例如转换、编排、弹性和稳定性模式。
根容器的部署必须配备特殊的分发器和聚合器功能（或微服务）。分发者负责分解成细粒度的任务，并将这些任务分发给微服务实例。聚合器负责聚合业务工作流从组合微服务中得出的结果。
API 网关和聚合
具备复杂功能的网关会增大测试和部署的难度。强烈建议大家避免在 API 网关中进行聚合和数据转换。领域专属的功能更应该遵循软件开发实践的定义，在应用程序的代码中完成。Netflix API Gateway Zuul 2 从他们在 Zuul 到原始系统的网关中，删除了许多业务逻辑。
Service Mesh 与 API 网关
微服务中的 Service Mesh 是处理进程间通信的可配置网络基础结构层。这和通常称为 Sidecar 代理或 Sidecar 网关的东西很像。它提供了许多功能，例如：
- 负载均衡
- 服务发现
- 健康检查
- 安全性
从表面上看，API 网关和 Service Mesh 似乎解决了相同的问题，因此好像是多余的。它们确实解决了相同的问题，但是应用在不同的场景。API 网关被部署为业务解决方案的一部分，被外部的服务发现，处理纵向的流量（面对外部客户端），但是，Service Mesh 是用来处理横向流量（在不同的微服务之间）。
实现 Service Mesh 可避免在您自己的代码中出现一些弹性交互，例如熔断器、服务发现、健康检查以及服务观察。对于少量的微服务，应考虑使用其他替代方法来进行故障管理，因为 Service Mesh 集成可能代价太大了。但对于大量的微服务，它的收益是显著的。
结合这两种技术可能是确保应用程序正常运行时间和弹性伸缩能力的一种有效方法，同时又可以确保您的应用程序易于使用。将两者视为同样的产品是不对的，最好将两者视为在涉及微服务和 API 的部署中相辅相成的工具。
API 网关实现的注意事项：
- 可能产生的单点故障或者瓶颈
- 由于通过 API 网关进行了额外的网络跳转以及复杂性风险，响应时间增长了。
参考: https://zhuanlan.zhihu.com/p/212181819