边缘服务的一致性、耦合和复杂性

技术公司采用微服务架构已经十多年了，结果好坏参半。微服务之间的依赖关系导致在修改一个服务时也需要修改其他服务，微服务的优势因此打了折扣。这就是所谓的紧密耦合。但组件之间的依赖关系是不可避免的。

如果微服务不能满足用户的需求，那它还有什么用？本文重点讨论如何维护有用的微服务，并能够从微服务的迁移流程中得到好处。关键的是要在各个层保持清晰的关注点分离，并遵循最适合每一个层的设计原则。

RESTful API 设计

2000 年，Apache HTTP 服务器联合创始人发表了一篇题为“网络软件架构的架构风格和设计”的博士论文。其中的第 5 章介绍了 REST (Representational State Transfer)，作为分布式超媒体系统的一种架构风格。这篇有关 Richardson 成熟度模型的博文是了解 REST 在 API 设计中所起作用的一个很好的资源。

在 API 设计和 HTTP 标准之间存在着紧密的一致性。在 RESTful API 设计中，URI 的路径部分用于标识特定实体(也称为资源)。HTTP 谓词用于标识要对实体执行的操作类型。实体可以通过其他实体的 URI 路径部分链接到其他实体。对于 HTTP 状态代码含义的解释也存在一致性。

提供在线应用程序的公司将 API 设计成平台，他们之所以这样做有很多原因。或许，他们希望从第三方那里获得额外的收入来源，或者向高级用户追加销售。或许，他们希望让不同的团队更容易调用彼此的 API。或许，他们希望以这样一种方式来组织他们的 API，让它们可以很容易被相同产品族中的类似或相关的产品所重用。最后，他们希望设计出易于进行自动化测试的 API。

就像提供在线应用程序的公司开发便于用户理解的 GUI 应用程序一样，平台公司也应该开发便于开发人员理解的 API。RESTful API 非常适合这一需求。

在 RESTful API 出现之前，API 是基于所谓的远程过程调用(Remote Procedure Call，RPC)而设计的。这些 API 的设计不存在一致性，以致于难以看出它们是干什么用的。REST 在 API 设计中引入了一致性。当你将 REST 与 OpenAPI 结合在一起时，开发人员很容易就知道如何使用你的 API。

一个基本的新闻源 RESTful API Swagger 规范。

后端服务可以很容易地调用 RESTful API，但对于前端应用程序来说就不那么容易了。这是因为好的用户体验不那么 RESTful。用户不想要背后满是碎片化实体的 GUI。他们希望一下子看到所有的东西，除非在设计上确实需要渐进显示。例如，我不想在规划旅行行程时打开多个页面，我希望在下订单之前能够在一个页面上看到所有的摘要信息(包括航班、汽车租赁和酒店预订)。

当用户导航到一个 Web 页面或链接到单页应用程序(SPA)或移动应用程序的某个视图时，前端应用程序需要调用后端服务来获取渲染视图所需的数据。如果使用的是 RESTful API，单个调用不太可能获得所有的数据。通常是先执行一个调用，然后前端代码遍历该调用的结果，并对每个结果项进行更多的 API 调用，以获得所需的所有数据。这不仅使前端开发复杂化，而且还增加了应用程序的页面加载时间。稍后再详细介绍。

这里还有另一个问题，即 RESTful API 与前端 GUI 关注点不是很契合。RESTful API 本身不支持推送通知，但支持回调(通过 WebHook 实现)。WebHook 对推送通知的支持程度不如 WebSocket。WebHook 和 WebSocket 的不同之处在于，Web 浏览器不支持 WebHook，但支持 WebSocket。这是因为 WebSocket 是由前端发起的，并与后端保持连接，后端会向前端发送更新。WebHook 是由后端发起的，但浏览器没有一个固定的 IP 地址来接收这些请求。因为路径在 RESTful API 中被用于标识一个特定的实体，所以请求和响应的格式不应该发生明显的变化。为了节省连接资源，SPA 可能会为所有类型的推送通知打开单个 WebSocket，允许每一条消息的格式之间存在巨大差异。

