Spring Cloud内部运行原理

        Spring Cloud作为云应用集中了很多组件包括：路由代理(Zuul)、注册与发现(Eureka and Client)、断路器(Hystrix)、消费服务者(Ribbon  and Feign)等，每个组件在架构都为实现不同的处理功能。看如下结构图：

 1、外部或者内部的非spring cloud项目都先通网关zuul然后从eureka server中获取可用列表服务。

2、从eureka server注册中心返回可用实例。

3、通过ribbon负载均衡分配可用节点。

4、ribbon选择可用的节点分配到后端具体的实例

5、hystrix断路器查看当前实例是否可用，dashboard监控实例状态信息，Turbine监控服务间的调用和熔断相关指标。

6、后端服务与服务之间都是通过feign通信，处理请求业务后返回到Eureka中心返回结果。

一、介绍下Eureka的缓存机制：

    对于日访问量达千万级的项目，Spring Cloud本身eureka client 每隔30秒就需要向eureka server发送心跳以检测当前服务是可用的，这本身就是非常消耗资源的，但这并不影响Spring Cloud强大的业务管理。其中主要依赖于两点：

1、Eureka Server设计精妙的注册表存储结构

   查看Eureka Server注册的源码 位于org\springframework\cloud\spring-cloud-netflix-eureka-server\2.1.0.RC3\spring-cloud-netflix-eureka-server-2.1.0.RC3.jar中：

    private final ConcurrentHashMap>> registry
            = new ConcurrentHashMap>>();

 其中registy定义的类型就是注册表里的核心结构。也是说eureka server是内存进行存储，在内存中定义了一个数据结构，各个服务的注册、服务下线、服务故障，全部会在内存里维护和更新这个注册表。eureka会直接从内存中读取注册列表。

ConcurrentHashMap中有两个参数一个String,另一个Lease,String代表的也就是注册的程序名称，而Lease代表是这个机器的ip地址、hostname以及端口号封装成一个对象到注册中心。

2、Eureka Server端优秀的多级缓存机制

   eureka为了避免同时读写内存数据结构造成的并发冲突问题采用了多级缓存的机制：

在拉取注册表时会首从readonlyCacheMap缓存里查找，如果没有再从readWriteCacheMap查找，要是还没有找到就直接从内存找。 当注册表发生改变时，直接修改内存中的注册表同时会过滤掉readWriteCacheMap，但readonlyCacheMap不会进行过滤还可以访问，当到达30秒过后后台线程发现readWriteCacheMap被清空了，同时也会清空readonlyCacheMap。当下个请求进行访问readonlyCacheMap和readWriteCacheMap会重新从最新的内存注册表过更新数据，又达到了一致性。

 

总结：Eureka同时通过纯内存的注册表，保证了所有的请求都可以在内存处理，确保了极高的性能，另外多级缓存机制，确保了不会针对内存数据结构发生频繁的读写并发冲突操作，进一步提升性能。