String Cloud Eureka 服务治理

基础架构：

        ① 服务注册中心：  Eureka提供服务端,提供注册与发现。所有有服务都会注册到 eureka-server

        ② 服务提供者: 用EurekaClient 将自己的服务注册到 Eureka 上，Eureka 提供 一个 application 来存储提供者所注册的名称

        ③ 服务消费端: 消费者应用从Eureka 服务注册中心中获取服务列表 application ,从而知道调用其他所需要的服务

服务治理机制：

         注册中心-1 可以和 注册中心-2 互相注册来达到高可用的集群。

         服务提供者也可以启动 两个实例,注册到 一个服务中心上 

   服务注册：

         服务提供者在启动的时候会通过 REST 请求的方式将自己注册到 eureka-server,同时带在自身的元数据信息。Eureka-server 接收到这 REST 请求之后 会用一个 双层Map 来存储 。第一层用来存储 application 服务名称，第二层次是存储的具体的实例名称

   服务同步：

         注册中心互相注册的高可用集群，当 A 服务 注册到 注册中心 -1 的时候它将该请求转发给 集群当中的注册中心, 来实现注册中心之间的服务同步。所以提供者只需要注册集群某一个注册中心的节点就好

   服务续约：

          服务提供者将维护一共心跳来持续告诉 Eureka-server,防止 Eureka-server 移除任务 （默认为30秒）

   注册中心：

   服务下线：当实例服务下线时 会 发送一个 REST 请求给 Eureka-server 告诉 注册中心 “我要下线了“ 。注册中心在下线请求转发给集群。

          当服务实例没正常下线的时候,Eureka-server 在启动时会创建一个定时任务将无法提供服务的实例移除。默认为 60 秒将清单中超时 90 秒的没有续约的服务移除。

服务消费：

        服务获取发送REST 请求 给 注册中心来获取服务清单。为考虑性能。Eureka-server 会维护一份只读服务清单来返回给客户端，同时30秒刷新一次请求。

        服务调用，在获取服务清单后，根据具体服务的实例名和该实例的元数据信息。在进行调用。Ribbon中默认是轮询的方式访问