微服务专栏地址
目录
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，分布式锁等等。