微服务架构
微服务2014年提出，微服务架构是将应用分为许多小型服务，每个服务可以用不同的编程语言使用不同的数据库。众多的服务需要通过微服务框架来管理，具体表现在服务注册，服务发现、服务注册、负载均衡、熔断限流、服务监控等，对服务进行治理
微服务框架Springcloud（Finchley版本）
1、Eureka服务发现、服务注册
Eureka是Netflix开源的一款提供服务注册和发现的产品，与Spring Cloud无缝集成。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。
服务注册发现的三个角色
- 服务提供者：会向Eureka Server做服务注册、Renew服务续约、Cancel服务下线<基本靠心跳>。
- 注册中心之间会做注册服务的同步，从而保证状态一致，服务注册中心必须要有高可用性和实时更新功能。
- Service Consumer会向Eureka Server获取注册服务列表，并消费服务
注册发现过程：
Eureka提供了服务注册和查询服务信息的REST API。服务通过使用POST请求注册自己的IPAddress和Port。每30秒发送一个PUT请求刷新注册信息，如果一个服务在90 秒之后没有发送心跳，它将从所有 Eureka 节点上注销。通过DELETE请求也可以注销服务，客户端通过GET请求获取可用的服务实例信息。
服务发现心跳的两种方式：
客户端发送心跳<常用>
客户端每隔一定时间主动发送“心跳”的方式来向服务端表明自己的服务状态正常，心跳可以是 TCP 的形式，也可以是 HTTP 的形式。也可以通过维持客户端和服务端的一个 socket长连接自己实现一个客户端心跳的方式。
服务端主动探测
服务端主动调用服务进行健康检查是一个较为准确的方式，返回结果成功表明服务状态确实正常。服务端调用服务发布者某个 HTTP 接口。服务端主动探测也存在问题，在很多场景下服务注册中心到服务发布者的网络是不通的，
注册中心的高可用
通过多个Eureka实例来实现的,每一个Eureka服务都有一个弹性IP Address。当Eureka服务启动时，有DNS服务器动态的分配。Eureka客户端通过查询 DNS来获取Eureka的网络地址（IP Address和Port）。
Eureka平台中，如果某台服务器宕机，Eureka不会有类似于ZooKeeper的选举leader的过程；客户端请求会自动切换到新的Eureka节点；当宕机的服务器重新恢复后，Eureka会再次将其纳入到服务器集群管理之中。
网络分割故障与高可用：
网络分割故障：当网络交换机出故障会导致不同子网间通讯中断
当网络分割故障发生时，每个Eureka节点会持续的对外提供服务（ZooKeeper不会）可以实现在同一个子网中，新发布的服务仍然可以被发现与访问。
当网络分割故障发生时，将Eureka集群分割成了独立的子网而不能互访， Eureka可能会错误的将本身健康的服务，当成掉线的服务而错误的服务下线。
—>如果Eureka服务节点在短时间里丢失了大量的心跳连接
那么这个 Eureka节点会进入”自我保护模式“，同时保留那些“心跳死亡“的服务注册信息不过期。此时，这个Eureka节点对于新的服务还能提供注册服务，对于”死亡“的仍然保留，以防还有客户端向其发起请求。
当网络故障恢复后，这个Eureka节点会退出”自我保护模式“。所以Eureka的哲学是，同时保留”好数据“与”坏数据“总比丢掉任何”好数据“要更好，所以这种模式在实践中非常有效。
当网络分割故障导致客户端不能访问任何一台Eureka服务器，服务消费者仍然可以通过 Eureka客户端缓存来获取现有的服务注册信息。<Eureka客户端缓存> Eureka客户端具有注册表缓存信息，所以即使所有的Eureka服务器都停机，它们也可以运行得很好
2、负载均衡Ribbon和Feign
Spring Cloud Ribbon 是一个基于HTTP和TCP的客户端负载均衡工具，它基于 Netflix Ribbon实现。Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者发请求。Ribbon默认为我们提供了很多负载均衡算法，例如轮询、随机等。当然也可为Ribbon实现自定义的负载均衡算法。Feign默认集成了ribbon。
通常所说的负载均衡都指的是服务端负载均衡，而客户端负载均衡和服务端负载均衡最大的不同点在于上面所提到的服务清单所存储的位置。在客户端负载均衡中，所有客户的节点都维护着自己要访问的服务清单，而这些服务端的清单来通过从注册中心进行抓取得到的，同时也需要对此进行维护。
3、熔断Hystrix、限流
服务限流主要是保护服务节点或者数据节点，防止瞬时流量过大造成服务和数据崩溃，导致服务不可用。当资源成为瓶颈时，服务框架需要对请求做限流，启动流控保护机制。控制访问流量，通过指定的策略消减流量（如网络层面限制访问流量、后服务实例使用技术手段限制并发数量等），使得落到后台服务实例的请求在能承受的范围内。
雪崩效应
某个服务出现问题，此时若有大量的请求涌入，服务器资源耗尽会导致服务瘫痪。服务与服务之间的依赖性故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
降级机制
当访问量剧增、非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。弃卒保帅，最终目的是保证核心服务可用，即使是有损的。但是核心服务肯定是无法舍弃的，只能是一种保障或者拯救措施。
Hystrix是Netflix一个限流容错框架，解决微服务架构体系中的限流、降级、熔断等功能。提高系统稳定性，提供了完善的监控实现，并且Hystrix可以根据监控数据动态调整内部处理机制。
- 熔断：在第三方客户端访问依赖服务出现高延迟或者失败时，熔断访问请求，为系统提供保护和控制
- 雪崩：在分布式系统中防止级联失败，避免因为某一个服务功能不正常导致异常扩散
- 快速失败：Fail fast，同时能快速回复
- 失败回滚和降级：提供Fallback和优雅的降级机制
- 监控报警：提供近实时的监控、报警和运维手段
较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。
4、API网关zuul—>Gataway
Zuul是Netflix开源的微服务网关，提供动态路由、监控、弹性、安全性等功能。它可以和Eureka、Ribbon、hystrix等组件配合使用。Zuul的核心是一系列过滤器。这些过滤器完成以下功能：
- 身份认证和安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
- 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
- 动态路由：动态地将请求路由到不同的后端集群。
- 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
服务网关
服务网关也就是API网关，服务网关可以作为服务的统一入口，提供身份校验、动态路由、负载均衡、安全管理、统计、监控、流量管理、灰度发布、压力测试等功能
服务网关/API网关并不是微服务体系所特有的，而是微服务流行起来之后，服务网关基本上成了微服务架构的标配。服务网关通常用于向客户端提供统一的服务接入方式。
Spring Cloud Gateway
Zuul基于servlet使用阻塞API它不支持任何长连接如websockets。而Gateway建立在Spring Framework使用非阻塞API。Gateway 中Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的开发体验。
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。
Spring Cloud gateway工作流程
如图所示，客户端发出请求，如果Gateway Handler Mapping确定请求与路由匹配（这个时候就用到predicate），则将其发送到Gateway web handler处理，经过一系列的过滤器链。predicate决定了一个请求走哪一个路由。
predicate
Predicate来自于java8的接口。Predicate 接受一个输入参数，返回一个布尔值结果。
filter的作用和生命周期
当我们有很多个服务时，每个服务都需要做相同的鉴权、限流、日志输出等。对于这样重复的工作，在微服务的上一层加一个全局的权限控制、限流、日志输出的Api Gateway服务，然后再将请求转发到具体的业务服务层。这个Api Gateway服务就是起到一个服务边界的作用，外接的请求访问系统，必须先通过网关层
5、服务追踪zipkin
Spring Cloud Sleuth集成了zipkin可视化组件
服务链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败，需要服务追踪找到是哪个服务出现问题。
6、分布式配置中心——github共享库
服务配置文件统一管理，实时更新。在Spring Cloud中分布式配置中心组件spring cloud config 支持配置服务放在本地，也支持放在远程Git仓库中。在spring cloud config分客户端和服务端。
消息总线
Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。
