springboot不香吗?为什么还要使用springcloud--各个组件基本介绍

Eureka注册中心

1.1 Eureka简介

服务的管理

问题分析

service对外提供服务，需要对外暴露自己的地址。而consumer（调用者）需要记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，
一个项目肯定会拆分出十几，甚至数十个微服务。此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。
网约车这就好比是网约车出现以前，人们出门叫车只能叫出租车。一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。
此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务，完美！
Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一个基于REST服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于dubbo的注册中心，比如Zookeeper。

1.2.Eureka基本架构

SpringCloud封装了Netflix公司开发的Eureka模块来实现服务注册和发现（请对比Zookeeper)。Eureka采用了C-S的设计架构。EurekaServer作为服务注册功能的服务器，它是服务注册中心。而系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心路连接。这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行。SpringCloud的一些其他模块（比如Zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑。

1.2.1 EurekaServer(注册中心)

EurekaServer作为一个独立的部署单元，以RESTAPI的形式为服务实例提供了注册、管理和查询等操作。同时，EurekaServer也为我们提供了可视化的监控页面，可以直观地看到各个EurekaServer当前的运行状态和所有已注册服务的情况。

1.2.2 EurekaClient(客户端)

●服务注册： 启动时，会调用服务注册方法，向 EurekaServer 注册自己的信息。EurekaServer 会维护一个已注册服务的列表。当实例状态发生变化时（如自身检测认为Down的时候），也会向EurekaServer更新自己的服务状态，同时用replicateToPeers() 向其它EurekaServer节点做状态同步。
●续约与剔除： 服务实例启动后，会周期性地向 EurekaServer 发送心跳以续约自己的信息，避免自己的注册信息被剔除。续约的方式与服务注册基本一致，首先更新自身状态，再同步到其它Peer。如果EurekaServer在一段时间内没有接收到某个微服务节点的心跳， EurekaServer 将会注销该微服务节点（自我保护模式除外）。
●服务消费： ServiceConsumer 本质上也是一个 EurekaClient 。它启动后，会从 EurekaServer 上获取所有实例的注册信息，包括IP地址、端口等，并缓存到本地。这些信息默认每30秒更新一次。前文提到过，如果与 EurekaServer 通信中断， ServiceConsumer 仍然可以通过本地缓存与 ServiceProvider 通信。

• Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
• 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
  1- Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
  2- 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
  3- 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
  4- 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
  ●三处缓存 EurekaServer 对注册列表进行缓存，默认时间为30s。
  EurekaClient 对获取到的注册信息进行缓存，默认时间为30s。 Ribbon 会从上面提到的EurekaClient获取服务列表，将负载均衡后的结果缓存30s。

Ribbon负载均衡

2.1Ribbon概述

2.1.1.Ribbon是什么

SpringCloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。
简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出LoadBalanCer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

2.1.2.Ribbon主要职责

LB（负载均衡）

LB，即负载均衡（ Load Balanoe )，在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA。
常见的负载均衡有软件nginx , LVS,硬件F5等。
相应的在中间件，例如：dubbo和 SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。

LB又分为两种，集中式LB和进程内LB
集中式LB（偏硬件）

即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如nginx ) ，由该设施负责把访问请求通过某种策略转发至服务的提供方；

进程内LB（偏软件）

将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。
Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服各提供方的地址。

2.1.3 官方资料

https://github.com/Netflix/ribbon/wiki

2.2.Ribbon实例

通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。

但是实际环境中，我们往往会开启很多个service的集群。此时我们获取的服务列表中就会有多个，到底该访问哪一个呢？
一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。

2.2.1.Ribbon架构说明

第一步先选择 EurekaServer，它优先选择在同一个区域内负载较少的server。
第二步再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。
其中Ribbon 提供了多种策略：比如轮询、随机和根据响应时间加权。