- 内容提要
- 译者序
- 前言
- 第 1 章 欢迎迈入云世界,Spring
- 第 2 章 使用 Spring Boot 构建微服务
- 第 3 章 使用 Spring Cloud 配置服务器控制配置
- 第 4 章 服务发现
- 第 5 章 使用 Spring Cloud 和 Netflix Hystrix 的客户端弹性模式
- 第 6 章 使用 Spring Cloud 和 Zuul 进行服务路由
- 第 7 章 保护微服务
- 第 8 章 使用 Spring Cloud Stream 的事件驱动架构
- 第 9 章 使用 Spring Cloud Sleuth 和 Zipkin 进行分布式跟踪
- 第 10 章 部署微服务
- 附录 A 在桌面运行云服务
- 附录 B OAuth2 授权类型
第 4 章 服务发现
本章主要内容
- 为什么服务发现对基于云的应用程序环境很重要
- 与传统的负载均衡方法作对比,了解服务发现的优缺点
- 建立一个 Spring Netflix Eureka 服务器
- 通过 Eureka 注册一个基于 Spring Boot 的微服务
- 使用 Spring Cloud 和 Netflix 的 Ribbon 库来完成客户端负载均衡
在任何分布式架构中,都需要找到机器所在的物理地址。这个概念自分布式计算开始出现就已经存在,并且被正式称为服务发现。服务发现可以非常简单,只需要维护一个属性文件,这个属性文件包含应用程序使用的所有远程服务的地址,也可以像通用描述、发现与集成服务(Universal Description, Discovery, and Integration,UUDI)存储库一样正式(和复杂)。
服务发现对于微服务和基于云的应用程序至关重要,主要原因有两个。首先,它为应用团队提供了一种能力,可以快速地对在环境中运行的服务实例数量进行水平伸缩。通过服务发现,服务消费者能够将服务的物理位置抽象出来。由于服务消费者不知道实际服务实例的物理位置,因此可以从可用服务池中添加或移除服务实例。
这种在不影响服务消费者的情况下快速伸缩服务的能力是一个非常强大的概念,因为它驱使习惯于构建单一整体、单一租户(如一个客户)的应用程序的开发团队,远离仅考虑通过增加更大型、更好的硬件(垂直伸缩)的方法来扩大服务,而是通过更强大的方法——添加更多服务器(水平伸缩)来实现扩大。
单体架构通常会驱使开发团队在过度购买处理能力的道路上越走越远。处理能力的增长以跳跃式和峰值的形式体现出来,很少按照平稳路径的形式增长。微服务允许开发人员对服务实例进行伸缩。服务发现有助于抽象出这些服务部署,使它们远离服务消费者。
服务发现的第二个好处是,它有助于提高应用程序的弹性。当微服务实例变得不健康或不可用时,大多数服务发现引擎将从内部可用服务列表中移除该实例。由于服务发现引擎会在路由服务时绕过不可用服务,因此能够使不可用服务造成的损害最小。
我们已经了解了服务发现的好处,但是它有什么大不了的呢?难道我们就不能使用诸如域名服务(Domain Name Service,DNS)或负载均衡器等可靠的方法来帮助实现服务发现吗?接下来让我们就来讨论一下,为什么这些方法不适用于基于微服务的应用程序,特别是在云中运行的应用程序。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论