微服务四层架构之边界层的3种边界模式

边界层隐藏了内部服务的复杂交互，只展示了一个统一的外观。

1) 边界层对内部的复杂度和变更进行了封装和抽象。比如，为历史订单的客户端提供一个固定不变的接口，但随着架构演进会重构这个功能的内部实现。如果没有边界层的话，要对每个服务了解很多信息，最后变得和系统的实现耦合越来越严重。

2) 其次，边界层提供了访问数据和功能的方法，以便客户端使用适合自己的传输方式和内容类型来访问。比如，服务之间相互通信采用的是gRPC的方式，而对外的边界层可以暴露一个HTTP API给外部消费者，这种方式更适合外部应用使用。

3) 边界层还可以实现一些其他面向客户端的功能：认证和授权——验证API客户端的身份和权限；限流——对客户端的滥用进行防卫；缓存——降低后端整体的负载；日志和指标收集——可以对客户端的请求进行分析和监控。把这些边缘功能放到边界层可以将关注点的划分更加清晰。

4) 开发者同样可以在服务层中用边界来划分业务领域，比如，下单流程包括几个不同的服务，但是应该只有一个服务会暴露出其他业务领域可以访问的切入点。

本文将介绍3种相关但又不同的应用边界模式：API网关、服务于前端的后端以及消费者驱动的网关。

API网关

API网关在底层的服务后端之上为客户端提供了一个统一的入口点。它会代理发给下层服务的请求并对它们的返回结果进行一定的转换。API网关也可以处理一些客户端关注的其他横向问题，比如认证和请求签名。

网关会对请求进行认证，如果认证通过，它就会将请求代理到对应的后端服务上。它还会对收到的结果进行转换，这样返回的数据更适合客户端。

从安全的角度来看，网关也能够将系统的暴露范围控制到最小。我们可以将内部的服务部署到一个专用网络中，限制除网关以外的所有请求进入。

注意：尽量避免将业务逻辑渗透到API网关中，这会极大增加网关和下层服务之间的耦合度。

服务于前端的后端

服务于前端的后端（BFF）模式是API网关模式的一种变形。尽管API网关模式很简洁，但是它也存在一些缺点。如果API网关为多个客户端应用充当组合点的角色，它承担的职责就会越来越多。

在BFF方案中，开发者为每种客户端类型提供一个API网关。以SimpleBank公司为例，它们提供的每种服务都有一个自己的网关。

网关是高度专一的，对于消费者的需求响应更加及时，而不会导致臃肿或者冲突。这样的网关规模更小，更加简单，也使得开发过程可以更加集中。

消费者驱动网关

在前面两种模式中，API网关决定了返回给消费者的数据的结构。为了服务于不同的客户端，开发者可能需要开发不同的后台。现在我们反其道而行之。

如果开发者可以开发一个允许消费者向服务端表达它们所需要的数据格式，会怎样呢？可以把它看作BFF方案的一种进化版：不构建多个API，开发者可以只构建一个“超级”API来让消费者决定他们所需要的响应数据的样子。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》