1.1背景
可以看见,在更新机器时,这个url就需要跟着变更,就需要通知所有的相关服务修改.随之而来的就是各个项目的配置文件反复更新,各个项目的频繁部署.如何解决?在生活中,如果我们需要查询某个机构的电话号码,可以用过114查号台来进行.
这里的114查号台的作用主要有两个:号码注册:服务方把电话上报给114. 号码查询:使用方通过114可以查到对应的号码.同样的,微服务开发时,也可以采用类似的方案.服务启动/变更时,向注册中心报道.注册中心记录应用和IP的关系.调用方调用时,先去注册中心获取服务方的IP,再去服务方进行调用.
1.2注册中心
在最初的架构体系中, 集群的概念还不那么流⾏, 且机器数量也⽐较少, 此时直接使⽤DNS+Nginx就可 以满⾜⼏乎所有服务的发现. 相关的注册信息直接配置在Nginx. 但是随着微服务的流⾏与流量的激增, 机器规模逐渐变⼤, 并且机器会有频繁的上下线⾏为, 这种时候需要运维⼿动地去维护这个配置信息是 ⼀个很⿇烦的操作. 所以开发者们开始希望有这么⼀个东西, 它能维护⼀个服务列表, 哪个机器上线了, 哪个机器宕机了, 这些信息都会⾃动更新到服务列表上, 客⼾端拿到这个列表, 直接进⾏服务调⽤即可. 这个就是注册中⼼.注册中心主要有三种角色:服务提供者(server):一次业务中,被其他微服务调用的服务,也就是提供提供给其他微服务.服务消费者(client):一次业务中,调用其他微服务的服务,也就是调用其他微服务提供的接口.服务注册中心(registry):用于保存Server的注册信息,当server节点发生变更时,Registry会同步变更,服务与注册中心使用一定机制通信,如果注册中心与某服务长时间无法通信,就会注销该实例.他们之间的关系,可以通过两个概念来描述:服务注册:服务提供者在启动时,向registry注册自身服务,并向registry定期发送心跳汇报存活状态.服务发现:服务消费者从注册中心查询服务提供者的地址,并通过该地址调用服务提供者的接口.服务发现的一个重要作用就是提供给服务消费者一个可用的服务列表.
1.3 CAP理论
CAP理论是分布式系统设计中最基础,也是最为关键的理论.
一致性:CAP理论中的一致性,指的是强一致性,所有结点在同一时间具有相同的数据.
可用性:保证每个请求都有响应.
分区容错性:当出现网络分区后,系统仍然能够对外提供服务.
CAP 理论告诉我们: ⼀个分布式系统不可能同时满⾜数据⼀致性, 服务可⽤性和分区容错性这三个基本 需求, 最多只能同时满⾜其中的两个.
在分布式系统中, 系统间的⽹络不能100%保证健康, 服务⼜必须对外保证服务. 因此Partition
Tolerance不可避免. 那就只能在C和A中选择⼀个. 也就是CP或者AP架构.
正常情况:
异常情况:
CP架构:为了保证分布式系统对外的数据一致性,于是选择不返回任何数据.
AP结构:为了保证分布式系统的可用性,结点2返回V0版本的数据(即时这个数据不正确)
1.4常见的注册中心Eureka介绍
Eureka是Netflix OSS套件中关于服务注册和发现的解决⽅案. Spring Cloud对Eureka进⾏了集成, 并 作为优先推荐⽅案进⾏宣传, 虽然⽬前Eureka 2.0已经停⽌维护, 新的微服务架构设计中, 也不再建议使用, 但是⽬前依然有⼤量公司的微服务系统使⽤Eureka作为注册中⼼.
Eureka主要分为两个部分:Eureka server:作为注册中心Server端,向微服务应用程序提供服务注册,发现,健康检查等能力. Eurka Client:服务提供者,服务启动时,会向Eureka server注册自己的信息(IP,端口,服务信息等),Eureka Server会存储这些信息.
1.4.1 创建项目并构件启动类和配置文件
启动服务后可以看到上面的界面:
2.服务注册,接下来把product-service注册到eureka-server中.
加入eureka的依赖
修改配置信息:增加项目的名称和eureka注册中心的地址
测试:
可以看见这里的注册中心显示了product-service这个应用.
3.服务发现;
接着是服务发现的内容还是同样的步骤,
引入依赖:
完善配置文件:
远程调用:在远程调用时,需要从eureka-server中获取product-service的列表(可能存在多个服务),并选择其中一个进行调用
测试:
可以看到这里出现了商品的信息.