为什么PaaS需要 服务发现框架
为什么需要服务发现框架?
PaaS上的微服务可以自动扩容,数量是动态变化的 lPaaS上的微服务实例的地址是动态分配的 l问题: l客户端怎么知道微服务在哪里?
l访问多个服务实例时,如何做到负载均衡?
怎么发现?- 客户端发现模式
特点:客户端不用感知服务注册中心,也不用负责对请求实现负载均衡
l负载均衡Proxy从服务注册中心查询所有可用的服务实例 l负载均衡Proxy使用负载均衡算法选择一个实例 lAWS中的ELB, Kubernetes的Kube-proxy,Marathon l负载均衡Proxy:Nginx,HAproxy
优点:客户端不感知
缺点:负载均衡Proxy管理
怎么注册?- 自注册方式
l特点:服务端不用感知服务注册中心,也不用负责心跳
l服务管理器通过:查询部署信息,或者订阅事件,来跟踪运行服务的变化。 l当管理器发现一个新的可以服务实例,会向服务注册中心注册。并负责心跳刷新 lRegistrator开源项目,PaaS组件当前使用的服务发现框架 lKubernetes服务
优点:服务端不感知
缺点:服务管理器的管理
对比
服务注册 / 客户端 | 客户端发现 | 服务端发现 |
自注册 | 小系统,比较原始: 缺点: 客户端要改代码,感知服务注册中心 服务端要改代码,感知服务注册中心 | 优点: 客户端不用感知服务注册中心 缺点: 服务端需要感知服务注册中心 |
第三方注册 | 优点: 服务直接上线,不用感知服务注册中心。 缺点: 客户端需要感知服务中心 (例外:通过DNS感知) | 优点: 服务直接上线,不用感知服务注册中心。 客户端不用感知服务注册中心,可以快速使用服务。 |
第三方注册 + 服务端发现 是终极目标。
服务注册表实现
l服务注册中心是服务发现很重要的部分,它记录了所有服务实例网络地址信息。
l一些服务注册表例子包括:
lETCD – 是一个高可用,分布式的,一致性的,键值表,用于共享配置和服务发现。两个著名案例包括Kubernetes和Cloud Foundry。
lconsul – 是一个用于发现和配置的服务。提供了一个API允许客户端注册和发现服务。Consul可以用于健康检查来判断服务可用性。
lZooKeeper – 是一个广泛使用,为分布式应用提供高性能整合的服务。Apache ZooKeeper最初是Hadoop的子项目,现在已经变成顶级项目。
lSkyDNS – 一个较新的开源项目,原理与ETCD及consul一致,都是基于Go-raft协议,复杂度则介于两者之间
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:hwclouds.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
- 点赞
- 收藏
- 关注作者
评论(0)