SpringCloud微服务架构

时间:2022-09-04 18:48:07

1、Eureka承载大规模系统每天千万级访问的原理

  1)、首先每个服务的eureka client组件默认30秒发送一个请求到eureka server拉取最近有变化的服务信息;

  2)、eureka还有一个心跳机制,各个eureka client每隔30秒会发送一个心跳到eureka server告诉eureka server该client还活着,如果client很长时间没有发送心跳,说明该服务挂了。所以在手动(非自动化)部署项目的时候,我们得先杀掉准备部署的项目的进程(重启某服务,非启动某服务),再部署。  因为eureka  server默认该服务还存在,未杀死进程就重启项目,则会端口冲突;

  3)、eureka server注册表的核心结构是cocurrentHashMap结构,并且基于纯内存,在内存中维护Map数据结构。  各个服务的注册、服务下线、服务故障都会在内存中维护和更新这个注册表;

  4)、eureka server 的多级缓存机制。拉去注册表3级缓存:首先从readOnlyCacheMap里面查缓存的注册表,没有就从readWriteCacheMap里查缓存的注册表,再没有就从内存中查询。  这样尽可能保证了内存注册表数据不会出现频繁的读写冲突问题,进一步保证了eureka server的大量请求,都是快速从纯内存中走,性能极高。

2、微服务注册中心(Eureka、Consul)的读写锁优化 

  读写锁:一个锁可以拆分为读锁和写锁。加锁的时候遵循数据改动则不能使锁冲突(包括同类型锁)的原则,例如同一时间一个线程就只能加一个写锁、同时有线程加了写锁,其他线程就不能加读锁等等(遵循原则)。

  服务中心的注册表,记录了各个服务注册时,发送来的地址信息。服务A(服务实例1:192.168.1.1:8081,服务实例2:192.168.1.3:8081)、服务B(服务实例1:192.168.1.5:8081,服务实例2:192.168.1.6:8081)。

  该注册表会写和读都发生。如果不对同一个内存加保护,就可能发生多线程并发修改共享数据的问题。如果加synchronized让所有读写都串行化,则效率会很低。 所以读写锁是非常适合这种读多写少的场景(微服务的读多写少)。并且加上多级缓存机制,可以在写数据的时候读数据。

参考:石杉的架构日志、纯洁的微笑(公众号)