四：对微服务所需的服务发现的理解

微服务专栏地址

　　专栏：微服务
　　微服务系列总目录

目录

1. 简介

　　从问题的角度去思考、理解服务发现，后续demo代码编写或者探究原理时反过来验证对服务发现的理解。问题主要包括：

1. 什么是服务发现？
2. 为什么需要服务发现？
3. 服务发现具备哪些关键特性？
4. 服务发现的经典机制有哪些？
5. 有什么解决方案？
6. 实际生产中如何选择？

2. 什么是服务发现？

　　服务发现提供了一种协调机制，方便服务的发布和查找，是支撑大规模SOA的核心服务。在一定规模的应用系统中，服务的数量可能是几十个，上百个，服务中有消费者，生产者，那么消费者如何发现消费者？这个时候需要提供一种机制来解决这个问题。

3. 为什么需要服务发现？

　　当实现一个或者一组服务时，服务调用方需要知道服务实例的访问信息，如IP、端口、地址等。如果都是人工去为每个服务实例配置访问信息，效率、可靠性、稳定性都是不能保证的，特别是在基于云的微服务体系中，服务实例被动态地分配访问信息，并且这些信息也可能会随着资源的调整有变化。
　　所以需要一套完善的服务发现机制来帮助我们去实现服务的注册、发现自动化，实现不使用硬编码的方式，只需要服务名就可以使用服务。并且可以动态的实现服务的注册、销毁以及查找。
　　

4. 服务发现具备哪些关键特性？

• 高可用：服务发现是SOA或者微服务体系中的核心功能，服务发现不可用往往意味着应用不可用，这是无法接受的
• 提供服务注册、销毁：保证服务的有效性以及可用性
• 提供服务查找：服务实例是为客户端或者调用者提供服务的，必须能让客户端通过一定规则查找到其需要访问的服务

5. 服务发现的经典机制有哪些？

经典机制：传统LB模式、进程内LB模式、独立主机LB模式

5.1 传统LB模式

5.1.1 工作机制是什么样的

1. 服务上线，为其配置域名
2. 运维将服务信息配置到LB中
3. 消费者访问LB，LB调用服务并返回结果给消费者

5.1.2 有什么优缺点

优点：

• 实现方式简单
• 业界普遍在使用

缺点：

• 运维难度大：新增或者撤销服务时，需要运维介入更改LB配置信息
• 存在单点故障：一台F5或者nginx作为核心，若挂了则整体都不能正常工作
• 需要硬件配合，成本高：若使用F5做LB，就是外购硬件
• 性能有损耗：客户端调用服务端是需要穿透LB的

5.2 进程内LB模式

5.2.1 工作机制是什么样的

1. 服务实例自动注册到服务注册中心
2. 定期发送心跳，反映服务可用
3. 服务消费者客户端带有服务发现和负载功能
4. LB定期同步服务注册表中服务
5. 服务消费者通过LB调用服务实例

5.2.2 有什么优缺点

优点：

• 高可用性：每个客户端一个LB，不存在单点故障问题
• 服务发现无需运维介入：通过代码的形式实现服务的注册、发现，不需要运维额外配置信息
• 高性能：客户端直接通过LB获取服务实例访问地址信息，进而直接调用服务实例提供的服务接口，无中间过程损耗性能

缺点：

• 多语言支持成本高：客户端代码与LB强耦合，需要为每种接入语言实现客户端代码与LB代码
• 升级成本高：客户端代码与LB强耦合，升级任何一个都必须要两者同时考虑

5.3 独立主机LB模式

5.3.1 工作机制是什么样的

1. 前面两种方式的折中
2. 每个主机上部署一个LB
3. 服务实例自动注册到服务注册中心
4. 定期发送心跳，反映服务可用
5. LB定期同步服务注册表中服务信息
6. 消费端调用本机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，分布式锁等等。