新的用户需求(如增加额外的数据字段)可能需要前端和后端都作出修改，这是导致紧密耦合的根本原因。团队之间的紧密耦合降低了开发速度，这个可以用康威定律来解释。

跨团队的沟通成本要高于单个团队内部的沟通成本。同时拥有前端和后端开发人员的团队也可能缺乏效率。虽然从理论上讲，前后端开发人员处在同一个团队中，但在前端和后端开发人员之间仍然存在分界线。这种“隐式”的子团队隐藏了软件开发的一些复杂性，可以说是康威定律的一个不成文的补充。

当后端服务和前端应用程序发生紧密耦合时，发布管理也会变得复杂。微服务的最大优势之一是你不必一次性发布所有的内容，但紧密耦合的组件通常需要在同一时间发布，如果一个组件需要回滚，其他组件也都需要回滚。

GraphQL API 设计

2015 年，Facebook 采用了一种不一样的 API 设计方法，即图查询语言(GQL)或 GraphQL。它是一种包含层次结构类型的模式，该模式包含三种特殊类型：查询、变异和订阅。调用者发送一个命令，该命令提供查询条件，并指定在响应中期望得到的数据格式。

最为流行、功能齐全且成熟的 GraphQL 服务器端框架实现是由旧金山的一家名为Apollo的小型初创公司开发的。有了他们的框架，在客户端增加新功能就变得非常容易，且无需对服务器作出大量修改。

后端开发人员必须编写 schema 和解析器。框架调用在请求中指定的解析器，然后将每个解析器的响应拼接在一起。

类似的基本新闻提要的 GraphQL schema。

由于解析器位于属性级别，而且获取底层数据的机制可能一次性获取多个属性，因此存在重复获取相同数据的可能性，造成了浪费。这就是所谓的 N+1 问题。后端代码应该用某种类型的请求缓存来缓解这个问题。

基于生存时间值(TTL)、最近最少使用原则(LRU)的缓存在 GQL 中的作用是有限的。因为有效载荷是可以灵活指定的，所以很难实现高命中率和低脏读率的高效缓存。因此，GQL 缓存往往要比 RESTful 缓存大得多。Apollo GraphQL 框架支持在 schema 中使用缓存提示注解或在解析器中动态设置，这可以通过浏览器端缓存或内存缓存或外部缓存(如 Memcached 或 Redis)来实现。

变异部分与 RPC 相似，对于它们的处理方式并没有定义好的标准，所以它们都不好理解。

在撰写本文时，GraphQL 的应用程序性能监控(APM)还没有 RESTful API 那么成熟。GraphQL 没有提供内建支持，但有一些插件或解决方案可用于New Relic、Data Dog、Prometheus和App Dynamics。我相信，随着时间的推移，Apollo 风格的 GraphQL APM 监控将变得更加主流。

在 RESTful API 中，客户端指定路径，可能是查询字符串参数，可能是身份验证，仅此而已。而在 GQL 中，客户端必须指定有效载荷是什么样子的。这种小程序增加了调用 GQL 服务的复杂性，从而增加了出现错误的可能性。这也提高了自动化测试的成本。通常的方法是在测试自动化中查询所有的内容，这样做应该足够了，除非解析器需要通过上下文对象交换带外数据。

关注点分离

API 设计该基于 REST 还是 GQL，关键在于你要理解一个计算机科学概念，也就是关注点分离（SoC）。一个设计良好的软件通常由多个层组成，每个层又分为多个模块。如果每个层和每个模块都有清晰严格的关注点分离，那么软件就容易理解，复杂度也更低。为什么会这样？如果你知道在哪里可以找到某个功能的实现代码，你很快就会知道该如何去阅读它的代码（很可能会跨多个代码库）。就像 REST 和 GQL 在 API 设计方面所提供的一致性一样，清晰的 SoC 提供了一种一致性的方式用于找到每个功能的实现。开发人员很少会在他们了解得很透彻的软件中引入 bug。

