REST真的完全适合微服务架构吗？

Posted 2021-04-14 分布式实验室

在我接触微服务的这段时间，大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此，你可能理所当然地认为REST就是微服务的一种标准，并且是设计与实现微服务系统一种方式。然而，并非如此。

REST

基于REST的微服务示例比较受欢迎的原因可能是由于它们比较简易，无需借助任何额外的基础设施，服务之间通过HTTP协议就可以直接进行同步通信。

举个例子来说，假设一个系统当热销补货时就需要通知顾客。这个系统可以通过REST微服务实现，如下图所示：

 

2. 网关将请求转发给存货清单管理服务。

3. 存货清单管理服务基于它接收到的请求更新存货清单，随后发送请求到热销补货通知服务。

4. 接着，热销补货通知服务发送请求到订阅管理服务，要求当商品有库存时所有注册用户都需要被通知。

5. 然后，订阅管理服务发送邮件REST请求到邮件服务，通过邮件来通知所有用户。

6. 最后，每个服务依次相应，循环回到网关并且到达客户端。

进行更深入的分析，在实现过程中还需要考虑一些基本事情和缺陷。

阻塞

根据REST的同步原则，更新库存的操作直到通知服务完成通知所有相关顾客的任务前都不会进行返回。设想下，如果有件非常出名的商品，顾客希望当有额外库存时能在1000秒内收到通知，这种同步过程将造成多大影响。性能存在被严重影响的风险并且系统的伸缩性也将受到阻碍。

耦合度和单一职责

当一个产品到货，客户应当被通知’的认识被根深蒂固的认为应当由清单管理服务来做，但是我不这样认为。该服务的单一职责就是更新系统存货清单（存货清单聚合根）。实际上，它甚至都不需要知道通知服务的存在。在这个模型中，这两个服务是的耦合度太紧。

当服务失效

服务是会失败的，当遇到这些情况时，基于微服务的系统需要尽力继续进行这些功能。由于系统的紧耦合，存货清单管理服务（举例说明）就需要一个失败策略来处理当热销补货通知器失效的场景。是应该让存货清单更新失败还是应该让服务进行重试？至关重要的应该是让到达通知器的请求尽快失败，像Hystrix这种环路破坏模式就能够做到这点。虽然不论使用何种通信方式，失败的场景都需要进行处理，但是将所有的逻辑都绑定到调用服务上是非常臃肿的。回到单一职责的问题，我的观点还是认为存货清单管理服务不应该负责处理当通知器失效的情况。

管道

克服服务之间耦合度的一种方式就是根据管道企业模式，将路由职责从微服务中剥离。我们的子系统模式如下图所示：

服务之间的通信依然基于REST，但不再是‘点对点’模式，而是通过官道实体负责编排数据流，不再是通过服务自身。当克服耦合度问题（通过异步管道，阻塞一部分工作）时，在微服务社区中，这种方式也被认为是一种很好的实践用以尽可能地保持服务自治性和一致性。使用这种方式，服务必须依赖第三方实体（例如管道编排服务）以便作为一个系统进行运作，因此，在这种方式下服务是不能够自给自足的。

举个例子来说，我们可以注意到管道只会从热销补货通知器收到一个单一相应（即使有两个订阅者），所以它必须被配置为能够解析相应，从而让邮件通知器能够给每个订阅者单独发送邮件。有人会说，可以将邮件发送器修改为能够通过一个请求批量发送邮件给不同的订阅者，如果是这样，每个用户的用户名就需要包含在邮件内容中，也就还需要一些令牌替换功能。这就带来了额外的行为耦合，即通知器需要特别了解邮件发送器的行为。

异步消息传送

在一个基于消息传递的系统中，服务的输入和输出都被定义为指令或者事件。每个服务订阅那些它们乐于消费的事件，然后通过消息队列或者代理这类机制可靠地获取这些事件，当这些事件被其他服务放入队列中时。

根据这种方式，库存通知子系统可以被重构，如下所示：

通过共享队列名和一种一致且众所周知的指令或事件格式来获取关联性，由一种服务引发的事件或者指令需要能够被其他订阅者服务所消费。在这个架构中，能够获得极大的灵活性、服务隔离性以及自治性。

存货清单管理实例具有单一职责，即更新存货清单，不需要关系当完成自身任务时会引发任何其他服务。因此，其他服务能够被加入系统，它们可以直接消费存货清单更新事件而不需要修改存货清单管理服务，或者任何管道编排服务。

同样，它不需要关心（或者了解）热销补货通知器是否遭遇事故停止服务，存货清单依然能够被顺利更新，就像存货清单管理服务所关心的那样。存货清单管理服务对于失败的无感实际上是一件好事，我们仍然需要一种策略来处理热销补货通知器的失败场景，但是像我之前所陈述，这件事情就不是存货清单管理服务所要负责的。

想要具备能力用以处理像添加、删除、修改这些改变而不影响其他服务的操作或代码，以及能够优雅地处理诸如服务失败这类压力，需要在设计基于微服务系统时考虑两件非常重要的事情。

然而，世界上所有的异步消息传递都不是完全美好的，还需要考虑一些缺陷：

设计/实现/配置的困难

和同步编程模型比较起来异步编程模型通常更加复杂，这使得异步编程模型设计和实现起来更加复杂。这是因为有许多可能必须克服额外的问题，如消息排序，重复消息和消息幂等性。

此外，消息代理的配置也许要进行考虑。例如，对于同一种服务有多个实例，应该将消息传递给所有服务实例还是只传递给其中一个？这两种场景都有使用案例。

异步消息的本性

一个动作结果未立即返回同样会增加系统和用户接口的复杂性，并且在某些场景下，这对于使用异步方式进行运作的系统子集来说甚至没有任何逻辑意义。就热销补货通知器与订阅管理服务的关系来说，没有关于需要被通知的订阅者的相关信息，通知器就不能正常运作，因此对于这种情况同步REST调用就能起作用。这和邮件发送任务是不同的，因为对于邮件来说没有必要立即发送。

信息流的可见性

由于基于消息传递微服务的分散与自治性，在系统内很难获得一个完全清晰的消息流图。这使调试变得更加困难，而且相对于管道方式，系统的业务逻辑更加难以管理。

注意：基于事件的消息传递可以通过应用事件源和CQRS模式进一步扩展，但是这超出了本文的讨论范围。可以查看链接获取更多信息。

因此在设计你的微服务时哪一种通信方式更加合适？这与软件开发（和周期？）的大多数事情是一样的，取决于具体的需求！如果一个微服务实际需要同步响应，或者如果它自身需要接手同步响应，那么REST也许就是你所需要的方式。如果一个企业要求系统的消息流能够被容易地监控和审计，或者考虑到能够在一个中心位置修改和查看消息流，那么可以考虑管道方式。然而，基于异步消息传递系统松耦合与高伸缩的性质能够很好地适应微服务的的整体思想。通常情况下，尽管设计与实现上存在一些重大的障碍，但是当你决定在基于微服务的系统中使用一种默认的通信机制，基于事件的消息传递方式是一个不错的选择。

本文为翻译文章，阅读原文，请点击左下角阅读原文链接。