微服务架构中的注册中心
微服务架构对服务注册中心的要求
在微服务架构中，由于每一个服务的粒度相对传统SOA来说要小的多，所以服务的数量会成倍增加。这时如果有效管理服务的注册信息就尤为重要。我们对服务注册中心的期望主要有以下几条：
- 简单易用：最好对开发者透明
- 高可用：几台注册中心坏掉不会导致整个服务瘫痪，注册服务整体持续可用
- 避免跨越机房调用：最好调用优先同一个机房的服务以减少网络延迟
- 跨语言：允许开发者使用多种编程语言构建微服务
服务提供者、消费者、发现组件等三者关系
- 微服务启动件自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储微服务的ip地址、端口等信息。
- 服务消费者可以从服务发现组件查询服务提供者的网络地址，并使用该地址调用服务提供者的接口。
- 各位服务与服务组件使用统一的心跳机制，如果服务发现组件长时间无法与某微服务实例通信，就会被注销。
D.微服务网络地址发生变更时，会重新注册到服务发现组件，避免人工修改提供者的网络地址。
服务发现组件核心功能：
- 服务注册表：记录微服务信息的服务名称、ip、端口等，服务注册表查询API和管理API。
- 服务注册与服务发现：服务注册是微服务启动时，将自己的信息注册到服务发现组件上的过程。服务发现是指查询可用微服务列表及其网络地址的机制。
- 服务检查：服务发现组件使用一定机制定时检测已注册的服务状态。
Eureka简介
Eureka 是 Netflix 出品的用于实现服务注册和发现的工具。 Spring Cloud 集成了 Eureka，并提供了开箱即用的支持。其中， Eureka 又可细分为 Eureka Server 和 Eureka Client。
Eureka框架结构
Eureka的框架分为2 个组件：Eureka Server和Eureka Client，具体作用如下：
- Eureka Server提供服务发现的能力，微服务启动的时候，先Eureka Server注册自己的信息（ip、端口、服务名称），Eureka Server存储这些信息。
- Eureka Client是一个客户端，用户简化与Server的交互。
- Eureka Server在90m未收到微服务实例的心跳，Server会销毁该实例。
- Eureka Client会缓存服务注册表中的信息，有一定的优势：减少查询Server的次数，Server节点都宕机，服务消费依赖缓存信息也可以完成服务的正常调用。
Eureka服务治理基础框架3个核心要素
- 服务注册中心：提供服务注册与发现的功能
- 服务提供者：将自己服务注册到服务注册中心
- 服务消费者：消费者应用从服务注册中心获取服务列表，为消费者提供服务。
架构图如下：
服务提供者(服务注册)
Rest方式将数据发送给注册中心，配置：
指示此实例是否应将其信息注册到eureka服务器以供其他人发现。在某些情况下，您不希望发现实例，而您只想发现其他实例。默认值：true
eureka.client.register-with-eureka=true
服务续约，服务提供者通过http向注册中心发送心跳，让服务注册中心知道自己还活着。通过配置如下参数设置续约信息：
#续约任务的调用间隔时间，默认30s
eureka.instance.lease-renewal-interval-in-seconds=30
#服务失效的时间，默认90s
eureka.instance.lease-expiration-duration-in--seconds=90
服务消费者(服务消费)：
获取服务：eureka.client.fetch-register=true;注册中心的职责就是维护服务实例，并检索服务。
指示该客户端是否应从eureka服务器获取eureka注册表信息。默认值为true 一般为服务消费者配置
eureka.client.fetch-registry=true
#指示从eureka服务器获取注册表信息的频率（以秒为单位）默认值：30
eureka.client.register-fetch-interval-seconds = 30;
服务调用：
服务消费在获取服务列表后，通过服务名可以获取具体的服务实例名和该实例的元数据信 息。通过这些信息，可以通过Ribbon采用轮询的方式进行调用，实现客户端的负载均衡。Eureka包含Region和Zone，一个Region包含多个Zone，每个服务客户端需要被注册到一个Zone中，每个客户端对应一个Region和一个Zone。
服务注册中心：
- 失效剔除：Eureka Server在启动时，创建一个定时任务，会60s将清单中超过90s没有续约的服务剔除。
- 自我保护：心跳失败比例在15分钟内，低于85%.