微服务通信策略

栏目: 服务器 · 发布时间: 5年前

内容简介:在Plöd是当单体不满足需求而使用微服务时,必须把它们集成,Plöd指出,这不只是技术问题,还有其他方面的影响:

GeeCON 2018大会 上, Michael Plöd 在一场介绍 微服务之间不同的通信策略 的演讲中解释说,在从单体架构迁移到微服务架构时,暗含在单体架构中的复杂性会明确显露出来,通信挑战将呈指数级增长。

Plöd是 InnoQ 首席顾问。他首先指出,根据他的经验,团队经常把微服务视为默认架构。他强调,分布式系统是高难度的系统;如果你不需要一个分布式系统,你就不必为了微服务而力争实现那样的架构。在这种情况下,构建良好的单体通常是更好的选择。

当单体不满足需求而使用微服务时,必须把它们集成,Plöd指出,这不只是技术问题,还有其他方面的影响:

  • 团队之间需要通过沟通来解决集成问题,这可能会导致政治和治理问题。
  • 耦合:实现服务之间的松耦合非常重要,否则,你很容易最终得到一个分布式单体。
  • 质量标准:在一致性、性能、可扩展性、健壮性方面,找出真正需要的是什么,你应该尽早评估你的应用程序。
  • 技术:虽然REST很常用,但那不是唯一的通信选项。

为了帮助团队通信及管理耦合,Plöd指出,领域驱动设计(DDD)对在业务层面找出边界非常有帮助—— 有界上下文 。这些上下文彼此之间通常以不同的方式进行交互,为了描述它们之间的关系,可以使用 上下文映射 。这些交互模式包括:

  • 打开主机服务 :指定一个可供服务使用的协议,如REST;
  • 共享内核 :两个服务可以共享部分代码或定义交互的库;
  • 消费者/供应商 :一个服务是另一个服务的消费者,因此,可能会影响它的实现;
  • 防腐层 :消费者服务创建一个适配器,最小化它与之交互的另一个服务所带来的影响。

看下通信的技术方面,Plöd首先介绍了通信的一般分类—— OrchestrationChoreography 。使用Orchestration,微服务知道过程,会主动调用其他服务来完成任务。使用 Choreography ,微服务会发布一个事件,其他服务会响应事件,完成相应的动作。在Plöd看来,这是一个重要的区别,他认为,我们应该就系统首选的工作方式做架构决策。他还建议考虑宏架构和微架构,并指出,微服务并不是说团队可以随意选择他们喜欢的东西,因为那样做的话,你最终会陷入完全的混乱。相反,他建议采用一种有规则的宏架构,所有团队都必须遵守这些规则。在微架构中,团队有更大的自由,可以选择他们自己的实现风格。

让我们看下通信的技术选项,Plöd指出了四种类型:

  • RESTful资源
  • 消息传递
  • 领域事件
  • 订阅

虽然 REST 如今已经广为人知,但根据Plöd的经验, 只有很少团队很好地实现了 ,尤其是在超媒体和多表示形式方面。他指出,实现一个RESTful资源调用非常简单,但是,实现一个可以在微服务环境中正常运行的健壮调用要困难许多。以下是需要知道的一些陷阱和挑战:

  • 服务发现:一种服务用来发现它与之通信的服务的URL的方式。
  • 弹性:包括如何处理错误和宕机。服务的优雅退化非常重要,可以避免异常服务使整个应用程序性能下降。
  • 负载均衡:可以处理不断增长的负载。有许多不同的实现方法,使用哪种方法取决于应用程序的运行环境。

下一个选项是消息传递,微服务发送和消费消息,通常是通过一个消息代理。下面描述的这些有关REST的挑战不是很切题:

  • 服务发现已经没意义,因为服务仅知道消息系统。
  • 弹性主要由消息系统处理。主要的风险是延迟因为错误或宕机增加。
  • 负载均衡是通过向上扩展消息系统或增加消息消费者数量来实现的。

Plöd的第三个选项是领域事件。它们表示过去在业务层面上已经发生的事实。使用它们进行通信会得到 事件驱动的微服务 ,现如今,这是一种非常流行的架构风格。当使用事件通信时,对于事件中的有效载荷,他介绍了几个可选方案:

  • 满负载模式:事件中包含处理事件所需的所有数据,例如关于客户的所有数据。这可以简化消费者的工作,但也意味着更紧密的耦合。
  • REST URL:只有一个指向代表事件的资源的URL。
  • 空模式:仅包含关于事件本身的数据。消费者必须通过其他方式找到它需要的数据。
  • 混合模式:比如,有少量的数据和一个用于找到其他数据的URL。在大多数情况下,这都是Plöd首选的方式。

Plöd最后的选项是使用 Atom Feeds 组合REST和事件。现在,服务会利用事件发布推送信息,消费者订阅并异步读取。在大多数环境中,使用HTTP都非常容易通信,而且可以利用像 ETags最后修改时间 、分页和链接这样的特性。另外一个好处是,服务发布推送信息,可以从消费者完全解耦。推送消息的读取完全是由消费者按照它们认为恰当的方式进行的,而且,已消费事件的跟踪也是由消费者完成的。

为了提供推送消息,事件必须持久化,这就轮到 事件源 登场了。我们可以使用这些事件作为我们主要的持久化模型,这还使得我们可以使用 CQRS 来获得视图,这些视图是经过优化的事件读取模型。Plöd特别指出,CQRS和事件源只是系统特定部分的解决方案,而不代表系统中随处都在使用的架构。

要了解更多有关集成的信息,Plöd强烈推荐由Gregor Hophe和Bobby Wolf所著的 Enterprise Integration Patterns 一书。

查看英文原文: Strategies for Microservices Communication


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

JavaScript Patterns

JavaScript Patterns

Stoyan Stefanov / O'Reilly Media, Inc. / 2010-09-21 / USD 29.99

What's the best approach for developing an application with JavaScript? This book helps you answer that question with numerous JavaScript coding patterns and best practices. If you're an experienced d......一起来看看 《JavaScript Patterns》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

MD5 加密
MD5 加密

MD5 加密工具

html转js在线工具
html转js在线工具

html转js在线工具