Spring:从零开始的Cloud生活（零）——Eureka 服务治理

 

目录

Spring:从零开始的Cloud生活（零）——Eureka 服务治理

1.Netfilx Eurake

2.搭建服务注册中心

3.服务提供者

4.高可用注册中心

5.服务发现和消费

---

之前对于SpringCloud都是一知半解的状态，现在开始系统学习，边学边记，参考来源于《Spring Cloud微服务实战》，由于版本差异，通过各大论坛查漏补缺。

SpringCloud是一系列技术的集合，它像我们买台式电脑中的品牌机一样，模式化地整合了一系列技术供我们使用，高手可以自己选择、替换、配置电脑的组件，但是制式品牌机才是应用最为广泛的。

服务治理的主要功能就是用来实现微服务实例的自动化注册与发现，当服务之间互相调用的时候被调用方都需要一个具体的实例清单来告知调用方有哪些实例可供调用，如果系统功能比较简单，微服务模块的数量较少，还可以通过手工维护的方式来静态配置实例清单，但如果服务超过一定规模，集群的大小、服务的位置、服务命名等都有可能发生改变，再使用手工维护的方式极易发生命名冲突和各种调用错误，即使无错也会消耗大量的人力。

这里就涉及了两个概念：

• 服务注册：通常情况下，微服务的使用都会伴随一个技术——注册中心，每个服务单元都会在注册中心中注册自己的服务，将IP与端口号、版本号、通信协议等附加信息告知注册中心，注册中心会按服务名分类组织服务清单。服务中心会以监听心跳的方式去观察清单中的服务是否可用，若不可用就会剔除该服务，借此来排除故障。
• 服务发现：在服务治理框架中，两个服务之间的调用再通过指定实例地址来实现，所以调用方并不知道被调用方的具体实例地址，因此调用方需要向注册中心发起请求，获取所有服务的实例清单来完成对具体事例的访问。不过在实际使用中，由于诸多因素的限制，不会每次都向注册中心请求获得被调用方的实例地址，在不同场景中会采用不同的缓存及服务剔除机制。

举个小例子，现在有服务提供者A和B，A服务的进程运行在实例192.168.0.1:8200和192.168.0.2:8200上，B服务的进程运行在192.168.0.1:9200、192.168.0.2:9200和192.168.0.3:9200上，假设实例都在启动状态下，并向注册中心注册了自己的服务，那么注册中心就会维护下面这个清单：

服务名	位置
A	192.168.0.1:8200  192.168.0.2:8200
B	192.168.0.1:9200  192.168.0.2:9200  192.168.0.3:9200

假如服务C此时想调用服务A，就先向注册中心打报告，注册中心告诉服务C，服务A的可用实例地址为 192.168.0.1:8200  192.168.0.2:8200，然后服务C通过设置好的轮询规则选取一个来调用。

 

---

1.Netfilx Eurake

Netfilx Eurake是作为SpringCloud中的一部分来实现注册于发现，它既包含了客户端组件，也包含了服务端组件，同时二者都是使用Java语言编写，当然，Eurake提供了完备的RestfulAPI，其他语言也可兼容。

目前自己了解到的注册中心为zookeeper、consul、eurake，除此之外还有阿里的nacos，在选用配置中心的时候可以根据项目选择，这四者的主要区别如下表格：

表格来源：https://blog.csdn.net/fly910905/article/details/100023415

 

	Nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	CP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	Client Beat	TCP/HTTP/gRPC/Cmd	Keep Alive
负载均衡策略	权重/ metadata/Selector	Ribbon	Fabio	—
雪崩保护	有	有	无	无
自动注销实例	支持	支持	支持	支持
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
监听支持	支持	支持	支持	支持
多数据中心	支持	支持	支持	不支持
跨注册中心同步	支持	不支持	支持	不支持
SpringCloud集成	支持	支持	支持	支持
Dubbo集成	支持	不支持	支持	支持
K8S集成	支持	不支持	支持	不支持

 

Eruka作为SpringCloud默认的注册中心&