- 服务发现——Netflix Eureka
- 客服端负载均衡——Netflix Ribbon
- 断路器——Netflix Hystrix
- 服务网关——Netflix Zuul
- 分布式配置——Spring Cloud Config
Netflix Eureka
Eureka 是什么？
Eureka 是 Netflix 贡献出来的开源中间层负载均衡和服务发现的工具。Eureka 基于 Java 实现，可以非常方便的在 Spring 应用程序里声明 Server 和 Client 进行服务注册。
Eureka 解决的问题
Eureka 服务器是服务的注册中心，它能提高大规模集群环境里服务发现的容错性和可用性。并且可以解决跨数据中心之间的服务注册和发现的问题。
Netflix 推荐在每个 Region 搭建一个 Eureka 集群，每个 Region 里的可用区至少有一个 Eureka Server，这样可以保证任意一个可用区的服务注册信息都会被复制到各个可用区，实现服务信息的高可用。在任意可用区的客户端都可以访问到服务的注册信息。客户端在访问服务器之后会在本地缓存服务的信息，并且定期（30秒）刷新服务的状态。
如果在集群内有大面积的网络故障时（例如由于交换机故障导致子网之间无法通信），Eureka 会进入自我保护模式，每个Eureka节点会持续的对外提供服务（注：ZooKeeper不会）：接收新的服务注册同时将它们提供给下游的服务发现请求。这样就可以实现在同一个子网中（Same side of partition），新发布的服务仍然可以被发现与访问。
在 Eureka V1.0的版本里，Eureka 之间的数据同步是全量同步，每个客户端都有 Eureka 集群里所有服务的信息，在 V2.0的版本里，将支持客户端偏好的服务信息同步。同时也会增强 Eureka 的读写分离和高可用性。
Netflix Ribbon
Ribbon的核心组件(均为接口类型)有以下几个：
ServerList
用于获取地址列表。它既可以是静态的(提供一组固定的地址)，也可以是动态的(从注册中心中定期查询地址列表)。
ServerListFilter
仅当使用动态ServerList时使用，用于在原始的服务列表中使用一定策略过虑掉一部分地址。
IRule
选择一个最终的服务地址作为LB结果。选择策略有轮询、根据响应时间加权、断路器(当Hystrix可用时)等。
Ribbon在工作时首选会通过ServerList来获取所有可用的服务列表，然后通过ServerListFilter过虑掉一部分地址，最后在剩下的地址中通过IRule选择出一台服务器作为最终结果。
与Eureka结合使用
当与Eureka组合使用Ribbon时，ServerList接口会使用DiscoveryEnabledNIWSServerList实现，该实现会通过 EurekaClient 向Eureka服务器获取可用的服务列表。ServerListFilter默认实现为ZonePreferenceServerListFilter，其作用是过虑掉不同zone下的服务(即优先选择同一个zone下的地址)。IRule使用ZoneAvoidanceRule实现，它是一种复合策略，同时使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前者以一个区域为单位判断可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的server；后者用于过滤掉连接数过多和断路器处于打开状态的server。该复合策略经过上述两次过虑后最终选择出一个地址作为LB结果。
服务器端负载均衡 Nginx
nginx 是客户端所有请求统一交给 nginx，由 nginx 进行实现负载均衡请求转发，属于服务器端负载均衡。
既请求由 nginx 服务器端进行转发。
客户端负载均衡 Ribbon
Ribbon 是从 eureka 注册中心服务器端上获取服务注册信息列表，缓存到本地，然后在本地实现轮询负载均衡策略。
既在客户端实现负载均衡。
Netflix Hystrix
下图展示了当使用 Hystrix 构造请求，请求到一个服务依赖项时所发生的流程：
下面部分将更详细地解释上述流程：
1. 构造一个 HystrixCommand 或 HystrixObservableCommand 对象
2. 执行 Command
3. 是否缓存 Response
4. 断路器是否打开
5. 线程池 / 队列 / 信号量 是否已
6. 执行 HystrixObservableCommand.construct() 或 HystrixCommand.run()
7. 计算线路健康状况
8. 获取回调
9. 返回成功的 Response
货船为了进行防止漏水和火灾的扩散,会将货仓分隔为多个，这种资源隔离减少风险的方式被称为：Bulkheads(舱壁隔离模式)。
Hystrix将同样的模式运用到了服务调用者上，在一个高度服务化的系统中，一个业务逻辑通常会依赖多个服务，比如：商品详情展示服务会依赖商品服务，价格服务，商品评论服务。调用三个依赖服务会共享商品详情服务的线程池。如果其中的商品评论服务不可用，就会出现线程池里所有线程都因等待响应而被阻塞，从而造成服务雪崩。Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离，从而避免服务雪崩。
熔断器模式定义了熔断器开关相互转换的逻辑。
服务的健康状况 = 请求失败数 / 请求总数。熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的。
当熔断器开关关闭时，请求被允许通过熔断器。 如果当前健康状况高于设定阈值，开关继续保持关闭。如果当前健康状况低于设定阈值，开关则切换为打开状态。当熔断器开关打开时，请求被禁止通过。当熔断器开关处于打开状态，经过一段时间后，熔断器会自动进入半开状态，这时熔断器只允许一个请求通过。当该请求调用成功时，熔断器恢复到关闭状态。若该请求失败，熔断器继续保持打开状态，接下来的请求被禁止通过。
熔断器的开关能保证服务调用者在调用异常服务时，快速返回结果，避免大量的同步等待，并且熔断器能在一段时间后继续侦测请求执行结果，提供恢复服务调用的可能。
Hystrix使用命令模式（继承HystrixCommand类）来包裹具体的服务调用逻辑（run方法），并在命令模式中添加了服务调用失败后的降级逻辑（getFallback）。
同时在Command的构造方法中可以定义当前服务线程池和熔断器的相关参数。因此在使用了Command模式构建了服务对象之后，服务便拥有了熔断器和线程池的功能。
Netflix Zuul
Zuul提供了一个框架，可以对过滤器进行动态的加载，编译，运行。过滤器之间没有直接的相互通信，他们是通过一个RequestContext的静态类来进行数据传递的。RequetstContext类中的ThreadLocal变量来记录每个request所需要传递的数据。
它包含了对请求的路由和过滤两个功能，其中路由功能负责将请求转发到具体的微服务 实例上，而过滤器功能则负责对请求进行预处理。
然而实际上，路由功能在真正运行时，它的路由映射和请求转发功能也是由过滤器来完成的。路由映射器主要通过pre类型的的过滤器完成，将请求路径与配置的路由 规则进行匹配，找到需要的转发的目标地址，而请求转发的部分则是由route类型的过滤器来完成。
所以，过滤器可以说是Zuul实现API网管功能最为核心的部件，每一个进入Zuul的HTTP请求都会经过一些列的过滤器处理连得到请求响应并返回给客户端。
过滤器是由Groovy写得，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便于request使用。
过滤器的类型
PRE:在请求达到Origin Server之前调用，比如身份验证
CUSTOM:自定义的过滤器
ROUTING:在路由请求时被调用
POST:在routing和error过滤器之后被调用，比如做各种统计
ERROR:在其他阶段发生错误时执行该过滤器
Spring Cloud Config
Spring Cloud Config的介绍
Spring Cloud Config为分布式系统中的外部化配置提供服务器和客户端支持。借助Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念与Spring Environment和PropertySource抽象，因此它们非常适合Spring应用程序，但可以与任何运行在任何语言的应用程序一起使用。随着应用程序从开发到测试转移到部署管道中，您可以管理这些环境之间的配置，并确保应用程序具有在迁移时所需运行的所有内容。服务器存储后端的默认实现使用git，因此它可以轻松支持配置环境的标签版本，并且可以用于管理内容的各种工具。使用Spring配置很容易添加替代实现并将其插入。
Spring Cloud Config特点
HTTP，用于外部配置的资源API（名称 - 值对或同等YAML内容）
加密和解密属性值（对称或不对称）
使用可轻松嵌入Spring Boot应用程序 @EnableConfigServer
配置客户端功能（针对Spring应用程序）：
绑定到配置服务器并Environment使用远程属性来初始化Spring
加密和解密属性值（对称或不对称）
