欢迎使用Markdown编辑器

flybirding10011

已于 2023-01-03 16:47:54 修改

阅读量247

点赞数

分类专栏：发布测测试文章标签：编辑器前端

于 2022-11-30 16:12:38 首次发布

本文链接：https://blog.csdn.net/cpongo1/article/details/128117198

版权

发布测测试专栏收录该内容

9 篇文章 ¥0.01 ¥39.90

订阅专栏

超级会员免费看

本文探讨了服务发现的历史、数据模型、数据一致性、负载均衡和健康检查在服务注册中心中的实现，以Eureka、Zookeeper和Consul为例，阐述了各组件的特点和选择策略。

摘要由CSDN通过智能技术生成

一、前言
服务发现是⼀个古老的话题，当应用开始脱离单机运行和访问时，服务发现就诞生了。目前的网络架构是每个主机都有⼀个独立的 IP 地址，那么服务发现基本上都是通过某种方式获取到服务所部署的 IP 地址。DNS 协议是最早将⼀个网络名称翻译为网络 IP 的协议，在最初的架构选型中，DNS+LVS+Nginx 基本可以满足所有的 RESTful 服务的发现，此时服务的 IP 列表通常配置在 nginx或者 LVS。后来出现了 RPC 服务，服务的上下线更加频繁，人们开始寻求⼀种能够支持动态上下线并且推送 IP 列表变化的注册中心产品。

互联网软件行业普遍热捧开源产品，因为开源产品代码透明、可以参与共建、有社区进行交流和学习，当然更重要的是它们是免费的。个人开发者或者中小型公司往往会将开源产品作为选型首选。Zookeeper 是⼀款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长⼀段时间里，它是国人在提起 RPC 服务注册中心时心里想到的唯⼀选择，这很大程度上与 Dubbo 在中国的普及程度有关。Consul 和 Eureka 都出现于 2014 年，Consul 在设计上把很多分布式服务治理上要用到的功能都包含在内，可以支持服务注册、健康检查、配置管理、Service Mesh 等。而 Eureka则借着微服务概念的流行，与 SpringCloud 生态的深度结合，也获取了大量的用户。去年开源的Nacos，则携带着阿里巴巴大