博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
微服务通信策略
阅读量:6334 次
发布时间:2019-06-22

本文共 2036 字,大约阅读时间需要 6 分钟。

在上,在一场介绍的演讲中解释说,在从单体架构迁移到微服务架构时,暗含在单体架构中的复杂性会明确显露出来,通信挑战将呈指数级增长。

\\

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

\\

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

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

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

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

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

\\

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

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

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

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

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

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

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

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

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

\\

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

\\

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

\\

查看英文原文:

\\

转载地址:http://zwsoa.baihongyu.com/

你可能感兴趣的文章
JAVA中循环删除list中元素的方法总结
查看>>
redis 安装
查看>>
SQL some any all
查看>>
电子书下载:Programming Windows Identity Foundation
查看>>
有理想的程序员必须知道的15件事
查看>>
用于测试的字符串
查看>>
财付通和支付宝资料收集
查看>>
PHPCMS V9数据库表结构分析
查看>>
理解 IEnumerable 与 IEnumerator
查看>>
NHibernate 2.0 Beta 1 Released和一些工具
查看>>
【每天一个Linux命令】12. Linux中which命令的用法
查看>>
软件接口数据一致性机制
查看>>
微服务架构介绍和RPC框架对比
查看>>
Debian下使用OpenLDAP 管理端
查看>>
泛型排序器TComparer
查看>>
9个offer,12家公司,35场面试,从微软到谷歌,应届计算机毕业生的2012求职之路...
查看>>
创建符合标准的、有语意的HTML页面——ASP.NET 2.0 CSS Friendly Control Adapters 1.0发布...
查看>>
Adobe驳斥Flash过度耗电论 称HTML5更耗电
查看>>
No!No!No! It's not fashion!
查看>>
艰困之道中学到的经验教训
查看>>