本文共 977 字,大约阅读时间需要 3 分钟。
简图如下:
整个微服务通过注册中心后,整个过程就很简单了。比如订单服务再加一台机器时,整个服务是不需要做任何改动的(会注册到Eureka注册中心),用户系统就可以发现新加的机器,拉取列表到本地,下次调用时由于本地已经有新机器的IP了,所以就可以使用到(这个就是Spring Cloud注册中心牛逼的地方)。
订单系统新加机器在启动时会把自己的机器信息通过Eureka中心的接口,把信息写到注册表中。
用户系统在启动的时候会从微服务注册中心把整个列表拉过来备注:Eureka的client包里面有心跳服务,大约每30s就会从服务注册中心重新拉取一次注册表,新加的机器可能在30s之内感知不到,但是在30s过后就会调用获取注册表的接口来获得最新的注册表。
可以发现,整个服务注册中心最最核心的就是注册表信息。
所有服务注册中心的操作都是对注册表信息去操作。解答前思考:Eureka的底层是如何实现注册表的?(1分钟)
说白了,Eureka其实就是一个简简单单的注册表集合。
Eureka的客户端启动的时候往注册表集合中增加一条机器实例的IP,然后Eureka的使用端把注册表的信息拿到本地,之后就直接调用了,不再和服务注册中心做交互了(除了Eureka的心跳机制) 来来回回其实就是对Eureka内部的注册表去做操作,要么写入,要么读取。 可以想一下如果是我们来设计实现这个Eureka的注册中心,我们会用什么结构呢?那首先想到的就是MapEureka核心接口
Eureka本身就是个web服务,对外提供了很多HTTP接口,这些HTTP接口实际上底层就是操作注册表。启动Eureka服务端,然后启动客户端,观察注册调用的接口:
为什么Eureka要使用map来存储注册表?而不是用数据库或者其他的数据结构来存储?
内存结构,查找快,基于性能考虑,支持并发 比如一线互联网公司的后端微服务,会有几十甚至上百个,每个微服务都可能有几十个实例,这么多实例都要去访问Eureka注册中心,那么访问量就很大(启动的时候需要写入数据、不时的需要拉取注册表信息、某个实例挂掉了还要操作删除注册表),整个注册表对性能要求很高,要支撑高并发那么使用内存结构去操作效率会更高,要是使用数据库,就无法满足后端那么多子系统去操作。 存储的结构大致如下:转载地址:http://payai.baihongyu.com/