我报名参与金石方案1期应战——分割10万奖池，这是我的第4篇文章，点击查看活动详情
前语
在运用微服务架构时，咱们会将一个大的单运用拆分红多个独立自治的小服务，如果在没有服务发现的情况下，咱们要想在服务之间进行通讯，咱们只能运用硬编码的方法，将需求通讯的服务装备信息写在程序中，这样可能会导致一系列的问题，如服务供给方的网络发生了变化，服务的调用方如不及时修正将会影响运用，无法动态收缩和扩容等。为了处理这个问题，本文将从服务发现的完成原理、常用的服务发现结构等方面进行简要介绍。需求的朋友能够参考以下内容，希望对我们有协助。
什么是服务注册与发现
望文生义，服务注册与发现首要包含两部分：服务注册与服务发现。
- 服务注册：是指服务实例发动时将本身信息注册到服务注册与发现中心，并在运行时通过心跳等方法向服务注册与发现中心报告本身服务状况；
- 服务发现：是指服务实例向服务注册与发现中心获取其他服务实例信息，用于进行后续的远程调用。
注册中心首要有三种人物：
- 服务供给者（RPC Server） ：在发动时，向 Registry 注册本身服务，并向 Registry 定时发送心跳报告存活状况。
- 服务消费者（RPC Client） ：在发动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立衔接。
- 服务注册中心（Registry） ：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会改写本地 内存中缓存的服务节点列表。
服务注册与发现中心的责任
- 管理当时注册到服务注册与发现中心的微服务实例元数据信息，包含服务实例的服务名、IP地址、端口号、服务状况和服务描绘信息等。
- 与注册到服务注册与发现中心的微服务实例保持心跳，定时检查注册表中的服务实例是否在线，并除掉无效服务实例信息。
- 供给服务发现才能，为调用方供给服务方的服务实例元数据。
服务注册与发现的特点
- 高可用：因为服务之间的调用信息来自于服务注册与发现中心，当它不可用时，服务之间的调用肯能无法正常进行，因而服务注册与发现一般会多实例布置，保证其高可用性和稳定性。
- 便利装备：本身是一个分布式，一致性的 k-v 存储系统。供给方发动的时候将本身装备信息向和谐器中进行注册，供给方下线的时候向和谐器进行反注册。
- 可监控：供给心跳机制，如果对方程序意外挂掉，没有进行反注册，和谐器也会超时除掉不可用的供给方。
常见的服务结构比照
常见的服务发现结构有Consul、Zookeeper以及Etcd。
| 名称 | Zookeeper | etcd | Consul | Nacos |
|---|---|---|---|---|
| 语言 | Java | Go | Go | Java |
| 一致性 | Paxos | Raft | Raft | Raft |
| key/value存储 | 支撑 | 支撑 | 支撑 | 支撑 |
| 多数据中心 | 不支撑 | 不支撑 | 支撑 | 支撑 |
| 健康检查 | 支撑 | 长衔接 | 衔接心跳 | |
| web界面 | 较为复杂 | 不支撑 | 支撑 | 支撑 |
| cap | cp | cp | cp | 装备中心：cp注册中心：ap |
| 运用接口 | rpc客户端 | http/grpc | http/dns | 支撑根据dns和根据rpc的服务发现 |
以上首要对Consul、Etcd和Zookeeper这三个常用的组件进行简单的比较，它们之间各有千秋，在组件选型时能够根据本身事务的需求进行选择和改造。
