1

我对微服务还很陌生...

我有兴趣了解更多关于服务发现和断路器等两种主要模式的信息，并且我对如何实现这些模式进行了研究。

作为一名 Java 开发人员，我使用的是 Spring Boot。据我了解，如果微服务通过 HTTP 进行通信，这些模式很有用。

我最近看到的主题之一是事件驱动架构的重要性，它利用事件消息总线，服务将使用该事件消息总线向其他服务发送消息，这些服务订阅总线并处理消息。

鉴于这种事件驱动的性质，鉴于这些通常适用于通过 HTTP 进行通信的服务，如何实现/实施服务发现和断路器？

4

4 回答 4

2

据我了解，如果微服务通过 HTTP 进行通信，这些模式很有用。

通信是 HTTP 无关紧要。断路器可用于防止在使用同步通信方式的架构中更可能发生的级联故障。事件驱动架构通常是异步的，因此级联故障不太可能发生。

服务发现用于微服务相互发现，但在事件驱动架构中，微服务仅与消息传递基础架构（即事件源中的事件存储）通信，因此可发现性只能在基础架构级别使用。

于 2017-10-07T05:28:16.893 回答
1

I.circuit breaker和service discovery是模式。当我们说模式时，它们可以用任何编程语言来实现。“HTTP”协议用于数据传输。

circuit breaker可以在Java中实现。您可以在 github 上找到许多实现（当然，具有不同的功能和模式解释）。

一些著名的、为目​​的而构建的实现是：

  1. 来自 NetflixOSS 的 Hysterix使用 Hysterix：您可以遵循 Spring Guide - Spring Circuit Breaker

  2. Apache Polygene - 有 JMX 断路器示例

  3. 弹性4j

二、关于，

鉴于这种事件驱动的性质，如何实现/实现服务发现和断路器，因为它们通常适用于通过 HTTP 进行通信的服务？

看来您需要对微服务交互主题进行更多研究。有两种方式可以实现微服务交互。你必须选择一个而不是另一个。您可以/不应该将两者混合使用。

  1. 编排：一种交互风格，具有将事件分派给进程的智能控制器。请注意此处代表业务流程的“流程”一词。编排风格在旧的 SOA 实现中也是首选。

  2. Choreography：一种交互风格，允许进程订阅事件并独立处理它们或通过与其他进程集成而无需中央控制器。

这些主题在 Orchestration vs. Choreography下都有详细介绍

服务发现需求：

通过编排，两个或多个微服务可以协调它们的活动和流程以共享信息和价值。

但是，这些微服务可能不知道彼此的存在，即没有硬编码或配置或编码到它们中的依赖端点的服务引用。我们这样做的原因是为了避免服务之间的任何形式的耦合。所以，问题仍然存在，如果需要，一个服务如何找到另一个服务的端点？这是service discovery使用机制的地方。

另一种观点是，通过使用容器等部署微服务，微服务端点甚至不会绑定到任何主机等[由于容器的启动和停止]。因此，对于这种情况，我们也需要“服务发现”机制。

因此，在服务发现机制中，集中式服务发现工具帮助服务注册自己并通过 DNS 或 HTTP 接口发现其他服务。

服务发现可以通过 1.服务器端服务发现 2.客户端服务发现来实现

Consul、etcd、zookeeper 是服务发现空间中的一些关键工具名称。

于 2017-10-07T09:48:09.913 回答
0

我相信这个问题存在误解，因为您认为事件驱动的架构不能在 HTTP 之上实现。

事件驱动的架构可以以许多不同的方式实现，并且（当架构是分布式系统时），在许多不同的协议之上。

它也可以按照您的建议使用消息代理（即 Kafka、RabbitMQ、ActiveMQ 等）来实现。然而，这只是一种选择，当然不是唯一的方法。

例如，Sam Newman的开创性著作《构建微服务》，在第 4 章：集成，在实现基于事件的异步协作下说：

“另一种方法是尝试使用 HTTP 作为传播事件的方式。ATOM 是一种符合 REST 的规范，它定义了用于发布资源提要的语义（除其他外）。存在许多允许我们创建和使用这些提要的客户端库。因此，当我们的客户服务发生变化时，我们的客户服务可以将事件发布到此类提要。我们的消费者只是轮询提要，寻找变化。一方面，我们可以重用现有的 ATOM 规范和任何相关的库这一事实很有用，而且我们知道 HTTP 处理的可伸缩性非常好。但是，HTTP 不擅长低延迟（某些消息代理擅长于此），我们仍然需要处理消费者需要跟踪他们看到的消息并管理自己的轮询时间表的事实。

我已经看到人们花了很长时间来实现越来越多的行为，这些行为是通过适当的消息代理使 ATOM 适用于某些用例而开箱即用的。例如，竞争消费者模式描述了一种方法，您可以通过该方法启动多个工作实例来竞争消息，这对于扩大工作人员的数量以处理独立作业列表非常有效。但是，我们希望避免两个或多个工作人员看到相同消息的情况，因为我们最终会比我们需要的更多地执行相同的任务。使用消息代理，标准队列将处理此问题。使用 ATOM，我们现在需要在所有工作人员之间管理我们自己的共享状态，以尝试减少重复工作的机会。如果您已经有一个好的、有弹性的消息代理可供您使用，考虑使用它来处理发布和订阅事件。但是，如果您还没有，请看一下 ATOM，但要注意沉没成本谬误。如果您发现自己越来越需要消息代理为您提供的支持，那么在某个时候您可能想要改变您的方法。”</p>

同样，如果您的设计为事件驱动架构使用消息代理，那么我不确定是否需要断路器，因为在这种情况下，消费者应用程序控制从队列中消耗事件消息的速率。生产者应用程序可以按照自己的节奏发布事件消息，而消费者应用程序可以添加任意数量的竞争消费者以跟上该节奏。如果服务器应用程序关闭，客户端应用程序仍然可以继续使用队列中的任何剩余消息，并且一旦队列为空，它们将继续等待更多消息到达。但这不会给生产者应用程序带来任何负担。在这种情况下，生产者和消费者应用程序是解耦的，

服务发现功能可以说有点类似。由于生产者和消费者不直接相互通信，而只是通过消息代理，那么您需要发现的唯一服务就是消息代理。

于 2017-12-11T20:32:37.350 回答
0

Spring Boot 与Spring Cloud很好地集成。Spring Cloud 提供了 Eureka（用于服务发现）以及 Hystrix（用于断路器模式）。此外，Spring Cloud Stream 提供事件驱动模式

非常容易与 Spring Boot 一起使用

于 2017-10-07T01:39:43.003 回答