我是相当新的微服务...微服务：服务发现/断路器事件驱动的架构
我已经采取的兴趣更多地了解两个主要模式，如service discovery和circuit breaker我已经对这些如何实施进行了研究。
作为Java开发人员，我使用Spring Boot。据我所知，如果微服务通过HTTP进行通信，这些模式是有用的。
一个我最近看到的主题是事件驱动的架构的重要性，这使得利用事件消息总线的那个服务将使用将消息发送到其他服务，订阅总线 和过程消息。
考虑到这种事件驱动的特性，考虑到这些通常适用于通过HTTP进行通信的服务，如何实现/实现服务发现和断路器？
Spring Boot与Spring Cloud很好地结合在一起。 Spring Cloud提供Eureka（用于服务发现）以及Hystrix（用于断路器模式）。此外，春季云流，以便提供事件驱动模式
非常容易使用与Spring引导
从我的理解，如果微服务通过HTTP进行通信，这些模式是有益的。
通信是HTTP并不重要。断路器对于防止在使用通信方式的架构中更可能发生的级联故障很有用。 事件驱动体系结构通常是异步因此级联失败的可能性较小。
服务发现用于微服务彼此发现，但在事件驱动体系结构中，微服务仅与消息传递基础结构（即事件源中的事件存储）通信，因此仅可在基础架构级别使用可发现性。
I. circuit breaker和service discovery是模式。当我们说Pattern时，它们可以用任何编程语言来实现。 'HTTP'协议用于传输数据。
circuit breaker可以在Java中实现。您可以在github上找到许多实现（当然，具有不同的功能和模式解释）。
一些知名的，对目的的实现内置的是：
Hysterix from NetflixOSS对于使用Hysterix：您可以按照春指南 - Spring Circuit Breaker
Apache Polygene - 其中有例如JMX断路器
二，关于，
鉴于这种事件驱动的本质，如何能服务发现和电路断路器 实现/实施，因为这些通常是 适用于通过HTTP通信服务？
看来您需要更多关于微服务交互主题的研究。 微服务交互有两种可能。你必须选择一个。你可以/不应该混用两者。
编排：具有智能控制器，它能将事件过程的交互方式。请注意这里代表业务流程的'流程'一词。编排风格在旧的SOA实现中也是首选。
编排：一种交互风格，允许进程订阅事件并独立处理它们，或者通过与其他进程集成而不需要中央控制器。
随着舞美，两个或两个以上微服务可以协调他们的活动和流程，以共享信息和值：
这些主题下 Orchestration vs. Choreography
需要服务发现大大覆盖。
但是，这些微服务可能不知道彼此的存在，即没有配置或编码到其中的依赖端点的硬编码或服务引用。为什么我们这样做，是为了避免服务之间的任何耦合。那么，问题仍然是如果一项服务需要找到另一个服务的端点？这是使用service discovery机制的地方。
另一个角度是，通过容器等微服务部署，微服务端点甚至不会被绑定到任何主机等[由于容器的旋转和旋转]。因此，对于这种情况，我们需要“服务发现”机制。
因此，在服务发现机制中，集中式服务发现工具可帮助服务注册自己并通过DNS或HTTP接口发现其他服务。
服务发现可以用 2. Client Side service discovery
领事ETCD，动物园管理员来实现一些服务发现空间中的关键工具的名称。
我相信在这个问题上存在误解，因为您认为事件驱动的体系结构无法在HTTP之上实现。
事件驱动的体系结构可以以许多不同的方式实现，并且（当体系结构是分布式系统时），可以在许多不同的协议之上实现。
它也可以使用消息代理（即Kafka，RabbitMQ，ActiveMQ等）来实现。但是，这只是一个选择，当然不是唯一的方法。
例如，重要著作Building Microservices由山姆·纽曼，在第4章：集成，基于事件实现异步协作下称：
“另一种方法是尝试使用HTTP作为传播的一种方式 事件。 ATOM是一个符合REST的规范，它定义了用于发布资源提要的语义 （等等）。许多客户端存在 库，这些库允许我们创建和使用这些供稿。所以 当我们的客户服务发生变化时，我们的客户服务可能会将活动发布到这样的订阅源。我们的消费者只是轮询饲料， 寻找变化。一方面，我们可以重复使用现有的ATOM规范和任何相关库的事实很有用，我们知道HTTP处理能够很好地扩展。然而，HTTP不是 擅长于低延迟（一些消息代理商擅长），我们仍然需要处理消费者需要跟踪他们看到的消息并管理他们自己的轮询时间表的事实。
我看到人们度过一个时代实现你得到的开箱即用适当的消息 经纪人才能ATOM工作了一段用例的 行为越来越多。例如，竞争消费者模式描述了一种方法，通过这种方法，您可以调用多个工人实例来竞争消息，这可以很好地工作来扩大工作人员的数量，以处理独立的 作业列表。但是，我们希望避免两个或更多工作人员看到相同消息的情况，因为我们最终会完成比 需要更多的相同任务。使用消息代理，标准队列将处理这个问题。 通过ATOM，我们现在需要管理我们自己在所有 工作人员之间的共享状态，以尽量减少复制工作的机会。如果您的 已经拥有可用的良好弹性消息代理，请考虑使用它来处理发布和订阅事件。但是 如果你还没有一个，请给ATOM一看，但要注意沉没成本谬误。如果您发现自己希望获得消息代理提供的越来越多的支持，那么在某个时候，您可能想要改变您的方法 。”
同样的，如果你的设计采用事件驱动架构的消息代理，然后我不知道是否需要一个断路器，因为在这种情况下，消费应用控制的速率事件消息正在从队列中消耗。生产者应用程序可以按照自己的速度发布事件消息，消费者应用程序可以添加尽可能多的竞争消费者，以便跟上这一步伐。如果服务器应用程序关闭，则客户端应用程序仍然可以继续使用队列中剩余的任何消息，并且一旦队列为空，它们将继续等待更多消息到达。但是这并没有给生产者应用带来任何负担。在这种情况下，生产者和消费者应用程序是分开的，断路器在其他情况下所做的所有工作都将由消息代理应用程序解决。
可以说服务发现功能有些类似。由于生产者和消费者之间并不直接对话，而只能通过消息中介，所以你需要发现的唯一服务就是消息中介。