服务注册/服务发现-Eureka
- [1. 背景](#1. 背景)
-
- [1.1 问题描述](#1.1 问题描述)
- [1.2 解决思路](#1.2 解决思路)
- [1.3 什么是注册中⼼](#1.3 什么是注册中⼼)
- [1.4 CAP理论](#1.4 CAP理论)
- [1.5 常⻅的注册中⼼](#1.5 常⻅的注册中⼼)
- [2. Eureka 介绍](#2. Eureka 介绍)
- [3. 搭建Eureka Server](#3. 搭建Eureka Server)
1. 背景
1.1 问题描述
上个章节的例⼦中可以看到, 远程调⽤时, 我们的URL是写死的
java
String url = "http://127.0.0.1:9090/product/"+ orderInfo.getProductId();当更换机器, 或者新增机器时, 这个URL就需要跟着变更, 就需要去通知所有的相关服务去修改. 随之⽽来的就是各个项⽬的配置⽂件反复更新, 各个项⽬的频繁部署. 这种没有具体意义, 但⼜不得不做的⼯作, 会让⼈⾮常痛苦
1.2 解决思路
试想⽣活中的场景:
我们⽣活中, 避免不了和各个机构(医院, 学校, 政府部⻔等)打交道, 就需要保存各个机构的电话号码. 如果机构换了电话号码, 就需要通知各个使⽤⽅, 但是这些机构的使⽤⽅群体是巨⼤的, 没办法做到⼀⼀通知, 怎么处理呢?
机构电话如果发⽣变化, 通知114. ⽤⼾需要联系机构时, 先打114查询电话, 然后再联系各个机构.114查号台的作⽤主要有两个:
号码注册: 服务⽅把电话上报给114
号码查询: 使⽤⽅通过114可以查到对应的号码
同样的, 微服务开发时, 也可以采⽤类似的⽅案.
服务启动/变更时, 向注册中⼼报道. 注册中⼼记录应⽤和IP的关系
调⽤⽅调⽤时, 先去注册中⼼获取服务⽅的IP, 再去服务⽅进⾏调⽤.
1.3 什么是注册中⼼
在最初的架构体系中, 集群的概念还不那么流⾏, 且机器数量也⽐较少, 此时直接使⽤DNS+Nginx就可以满⾜⼏乎所有服务的发现. 相关的注册信息直接配置在Nginx. 但是随着微服务的流⾏与流量的激增,机器规模逐渐变⼤, 并且机器会有频繁的上下线⾏为, 这种时候需要运维⼿动地去维护这个配置信息是⼀个很⿇烦的操作. 所以开发者们开始希望有这么⼀个东西, 它能维护⼀个服务列表, 哪个机器上线了,哪个机器宕机了, 这些信息都会⾃动更新到服务列表上, 客⼾端拿到这个列表, 直接进⾏服务调⽤即可.这个就是注册中⼼
注册中⼼主要有三种⻆⾊：
- 服务提供者(Server)：⼀次业务中, 被其它微服务调⽤的服务. 也就是提供接⼝给其它微服务.
- 服务消费者(Client)：⼀次业务中, 调⽤其它微服务的服务. 也就是调⽤其它微服务提供的接⼝.
- 服务注册中⼼(Registry): ⽤于保存Server 的注册信息, 当Server 节点发⽣变更时, Registry 会同步变更. 服务与注册中⼼使⽤⼀定机制通信, 如果注册中⼼与某服务⻓时间⽆法通信, 就会注销该实例
他们之间的关系以及⼯作内容, 可以通过两个概念来描述:
服务注册：服务提供者在启动时, 向 Registry 注册⾃⾝服务, 并向 Registry 定期发送⼼跳汇报存活状态
服务发现： 服务消费者从注册中⼼查询服务提供者的地址，并通过该地址调⽤服务提供者的接⼝. 服务发现的⼀个重要作⽤就是提供给服务消费者⼀个可⽤的服务列表.
1.4 CAP理论
谈到注册中⼼, 就避不开CAP理论
CAP 理论是分布式系统设计中最基础, 也是最为关键的理论.
- ⼀致性(Consistency) CAP理论中的⼀致性, 指的是强⼀致性. 所有节点在同⼀时间具有相同的数据
- 可⽤性(Availability) 保证每个请求都有响应(响应结果可能不对)
- 分区容错性(Partition Tolerance) 当出现⽹络分区后，系统仍然能够对外提供服务
CAP 理论告诉我们: ⼀个分布式系统不可能同时满⾜数据⼀致性, 服务可⽤性和分区容错性这三个基本需求, 最多只能同时满⾜其中的两个.
在分布式系统中, 系统间的⽹络不能100%保证健康, 服务⼜必须对外保证服务. 因此Partition Tolerance不可避免. 那就只能在C和A中选择⼀个. 也就是CP或者AP架构
正常情况:
⽹络异常:
- CP架构: 为了保证分布式系统对外的数据⼀致性, 于是选择不返回任何数据
- AP架构: 为了保证分布式系统的可⽤性, 节点2返回V0版本的数据(即使这个数据不正确)
1.5 常⻅的注册中⼼
-
Zookeeper
Zookeeper的官⽅并没有说它是⼀个注册中⼼, 但是国内Java体系, ⼤部分的集群环境都是依赖Zookeeper来完成注册中⼼的功能
-
Eureka
Eureka是Netflix开发的基于REST的服务发现框架, 主要⽤于服务注册, 管理，负载均衡和服务故障转移.
官⽅声明在Eureka2.0版本停⽌维护, 不建议使⽤. 但是Eureka是SpringCloud服务注册/发现的默认实现, 所以⽬前还是有很多公司在使⽤.
-
Nacos
Nacos是Spring Cloud Alibaba架构中重要的组件, 除了服务注册, 服务发现功能之外, Nacos还⽀持配置管理, 流量管理, DNS, 动态DNS等多种特性.
CAP理论对⽐
在分布式环境中, 即使拿到⼀个错误的数据, 也胜过⽆法提供实例信息⽽造成请求失败要好(⽐如淘宝11.11, 京东618都是谨遵AP原则)
2. Eureka 介绍
Eureka是Netflix OSS套件中关于服务注册和发现的解决⽅案. Spring Cloud对Eureka进⾏了集成, 并作为优先推荐⽅案进⾏宣传, 虽然⽬前Eureka 2.0已经停⽌维护, 新的微服务架构设计中, 也不再建议使⽤, 但是⽬前依然有⼤量公司的微服务系统使⽤Eureka作为注册中⼼.
Eureka主要分为两个部分：
- Eureka Server: 作为注册中⼼Server端, 向微服务应⽤程序提供服务注册, 发现, 健康检查等能⼒.
- Eureka Client: 服务提供者, 服务启动时, 会向Eureka Server 注册⾃⼰的信息(IP,端⼝,服务信息等),Eureka Server 会存储这些信息
关于Eureka的学习, 主要包含以下三个部分:
- 搭建Eureka Server
- 将order-service, product-service 都注册到Eureka
- order-service远程调⽤时, 从Eureka中获取product-service的服务列表, 然后进⾏交互