服务发现的特点
服务与服务之间的调用通常需要在配置文件中填写好主机和端口,但是这样不易于维护,且分布式环境中不易于部署与扩容。
那么此时就需要考虑服务启动的时候自己把主机和端口以及一些其他信息注册到注册中心,这样其他服务可以从中找到它。
甚至更为简单的,注册完毕后通过 DNS 的方式来『寻址』。比如 Zookeepr 可以很好的完成这个工作,但是其中还有一个弊端就是服务的健康检查,服务注册到注册中心之后如何保证这个服务一定可用?此时就需要自己来写逻辑,当服务不可用的时候自动从注册中心下线。
服务注册发现方案
完整的服务注册与发现流程图
一个服务发现系统主要由三部分组成:
- 注册器
- 注册表
- 发现机制
第三方实现:
- zookeeper
- etcd
- consul
特点比较
Feature | euerka | Consul | zookeeper | etcd |
---|---|---|---|---|
服务健康检查 | 可配支持 | 服务状态,内存,硬盘等 | (弱)长连接,keepalive | 连接心跳 |
多数据中心 | — | 支持 | — | — |
kv 存储服务 | — | 支持 | 支持 | 支持 |
一致性 | — | raft | paxos | raft |
cap | ap | ca | cp | cp |
使用接口(多语言能力) | http(sidecar) | 支持 http 和 dns | 客户端 | http/grpc |
watch 支持 | 支持 long polling/大部分增量 | 全量/支持long polling | 支持 | 支持 long polling |
自身监控 | metrics | metrics | — | metrics |
安全 | — | acl /https | acl | https 支持(弱) |
spring cloud 集成 | 已支持 | 已支持 | 已支持 | 已支持 |
consul
支持分布式,高可用,水平扩展的服务注册和发现工具,包含以下特点:
- 服务发现:
Consul
通过DNS
或者HTTP
接口使服务注册和服务发现变的很容易 - 健康检查:健康检测使
consul
可以快速的告警在集群中的操作。和服务发现的集成,可以防止服务转发到故障的服务上面 - 键/值存储
- 多数据中心:支持多数据中心以避免单点故障,内外网的服务采用不同的端口进行监听
- 一致性算法:采用
Raft
一致性协议算法,比Paxos
算法好用 - 服务管理控制面板