我对微服务很新......
我有兴趣了解更多关于 service discovery 和 circuit breaker 这两个主要模式的内容，并且我已对如何实施这些措施。
作为Java开发人员，我使用的是Spring Boot。据我所知，如果微服务通过HTTP进行通信，这些模式很有用。
我最近看到的一个主题是事件驱动架构的重要性，它利用事件消息总线服务将用于向其他服务发送消息，订阅总线 并处理消息。
鉴于这种事件驱动的性质，如何实现/实现服务发现和断路器，因为这些通常适用于通过HTTP进行通信的服务？
答案 0 :(得分：0)
Spring Boot与Spring Cloud很好地集成。 Spring Cloud提供Eureka（用于服务发现）以及Hystrix（用于断路器模式）。此外，Spring Cloud Stream提供事件驱动模式
使用Spring Boot非常容易
答案 1 :(得分：0)
据我所知，如果微服务通过HTTP进行通信，这些模式很有用。
通信是HTTP是无关紧要的。断路器可用于防止在使用同步通信方式的架构中更可能发生的级联故障。 事件驱动的体系结构通常是异步，因此不太可能发生级联故障。
服务发现用于微服务相互发现，但在事件驱动的体系结构中，微服务仅与消息传递基础结构（即事件源中的事件存储）通信，因此可发现性只能在基础结构级别使用。 / p>
答案 2 :(得分：0)
予。 circuit breaker和service discovery是模式。当我们说Pattern时，它们可以用任何编程语言实现。 'HTTP'协议用于传输数据。
circuit breaker 可以在Java中实现。您可以在github上找到许多实现（当然，具有不同的功能和模式解释）。
一些众所周知的，专门用于实现的目的是：
Hysterix from NetflixOSS使用Hysterix：您可以关注Spring Guide - Spring Circuit Breaker
Apache Polygene - 其中包含JMX断路器的示例
II。约，
鉴于这种事件驱动的本质，如何进行服务发现和电路 鉴于这些是常见的，可以实现/实施破坏者 适用于通过HTTP进行通信的服务吗？
您似乎需要对微服务交互主题进行更多研究。 微服务交互有两种可能的方式。你必须选择一个而不是另一个。你可以/不应该两者混合。
业务流程：具有智能控制器的交互方式，可将事件分派给进程。请注意这里代表业务流程的“进程”一词。在旧的SOA实现中，业务流程样式也是首选。
编排：一种交互方式，允许进程订阅事件并独立处理或通过与其他进程集成来处理它们，而无需中央控制器。
这些主题在很大程度上涵盖在内 Orchestration vs. Choreography
需要服务发现：
通过编排，两个或更多微服务可以协调他们的活动和流程来共享信息和价值。
但是，这些微服务可能并不知道彼此的存在，即没有配置或编码到它们中的依赖端点的硬编码或服务引用。为什么我们这样做，是为了避免服务之间的任何形式的耦合。那么，问题仍然是如果需要一个服务将如何找到另一个服务的端点？这是使用service discovery机制的地方。
另一个观点是，微服务部署与容器等，微服务端点甚至不会绑定到任何主机等[由于容器的旋转和减速]。因此，对于这种情况，我们需要“服务发现”机制。
因此，在服务发现机制中，集中式服务发现工具可帮助服务自行注册并通过DNS或HTTP接口发现其他服务。
可以使用实现服务发现 1. Server-side service discovery 2. Client Side service discovery
Consul，etcd，zookeeper是服务发现领域中的一些关键工具名称。
答案 3 :(得分：0)
我认为这个问题存在误解，因为您认为事件驱动的体系结构无法在HTTP之上实现。
事件驱动的体系结构可以以许多不同的方式实现，并且（当体系结构是分布式系统的体系结构时），可以在许多不同的协议之上实现。
它可以使用消息代理（即Kafka，RabbitMQ，ActiveMQ等）实现，如您所建议的那样。但是，这只是一种选择，当然不是唯一的选择。
例如，Sam Newman在第4章：集成中的实施异步事件协作下的开创性书籍Building Microservices说：
“另一种方法是尝试使用HTTP作为传播方式 事件。 ATOM是一种符合REST的规范，用于定义语义 （除其他外）用于发布资源。很多客户 存在允许我们创建和使用这些提要的库。所以 我们的客户服务可以在何时将事件发布到此类Feed 我们的客户服务变更。我们的消费者只是调查饲料， 寻找变化。一方面，我们可以重用的事实 现有的ATOM规范和任何相关的库都很有用， 我们知道HTTP可以很好地处理扩展。但是，HTTP不是 擅长低延迟（一些消息经纪人擅长），我们仍然 需要处理消费者需要跟踪的事实 他们看到了什么消息，并管理自己的投票时间表。
我看到人们花了一个时间来实现越来越多的 使用适当的消息开箱即用的行为 代理使ATOM适用于某些用例。例如， 竞争消费者模式描述了一种提出的方法 多个工作者实例竞争消息，效果很好 用于扩大处理独立列表的工作人员数量 工作。但是，我们希望避免两个或更多工人看到的情况 同样的消息，因为我们最终会比我们更多地完成同样的任务 需要。使用消息代理，标准队列将处理此问题。 有了ATOM，我们现在需要在所有人之间管理我们自己的共享状态 工人试图减少再现努力的机会。如果你 已经有一个好的，有弹性的消息代理可供您使用， 考虑使用它来处理发布和订阅事件。但 如果你还没有，给ATOM一个看，但要注意 沉没成本的谬误。如果你发现自己想要越来越多的 支持消息代理在某个时刻为您提供的支持 想要改变你的方法。“
同样，如果您的设计使用消息代理来实现事件驱动架构，那么我不确定是否需要断路器，因为在这种情况下，消费者应用程序控制事件消息的速率从队列中消耗掉。生产者应用程序可以按照自己的节奏发布事件消息，消费者应用程序可以添加尽可能多的竞争消费者，以便跟上这一步伐。如果服务器应用程序关闭，客户端应用程序仍然可以继续使用队列中的任何剩余消息，并且一旦队列为空，它们将继续等待更多消息到达。但这并没有给生产者申请带来任何负担。在这种情况下，生产者和消费者应用程序是分离的，并且断路器在其他情况下所做的所有工作都将由消息代理应用程序解决。
服务发现功能有点类似。由于生产者和消费者不直接相互通信，而只是通过消息代理，因此您需要发现的唯一服务是消息代理。