SpringCloud微服务架构

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让所有读写都串行化，则效率会很低。 所以读写锁是非常适合这种读多写少的场景（微服务的读多写少）。并且加上多级缓存机制，可以在写数据的时候读数据。

参考：石杉的架构日志、纯洁的微笑（公众号）