宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

技术公司采用小额服务框架已有十多年，结果好坏参半。 由于微服务之间的依赖关系，修改一个服务时也需要修改其他服务，微服务的优点打了折扣。 这就是所谓的紧密结合。 但是，组件之间的依赖关系是不可避免的。

如果微服务不能满足用户的需求，那有什么用呢？ 本文重点介绍如何维护有用的微服务并从微服务的迁移过程中获益。 重要的是，各层保持明确的关注点分离，并遵循最适合各层的设计原则。

RESTful API 设计

2000年，Apache HTTP服务器联合创始人发表了一篇名为“web软件架构的架构风格与设计”的博士论文。 的第五章介绍rest (representationalstatetransfer )作为分布式超媒体系统的体系结构样式。 这篇关于Richardson成熟度模型的博文是了解REST在API设计中的作用的优秀资源。

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

提供在线APP的公司将API设计为平台有很多原因。 也许他们想从第三方获得额外的收入来源，或者追加销售给高级用户。 也许他们想让不同的团队更容易调用彼此的API。 也许，我们希望这样组织API，以便可以轻松地重新用于同一产品系列中的类似产品或相关产品。 最后，我想设计一个易于自动化测试的API。

就像提供在线APP的公司开发便于用户理解的GUI APP一样，平台公司也应该开发便于开发者理解的API。 rest风格的API最适合这个需求。

在rest风格的API出现之前，API是基于所谓的远程过程调用(RPC )设计的。 这些API的设计不一致，很难搞清楚它们是用来做什么的。 REST在API设计中引入了一致性。 如果lsw将REST和OpenAPI组合在一起，开发者就可以很容易地知道API的使用方法。

基本新闻来源——rest风格的应用程序浏览器规范。

后端服务可以很容易地调用rest风格的API，但对前端APP来说并不容易。 这是因为良好的用户体验并不那么rest风格。 用户不希望GUI装满碎片实体。 他们想一次性看到所有东西，除非设计需要渐进的表示。 例如，我不想在计划旅行时打开多个页面。 在下单之前，我想在一页上确认所有的概要信息，包括航班、租车、酒店的预约等。

当用户导航到网页，或链接到单页面APP (spa )或移动APP的视图时，前端APP必须调用后端服务来获取渲染视图所需的数据如果使用rest风格的API，则无法通过一次调用获取所有数据。 通常，前端代码会执行一个调用，然后对每个结果项进行更多的API调用，以遍历调用的结果并获取所需的所有数据。 这不仅增加了前端开发的复杂性，还增加了APP页面加载的时间。 稍后详细介绍。

这里的另一个问题是，rest风格的API与前端GUI的关注点不太相符。 rest风格的API本身不支持推送通知，但支持回调(在WebHook上实现)。 WebHook对推送通知的支持度不及WebSocket。 WebHook和Web套接字的区别在于，Web浏览器不支持WebHook，但支持Web套接字。 这是因为web套接字由前端启动，与后端保持连接，后端向前端发送更新。 虽然WebHook是由后端启动的，但是浏览器没有接收这些请求的固定IP地址。 路径用于在rest风格的API中标识特定的实体，因此请求和响应的格式不应该发生很大变化。 为了节省连接资源，SPA可以为所有类型的推送通知打开一个web套接字，每个消息的格式可能有很大差异。

新的用户要求(如添加数据字段)可能需要同时更改前端和后端，这是紧密耦合的根本原因。 团队之间的紧密结合降低了开发速度，这可以用康威定律解释。

团队之间的交流成本高于单个团队中的交流成本。 同时拥有前端和后端开发者的团队也可能效率不高。 理论上，前端开发人员和后端开发人员在同一个团队中，但前端和后端开发人员之间有界线。 这样“隐含”的子团队隐藏了软件开发的复杂性，可以说弥补了康威定律的不成文性。

如果后端服务和前端APP紧密结合，发布管理也会变得复杂。 微服务最大的优点之一是不需要一次性发布所有内容，但是紧密耦合的组件通常需要在同一时间发布。 如果一个组件需要回滚，其他组件也是如此

需要回滚。

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