【编者的话】本文讨论了两类微服务通信的方法:无代理通信和有代理通信,并总结了各自的优缺点。作者指出能明白何时使用何种方式才是最重要的,并建议初始使用无代理通信,有需要的情况下再转向成熟的代理,并可两种方式结合使用。
我确定你要构建可扩展的应用程序,对吗?谁都不会否认吧?如果是这样,你肯定听过“Cloud Native”(云原生)一词。这种方法就像天使一样,可以解决你的大多数扩展难题。那么,Cloud Native究竟是什么?
Cloud native是一种用于构建可以利用云的所有功能的应用程序的方法。
这是一种方法,不是一个框架,不需要一堆步骤。因此,有各种不同的方法可以达到云原生化,实现云计算。
Cloud native的一项关键原则是微服务。 微服务是很小的模块(有时不是那么小),它们可以彼此独立地工作。 它们可能依赖于其他微服务,甚至依赖于数据库等数据持久层。但是关键是使用松散耦合。微服务通过“通信”进行协调。
这意味着每个微服务都位于不同的代码库中,并且正在独立部署。对于在那里的DevOps员工,你有一个专用于每个微服务的独立连续交付管道。
但这使我想到了最重要的问题。
我们如何让微服务交流?
除了为微服务确定“前向兼容” API的困难之外,让它们进行交谈并不像看起来那么简单。你需要考虑多种因子,比如 吞吐量 , 延迟 和 可伸缩性 。
现在,有很多方法可以对不同的通信模式进行分类。同步(阻塞)和异步(非阻塞)被经常使用,但是我觉得这些主要是编程语言的特征。我也不考虑半双工模式还是全双工模式,因为如今,在大多数云体系结构中很容易使用其中一种(甚至两种都使用)。
因此,让我们开始吧。
简介:这种方法让微服务 直接相互通信 。你可以使用HTTP进行传统的请求-响应,也可以使用websocket(或HTTP2)进行流式传输。
两个或多个微服务之间绝对没有中间节点(路由器和负载均衡器除外)。你可以直接连接到任何服务, 只要知道它们的服务地址和它们使用的API 。
听起来很基础吧?差不多是。有一些很棒的协议,例如GRPC,可以使生活更加轻松。
优点:
缺点:
在很多情况下,无代理的设计根本行不通。你通常需要简单地发布一次消息,并让多个订阅者使用它。这是代理设计出现的地方。
简介:在这种体系结构中,所有通信都通过一组代理进行路由。代理是运行某些高级路由算法的服务器程序。
每个微服务都连接到代理。微服务可以通过相同的连接发送和接收消息。发送消息的服务称为 发布者 ,接收者称为 订阅者 。消息被发布到特定的“主题”。订阅者接收那些有关其已订阅主题的消息。
优点:
基于流的设计:这种方法也催生了流的概念。每个主题本质上都是消息流。任何用户都可以根据需要使用这些流。使用流对系统设计进行建模的可能性是无限的。
缺点:
仅了解各种架构的优缺点是不够的。重要的是要知道何时使用哪一种。
你必须始终默认使用无代理设计。如果你需要流的灵活性或需要利用消息总线的pub-sub语义,请进行切换。如果你是从头开始,那么就可以从无代理的设计开始,然后在需要时进行切换。
不必只选择一个。你可以同时使用。对于我们的工具,我们正在使用代理设计来实现RPC调用。与我们的数据库层的通信是无代理的,以提供较低的延迟。
如果你选择基于微服务的体系结构,我总是建议进行事件驱动。事件驱动的体系结构可以看作是具有高级代理的核心,该代理具有内置的大量功能(如任务调度)。
工作中使用正确的方法很重要。选择沟通方式是一项基本决定,需要格外小心。
两者都有多个选项。坚持一个完善的框架比从头开始做更有意义。有很多选择。对于消息代理,你已经拥有RabbitMQ,Nats,Kafka等,并且每个代理都是针对特定消息语义而构建的。
另一个很棒的方法是使用后端即服务,例如Space Cloud。 Space Cloud将使整个后端自动化,因此你可以专注于业务逻辑而不是云架构。
原文链接: How to make microservices communicate? (翻译:池剑锋)