微服务专栏地址
目录
1. 简介
从问题的角度去思考、理解服务发现,后续demo代码编写或者探究原理时反过来验证对服务发现的理解。问题主要包括:
- 什么是服务发现?
- 为什么需要服务发现?
- 服务发现具备哪些关键特性?
- 服务发现的经典机制有哪些?
- 有什么解决方案?
- 实际生产中如何选择?
2. 什么是服务发现?
服务发现提供了一种协调机制,方便服务的发布和查找,是支撑大规模SOA的核心服务。在一定规模的应用系统中,服务的数量可能是几十个,上百个,服务中有消费者,生产者,那么消费者如何发现消费者?这个时候需要提供一种机制来解决这个问题。
3. 为什么需要服务发现?
当实现一个或者一组服务时,服务调用方需要知道服务实例的访问信息,如IP、端口、地址等。如果都是人工去为每个服务实例配置访问信息,效率、可靠性、稳定性都是不能保证的,特别是在基于云的微服务体系中,服务实例被动态地分配访问信息,并且这些信息也可能会随着资源的调整有变化。
所以需要一套完善的服务发现机制来帮助我们去实现服务的注册、发现自动化,实现不使用硬编码的方式,只需要服务名就可以使用服务。并且可以动态的实现服务的注册、销毁以及查找。
4. 服务发现具备哪些关键特性?
- 高可用:服务发现是SOA或者微服务体系中的核心功能,服务发现不可用往往意味着应用不可用,这是无法接受的
- 提供服务注册、销毁:保证服务的有效性以及可用性
- 提供服务查找:服务实例是为客户端或者调用者提供服务的,必须能让客户端通过一定规则查找到其需要访问的服务
5. 服务发现的经典机制有哪些?
经典机制:传统LB模式、进程内LB模式、独立主机LB模式
5.1 传统LB模式
5.1.1 工作机制是什么样的
- 服务上线,为其配置域名
- 运维将服务信息配置到LB中
- 消费者访问LB,LB调用服务并返回结果给消费者
5.1.2 有什么优缺点
优点:
- 实现方式简单
- 业界普遍在使用
缺点:
- 运维难度大:新增或者撤销服务时,需要运维介入更改LB配置信息
- 存在单点故障:一台F5或者nginx作为核心,若挂了则整体都不能正常工作
- 需要硬件配合,成本高:若使用F5做LB,就是外购硬件
- 性能有损耗:客户端调用服务端是需要穿透LB的
5.2 进程内LB模式
5.2.1 工作机制是什么样的
- 服务实例自动注册到服务注册中心
- 定期发送心跳,反映服务可用
- 服务消费者客户端带有服务发现和负载功能
- LB定期同步服务注册表中服务
- 服务消费者通过LB调用服务实例
5.2.2 有什么优缺点
优点:
- 高可用性:每个客户端一个LB,不存在单点故障问题
- 服务发现无需运维介入:通过代码的形式实现服务的注册、发现,不需要运维额外配置信息
- 高性能:客户端直接通过LB获取服务实例访问地址信息,进而直接调用服务实例提供的服务接口,无中间过程损耗性能
缺点:
- 多语言支持成本高:客户端代码与LB强耦合,需要为每种接入语言实现客户端代码与LB代码
- 升级成本高:客户端代码与LB强耦合,升级任何一个都必须要两者同时考虑
5.3 独立主机LB模式
5.3.1 工作机制是什么样的
- 前面两种方式的折中
- 每个主机上部署一个LB
- 服务实例自动注册到服务注册中心
- 定期发送心跳,反映服务可用
- LB定期同步服务注册表中服务信息
- 消费端调用本机LB,LB实现负载均衡和远程调用
5.3.2 有什么优缺点
优点:
- 可支持多种语言
- 无单点故障
- 性能高
缺点:
- 运维成本高:每个客户端都需要安装独立的LB,客户端与LB状态两者都要兼顾,且客户端与LB是一对一的
6. 有什么解决方案?
现在以理解核心思想为主,暂时只列出核心技术名称,后续会深入理解和对比,有兴趣的可自行查找资料。
6.1 各种方案
- Zookeeper:CP模式
- Consul:CP模式
- Eureka:进程内LB模式,AP模式
- Service Mesh:独立主机LB模式
- Etcd
6.2 方案特性对比
Feature | Consul | zookeeper | etcd | euerka |
---|---|---|---|---|
服务健康检查 | 服务状态,内存,硬盘等 | (弱)长连接,keepalive | 连接心跳 | 可配支持 |
多数据中心 | 支持 | — | — | — |
kv存储服务 | 支持 | 支持 | 支持 | — |
一致性 | raft | paxos | ||
cap | cp | cp | cp | ap |
使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http(sidecar) |
watch支持 | 全量/支持long polling | 支持 | ||
自身监控 | metrics | — | metrics | metrics |
安全 | acl | /https | acl | https支持(弱) |
spring cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
7. 实际生产中如何选择?
暂时未在实际过程中需要抉择,只能说说自己的思考
- 首先系统现状很重要,个人觉得一切都应该以实际情况出发
- 选取的微服务开发框架与各种解决方案集成的难度如何
- 各个方案的特点,如优缺点,复杂度,上手难易程度都是考量因素,当然若某一方案的一个缺点无法忍受,则一票否决也不是不可能
- 技术的热度、社区的活跃、资料的丰富层度也是一个维度,毕竟生产效率与学习成本也是必须要考虑的
- 是否有现有组件可直接来使用,如zookeeper,早已不仅仅是用来做服务发现,因其特性早已应用在多种技术、框架中,如hadoop,分布式锁等等。