Eureka

在微服务的场景下，各个服务的管理及服务之间调用管理，这是最基础的事情。
springcloud 中提供了Eureka集成框架来做这个事情。 目的在于将各服务之间的调用解耦，使用中间管理平台来辅助各服务之间的调用动作。

Eureka 将微服务分为三种角色， 其中2、3可以是一个服务。 三者都需载入Eureka支持包，并做基本的配置。1. 微服务-注册中心
2. 微服务-服务提供者
3. 微服务-服务调用者

各角色的工作
注册中心： 服务列表维护 | 失活处理 | 路由
服务提供者：启动时向注册中心注册 | 制定失活策略并告知中心 | 发送心跳包
服务调用者： 查找服务信息并缓存 | 定期更新缓存列表

路由策略
1.首先服务提供者需微服务本身定义一个名称，注册时一并告知。
2.服务调用者拿着名称查找微服务的实际地址。
3.路由体现在微服务分布式时，相同的微服务部署多套，此时多个服务服务名称一样地址有多个。此时服务调用者调用方式不变，由注册中心分配一个地址给到调用者。

多注册中心
即多个注册中心同时存在，以保证注册中心的高可用。
每个注册中心在配置时将自己作为一个服务提供者，注册到其它的注册中心。 这样可以使用注册中心本身的功能来管理其它注册中心。 有点类似于递归。
其它服务在配置时，将所有的注册中心都配置上，注册时向任意一个注册中心注册成功即可。
注册中心之间相互会同步服务列表。

eureka 与 Zookeeper

两者都是注册中心模式的服务管理框架，但两者在服务管理理念上有较大不同。

一个概念：CAP，分区容错(这里指各个注册中心可相互同步)、一致性、可用性，三者无法同时实现。

拿多注册中心为例，分区容错是必须实现的，否则失去了多中心的意义。
此时如果考虑一致性，需保证所有服务调用者来取服务列表时是一致的，只有两种方法保证一致，
1. 单个中心更新时锁定所有中心，等所有中心同步完成再开放。
2.所有调用者都从一个中心拿数据（即主从机制）， 若主中心挂了，则重新选出一个主中心，选出的过程所有中心锁定。
对比以上两个方法，首先这两者都不能保证可用性，第一个方法在服务列表更新时所有中心失去服务功能，列表更新是相对很频繁的过程，所有这种方法在绝大大大多数场景下不合适。 第二种方法则是Zookeeper使用的方式。

Zookeeper 保证了多中心时，服务列表的一致性。 问题在于主中心挂了，会有一定时间的中心停止响应。

eureka则放弃了一致性，没有强同步的要求，多中心平级同时提供服务，保证了高可用性。 当然eureka对一致性的问题做了一定的补救措施，也只是补救。

具体选用哪个，要看具体场景对一致性和高可用性哪个要求更高。 大部分场景下会优先保证可用性。

客户端负载均衡 Ribbon

服务端的负载均衡通过服务器的前置服务来实现， 客户端负载均衡是在调用时通过指定调用服务地址来做到均衡。
这两者处理的主体不一样，且这两者是可以并存的。

在Eureka 中集成了Ribbon(其本身也是独立的框架)， 在调用者获取到服务列表，发现一个服务部署在三台机器上，调用该服务时，使用Ribbon进行包装，调用逻辑会均衡的去调用3台机器。

调用者只管调用服务名即可，负载由Ribbon完全封装实现。 同时可以初始设定负载的策略，默认的策略是轮流调用。

熔断器hystrix

https://segmentfault.com/a/1190000005988895 这篇文章对雪崩解释的非常好
hystrix的英文翻译为豪猪
实际运行中，调用会有多级级联调用，或者是相互调用。 此时其中一台服务出现问题，或者响应速度很慢，会使整个系统出现瓶颈。 其它服务在等待该服务响应，造成其它服务的等待线程过多、响应变慢， 同时会逐步放大，造成整个系统雪崩。

hystrix框架，为防止因单个服务故障造成的整体系统雪崩，内置了很多机制。 主要包括以下
资源隔离：即在服务器上给每个服务单独的资源，避免其它服务异常占用资源时，正常服务无资源可用。
服务降级：服务异常、服务超时情况下，通过返回预设的内容，避免重复发起调用，多用在非核心的服务，如用户头像加载，广告加载，商品的介绍信息等，即使服务失败也不会影响主流程。
熔断：连续多次异常是，触发熔断，服务提供服务，或调用者停止调用该服务。
限流：限流可以在前置服务中处理(如nginx中)，这里是在服务中做限制，即指定某个服务最多使用的线程数，超过该线程数则暂时拒绝新的服务。

以上内容已可以完成微服务群的，服务管理、负载均衡、整体保护、及高可用

—————————————————————————————————————————————

以下内容为对微服务群的附加内容，以提高开发效率、运维效率、异常处理效率

spring cloud config 配置统一管理

微服务群中服务器非常多，且散部在各处，同时每个服务都需进行配置处理，其中的分布式服务其配置文件是一致的。用传统的运维方式效率难以满足要求，且容易出现遗漏等问题。

config架构将配置统一管理，内置了基本的文件管理、配置下发等功能，起到配置中心的作用。

eureka的配置文件不要装载在config中，否则启动注册中心时需先启动config，比较难受。
config本身会装载在一个微服务上，同时也可向eureka注册。
客户端获取配置的方式：首先需加入config的依赖包，基本配置中指向config服务，同时执行配置文件的名称，在启动时会先去加载配置文件作为自己的配置。

Zuul 路由网关

zuul本身是加载在微服务上的，同样也注册在eureka 上。
服务群的前置服务，提供服务路由，请求过滤，内外部隔离，服务聚合，服务映射。

其本身就集成了hystrix 。

在服务群较多时，zuul起到统一入口，辅助请求处理等功能。