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

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 本文讲的是REST真的完全适合微服务架构吗,【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。
本文讲的是REST真的完全适合微服务架构吗 【编者的话】作者根据自己的微服务经验,提出REST并不是微服务的唯一通信机制,从而介绍了微服务的几种通信机制,包括REST、管道以及基于异步消息传递。同时,作者提出了在不同的场景下可以使用不同的通信机制。

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

REST

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

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

  1. 一个外部实体发送一个存货清单更新请求到REST网关地址。
  2. 网关将请求转发给存货清单管理服务。
  3. 存货清单管理服务基于它接收到的请求更新存货清单,随后发送请求到热销补货通知服务。
  4. 接着,热销补货通知服务发送请求到订阅管理服务,要求当商品有库存时所有注册用户都需要被通知。
  5. 然后,订阅管理服务发送邮件REST请求到邮件服务,通过邮件来通知所有用户。
  6. 最后,每个服务依次相应,循环回到网关并且到达客户端。

值得注意的是,虽然通信过程是点对点的,但是固定编码服务地址是一种非常糟糕的设计选择,而且这是与微服务基本原则相悖的。取而代之,可以使用服务发现机制,例如 Eureka Consul ,这些机制让各服务将它们的API注册到中央服务器,然后客户端访问中央服务器的特定API地址。

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

阻塞

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

耦合度和单一职责

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

当服务失效

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

管道

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

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

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

异步消息传送

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

根据这种方式,库存通知子系统可以被重构,如下所示:
mq-flow.png

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

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

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

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

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

设计/实现/配置的困难

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

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

异步消息的本性

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

信息流的可见性

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

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

延伸阅读

Netflix OSS  - Eureka和Hystrix的主页
Consul
Antifragile Software  - 作者为Russ Miles
Event Sourcing  - 作者为Martin Fowler
Building and Deploying Microservices with Event Sourcing, CQRS and Docker  - 作者为Chris Richardson

原文链接:IS REST BEST IN A MICROSERVICES ARCHITECTURE?(翻译:肖远昊)