SoC 的标准由软件架构师来设定。以下是不同层的分类以及每个层应该关注什么。

通常来说，在现代商业软件中，最主要的层是前端和后端。

• 前端软件的直接交互对象是用户，通常运行在移动设备或笔记本电脑上。前端包括移动应用和 Web 应用，主要是关于渲染、绑定、交互和用户体验。其内部结构类似模型视图控制器（MVC）的变种。

• 后端软件的交互对象是前端软件。在生产环境中，后端软件通常运行在数据中心（如公有云）的服务器上。

后端又被进一步分为数据、边缘和集成服务。

• 数据服务为数据库提供保护、执行业务规则、维护一致性，并专注于可伸缩性、性能和潜在的弹性问题。其内部结构包括资源控制器、服务、模型和数据访问对象（DAO）。

• 边缘服务负责处理推送通知、跨端点聚合和安全问题。

• 集成服务应该作为第三方应用的反应式抗腐蚀层，如电商网站（后端集成）和电子表格（前端集成）。

还有其他一些类型的服务这里没有提及。

一个功能全面的服务网格可用于处理弹性、发现、内部认证、加密和可观察性问题。要实现可观察性，需要与其他类型的服务发生交互，获得监控、告警、日志聚合，甚至是分布式追踪能力。

在架构师看来，当开发人员决定模糊这些 SoC（通常是图一时的方便），就是系统开始陷入麻烦的开始。例如，因为 DevOps 的不完善，你决定让数据服务来处理边缘服务或集成服务应该处理的问题，或者让前端应用做一些本该由后端完成的事情。

现代技术栈

大约在六年前，我发现了一种所谓的 BFF 边缘服务。客户端应用程序不会直接调用数据服务，而是通过中间服务来调用，中间服务专门用来满足客户端应用程序的需求。如果设计得当，这种方式可以将数据服务与不断变化需求的 GUI 解耦开来。虽然数据服务仍然与数据库紧密耦合，但数据库 schema 变化速度相对较慢。至少对于相对成熟的项目来说是这样的。

那么 BFF 涉及哪些有用的技术？它们作为 GraphQL 暴露出来，需要基于 RESTful 数据服务提供一个聚合编排层，需要提供 WebSocket 或利用 GQL 的订阅能力，应该由前端团队负责开发维护，并采用前端开发人员比较熟悉的技术栈。

你可能倾向于认为 BFF 会增加延迟，因为多了额外的服务器跳转，但事实却相反。加重延迟的不是服务器跳转，而是数据包的传输距离。为了方便演示，请想象一下以下这种情况。假设一个网页调用了一个 API，这个 API 平均每次返回 10 个数据项，而每个数据项需要调用另外三个 API，这样才能获得渲染页面所需的数据。一位旧金山的用户从亚马逊 us-east-1 区域的服务器加载页面，每个请求来回需要传输 5600 公里。因为总共有 31 个请求，所以数据需要传输 173600 公里，这个距离可以绕地球 7 圈。如果你把这 31 个请求放在一个 BFF 里，并且这个 BFF 与服务器位于同一个数据中心里，那么你总共需要 32 个调用，但数据只需要传输 5600 公里，是不使用 BFF 传输距离的 3%。Web 浏览器可以通过并行的方式调用 API，但相比后端服务，在连接方面具有更强的约束。

另一种边缘服务叫作 API 网关，用于认证、授权、速率限定、单点登录和访问权限管理。如果有必要，它也可以将查询请求路由给 GQL BFF，或者直接将请求路由给 RESTful 服务。对于不同类型的客户端应用程序，需要使用不同的 BFF，但你只需要一个 API 网关就可以满足各种类型的客户端。API 网关有时候也作为第三方的调用代理，让它们可以访问防火墙背后的数据服务。API 网关是一种通用服务，可以由后端开发人员负责开发（OpenResty就是一种比较流行的方案），也可以是第三方提供的产品（比如Kong），或者是由公有云供应商提供的 PaaS 服务。

现代 Web 应用程序几乎都是 SPA（单页应用），而在以前，用户用 Web 浏览器加载 HTML 页面，这些页面可能是由服务器端的 Web 应用程序生成的。当用户单击页面上的一个链接，浏览器会渲染一个全新的 HTML 页面，这个页面也是由服务器端的 Web 应用程序生成的。在使用 SPA 时，用户用 Web 浏览器加载一个 Web 页面，这个页面只包含最基本的 HTML 元素，同时也会下载很多 JavaScript 和 CSS 文件。API 调用是通过执行 JavaScript 代码来完成的，然后生成很多 DOM 元素，浏览器再用这些 DOM 来渲染 GUI。当用户单击一个链接，页面上的 JavaScript 会销毁旧的 DOM 元素，并生成一些新的 DOM 元素。页面看起来发生了变化，但浏览器并没有加载全新的页面。

现如今，大多数前端开发人员使用 TypeScript（具备类型检查特性的 JavaScript 变种）编程，以及 Angular 或 React 等框架。TypeScript 被转译为 JavaScript 和 CSS，这个过程成为项目构建的一部分。在进行本地开发时，开发人员将 Node.js 作为 JavaScript 和 CSS 文件的服务器，也用它将请求路由给目标 API。但如果不是在本地开发，我建议使用 Nginx。这样可以将配置了同源策略的文件与应用程序代码放在一起。构建出来的 Docker 镜像包含应用程序编译后的文件以及与 CORS 或缓存控制问题相关的配置文件。如果你采用了这种方式，可能需要调整 CDN 的配置。

现如今大多数移动应用程序都是运行在 iOS 或安卓系统上。这些操作系统都有各自的技术要求，这里就不赘述了。你可以选择为不同的操作系统单独开发应用程序，也可以使用 Ionic 或 React Native 框架来开发同一套应用程序，然后为不同的操作系统分别生成各自的二进制包。你可以为分别为 iOS 和安卓开发单独的 BFF，也可以简单一点，开发一个移动 BFF 来满足两个平台。

结论

你不必纠结于是选择 REST 还是 GraphQL。REST 更适合面向平台的数据服务，GraphQL 更适合面向 GUI 的边缘服务。如果你的数据服务和边缘服务位于不同的层，那么完全可以同时保留 REST 和 GQL，把二者的好处尽收囊中。

理清不同类型组件之间的关注点分离，有助于降低意外复杂性。有时候，你会为了达成短期目标而模糊了这些关注点。架构师需要努力满足各方的需求。为了满足紧急需求，考虑应用一些短期的解决方案，允许暂时模糊关注点边界，提高意外复杂性。但后续需要马上跟进（需要各方的参与），进行长期必要的重构工作，让系统重新具备清晰的关注点分离，并从整体上降低意外复杂性。这就是技术负债给我们带来的教训。

如果可能的话，降低跨组件的耦合性。紧密耦合的组件应该由相同的团队负责开发维护，并采用相似或互补的开发技术。你不需要为此大幅改变团队的结构。

作者简介：

Glenn Engstrand 是 Rally Health 的软件架构师。他的工作重点是与工程师合作，交付符合 12 Factor 标准的可扩展服务器端应用架构。在 2017 年和 2018 年的 Adobe 内部广告云开发者大会以及 2012 年在波士顿举行的 Lucene Revolution 大会上，Glenn 进行了突破性的演讲。他擅长将单片应用分解为微服务，并与实时通信基础设施进行深度集成。

原文链接：

Consistency, Coupling, and Complexity at the Edge