原文发布时间为:2016-01-10
本文作者:time_qiao
本文来自云栖社区合作伙伴DockerOne,了解相关信息可以关注DockerOne。
原文标题:REST真的完全适合微服务架构吗?
目录
相关文章
|
3天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。
|
3天前
|
监控 持续交付 API
构建高效可扩展的微服务架构
在当今快速迭代和竞争激烈的软件市场中,构建一个高效、可扩展且易于维护的后端系统变得尤为重要。微服务架构作为一种流行的分布式系统设计方式,允许开发者将应用程序划分为一系列小型、自治的服务,每个服务负责执行特定的业务功能。本文将探讨如何利用现代技术栈搭建一个符合这些要求的微服务架构,并讨论其潜在的挑战与解决方案。我们将涵盖服务划分策略、容器化、服务发现、API网关、持续集成/持续部署(CI/CD)以及监控和日志管理等关键主题,以帮助读者构建出既可靠又灵活的后端系统。
|
5天前
|
监控 Kubernetes 持续交付
构建高效可扩展的微服务架构:后端开发实践指南
在数字化转型的浪潮中,企业对软件系统的要求日益提高,追求快速响应市场变化、持续交付价值成为核心竞争力。微服务架构以其灵活性、模块化和独立部署的特点,成为解决复杂系统问题的有效途径。本文将深入探讨如何构建一个高效且可扩展的微服务架构,涵盖关键设计原则、技术选型及实践案例,为后端开发者提供一条清晰的指导路线,帮助其在不断变化的技术环境中保持竞争力。
90 3
|
3天前
|
消息中间件 敏捷开发 运维
构建高效可靠的微服务架构:策略与实践
随着现代软件开发的复杂性增加,微服务架构逐渐成为企业解决大型应用系统分解、敏捷开发和持续部署问题的有效手段。本文深入探讨了构建一个高效且可靠的微服务架构的关键策略,包括服务的合理划分、通信机制的选择、数据一致性保障以及容错处理。通过分析这些策略在具体案例中的应用,我们旨在为开发者提供一套可行的微服务设计及实施指南。
|
3天前
|
监控 数据管理 API
构建高效微服务架构:后端开发的新趋势
在现代软件开发领域,随着业务需求的不断复杂化以及敏捷迭代的加速,传统的单体应用架构逐渐暴露出其局限性。微服务架构作为一种新的解决方案,以其高度模块化、独立部署和可扩展性,正成为后端开发领域的新趋势。本文将探讨微服务架构的核心概念,分析其优势与面临的挑战,并提供实施高效微服务的策略和最佳实践,帮助读者理解如何利用这一架构模式提升系统的可靠性、灵活性和可维护性。
90 5
|
6天前
|
人工智能 运维 监控
构建高性能微服务架构:现代后端开发的挑战与策略构建高效自动化运维系统的关键策略
【2月更文挑战第30天】 随着企业应用的复杂性增加,传统的单体应用架构已经难以满足快速迭代和高可用性的需求。微服务架构作为解决方案,以其服务的细粒度、独立性和弹性而受到青睐。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、常用的技术栈选择以及性能优化的最佳实践。我们将分析微服务在处理分布式事务、数据一致性以及服务发现等方面的挑战,并提出相应的解决策略。通过实例分析和案例研究,我们的目标是为后端开发人员提供一套实用的指南,帮助他们构建出既能快速响应市场变化,又能保持高效率和稳定性的微服务系统。 【2月更文挑战第30天】随着信息技术的飞速发展,企业对于信息系统的稳定性和效率要求
|
3天前
|
API 持续交付 开发者
构建高效微服务架构:后端开发的新范式
在数字化转型和技术迭代的浪潮中,微服务架构以其灵活性、可扩展性和独立性成为现代后端开发的重要趋势。本文深入探讨了构建高效微服务架构的关键要素,包括服务划分策略、容器化部署、API网关设计以及持续集成与持续部署(CI/CD)的实践。通过分析这些组件和流程,我们旨在为后端开发者提供一套实用的指南,帮助他们构建和维护一个高性能、可靠的微服务系统。
20 5
|
4天前
|
消息中间件 缓存 API
微服务架构下的API网关性能优化实践
在现代的软件开发中,微服务架构因其灵活性和可扩展性被广泛采用。随着服务的细分与增多,API网关作为微服务架构中的关键组件,承担着请求路由、负载均衡、权限校验等重要职责。然而,随着流量的增长和业务复杂度的提升,API网关很容易成为性能瓶颈。本文将深入探讨API网关在微服务环境中的性能优化策略,包括缓存机制、连接池管理、异步处理等方面的具体实现,旨在为开发者提供实用的性能提升指导。
|
5天前
|
Prometheus 监控 API
构建高效微服务架构:后端开发的新趋势
随着现代软件开发的复杂性增加,传统的单体应用已难以满足快速迭代与灵活部署的需求。微服务架构作为解决这一问题的有效手段,其设计理念和实践方法已成为后端开发领域的热门话题。本文将探讨如何构建一个高效的微服务架构,涵盖设计原则、技术选型、以及实践中可能遇到的挑战,为后端开发者提供一套可行的参考方案。
12 2
|
6天前
|
缓存 负载均衡 监控
构建高效微服务架构:API网关的作用与实践
【2月更文挑战第31天】 在当今的软件开发领域,微服务架构已成为实现系统高度模块化和易于扩展的首选方法。然而,随着微服务数量的增加,确保通信效率和管理一致性变得尤为重要。本文将探讨API网关在微服务架构中的核心角色,包括其在请求路由、安全性、负载均衡以及聚合功能方面的重要性。我们将通过具体案例分析,展示如何利用API网关优化后端服务,并讨论实施过程中的最佳实践和常见挑战。

相关产品

  • 微服务引擎
  • 服务网格