微服务

微服务架构是一种以一些微服务来替代开发单个大而全应用的方法，每一个小服务运行在自己的进程里, 并以轻量级的机制来通信, 通常是 HTTP RESTful API。微服务强调小快灵， 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务。
  微服务是一种生态，不是一种具体技术

微服务的特性

自主性（松耦合）

可以对微服务架构中的每个组件服务进行开发、部署、运营和扩展，而不影响其他服务的功能。这些服务不需要与其他服务共享任何代码或实施。各个组件之间的任何通信都是通过明确定义的 API 进行的。

专用性

每项服务都是针对一组功能而设计的，并专注于解决特定的问题。如果开发人员逐渐将更多代码增加到一项服务中并且这项服务变得复杂，那么可以将其拆分成多项更小的服务。

灵活扩展

通过微服务，您可以独立扩展各项服务以满足其支持的应用程序功能的需求。这使团队能够适当调整基础设施需求，准确衡量功能成本，并在服务需求激增时保持可用性。

轻松部署

微服务支持持续集成和持续交付，可以轻松尝试新想法，并可以在无法正常运行时回滚。由于故障成本较低，因此可以大胆试验，更轻松地更新代码，并缩短新功能的上市时间。

目前微服务的发展状况

目前主流的就是 springCloud 和 dubbo 了，那么我们对他们做一个对比：

Dubbo

一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错、负载均衡，以及服务自动注册和发现。

节点角色说明：

Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。（Dubbo 种一般都是使用 zookeeper 作为注册中心）
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。

调用关系说明：

服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

SpringCloud 与 Dubbo 的对比

SpringCould 是基于 SpringBoot 的基础上的一个微服务架构。包括包服务发现（Eureka），断路器（Hystrix），服务网关（Zuul），客户端负载均衡（Ribbon）、服务跟踪 (Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task) 等。Spring Cloud 抛弃了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。
  Dubbo 和 Spring Cloud 并不是完全的竞争关系，两者所解决的问题域不一样：Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目的是微服务架构下的一站式解决方案。

SpringCloud

服务发现——Netflix Eureka

Eureka 包含两个组件：Eureka Server 和 Eureka Client

Eureka Server 提供服务发现能力，各个微服务启动时会向 Eureka Server 注册自己的信息（服务名、IP、端口等），Eureka Server 便存储了这个信息。功能类似于 zookeeper
Eureka Client 是一个 Java 客户端，用于简化与 Eureka 的交互。
心跳机制：每个微服务启动后， 会每个一定时间（默认 30s）向 Eureka Server 发送心，让其知道自己扔健康存活。如果 Eureka Server 在一定时间内（默认 90s）没有收到某个微服务实例的心跳，Eureka Server 就会注销该实例
Eureka 集群：默认情况下，Eureka Server 也是 Eureka Client，多个 Eureka Server 之间通过复制方式，来实现服务注册表中的数据同步。Eureka Client 会缓存服务注册表中的信息， 无须每次都请求 Eureka Server 查询，缓解了 Eureka Server 的压力；即使 Eureka Server 所有节点都宕机，服务消费者依然可以查询自己缓存中的信息找到去调用服务提供者。
自我保护机制：若是因为网络原因，通过心跳机制判读该服务已死导致实例被注销时，这是不被允许的。因此自我保护机制来解决这个问题，当 EurekaServer 节点短时间内丢失过多客户端（网络原因导致），那么这个节点就会进入自我保护模式，一旦进入该模式，EurekaServer 就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络恢复时，该 EurekaServer 节点会退出自我保护机制。自我保护机制使 Eureka 集群更加的稳定与健壮。

CAP 原则

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。CAP 原则是 NOSQL（Redis、mongdb）数据库的基石。

一致性（Consistency）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
可用性（Availability）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（Partition tolerance）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择（集群下必须要保证 P）。

CAP 三个特性只能满足其中两个：

CA without P：如果不要求 P（不允许分区），则 C（强一致性）和 A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。传统的关系型数据库 RDBMS：Oracle、MySQL 就是 CA。

CP without A：如果不要求 A（可用），相当于每个请求都需要在服务器之间保持强一致，而 P（分区）会导致同步时间无限延长 (也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

AP wihtout C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

zookeeper 和 Eureka

zookeeper 保证的是 CP
zookeeper 存在的问题：当 master 挂掉的时候会通过选举产生新的 master，但是由于在选举期间集群不可用且选举时间过长导致服务长期不可用。
Eureka 保证的是 AP
Eureka 由于保证的是可用性，因此不会出现上面那种情况。因为 Eureka 的每个节点都是平等的，挂掉几个节点不会影响整体的工作，当某个 Eurek 的客户端注册失败的时候会自动切换到其他节点进行注册，只要是还有一台存活就阔以保证可用性，只不过查询到的数据不是最新的。
   因此 Eureka 可以很好的应对因为网络故障导致节点丢失的情况，而不是像 zookeeper 那样使整个注册服务瘫痪的情况。

客服端负载均衡——Netflix Ribbon

Ribbon 工作原理
ribbon 实现的关键点是为 ribbon 定制的 RestTemplate，ribbon 利用了 RestTemplate 的拦截器机制，在拦截器中实现 ribbon 的负载均衡。负载均衡的基本实现就是利用 applicationName 从服务注册中心获取可用的服务地址列表，然后通过一定算法负载，决定使用哪一个服务地址来进行 http 调用。

负载均衡分类

集中式 LoadBalance
在消费者和提供者之间使用独立的 LoadBanlance 设备，如 Nginx（反向代理服务器）。由该设备将访问亲求分发到提供者。
进程式 LoadBalance
将 LoadBanlance 的逻辑整合到消费者，消费者从注册中心获取可用的地址，然后自己通过策略选择合适的服务器。Ribbon 就是典型的进程式。

负载均衡算法

随机负载均衡（默认）：随机选择状态为 UP 的 Server
简单轮询负载均衡：以轮询的方式依次将请求调度不同的服务器
加权响应时间负载均衡：根据响应时间分配一个 weight，响应时间越长，weight 越小，被选中的可能性越低
区域感知轮询负载均衡：复合判断 server 所在区域的性能和 server 的可用性选择 server

断路器——Netflix Hystrix

Hystrix 为分布式系统的延迟和故障提供强大的容错能力。 当一个节点出问题的时候，hystrix 保证了整体不会失败，提高了分布式系统的弹性

服务熔断

微服务架构中某个微服务发生故障时，要快速切断服务，提示用户，后续请求，不调用该服务，直接返回，释放资源，这就是服务熔断。
熔断生效后，会在指定的时间后调用请求来测试依赖是否恢复，依赖的应用恢复后关闭熔断。

服务降级

服务器高并发下，压力剧增的时候, 根据当业务情况以及流量，对一些服务和页面有策略的降级 (可以理解为关闭不必要的服务)，以此缓解服务器资源的压力以保障核心任务的正常运行。
双十一期间，支付宝很多功能都会提示，[双十一期间，保障核心交易，某某服务数据延迟]。

服务网关——Netflix Zuul

网关：系统唯一对外的入口，介于客户端与服务器端之间，用于对请求进行鉴权、限流、 路由、监控等功能。

zuul 提供了两个主要功能：路由和过滤

路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。
过滤功能则负责对请求的处理过程进行干预，是实现请求校验、鉴权等处理
  Zuul 和 Eureka 进行整合，将 Zuul 自身注册为 Eureka 服务治理下的应用，同时从 Eureka 中获得其他微服务的消息，也即以后的访问微服务都是通过 Zuul 跳转后获得。
  注意：Zuul 服务最终还是会注册进 Eureka

通俗点就是统一了访问地址

分布式配置——Spring Cloud Config

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在 Spring Cloud 中，有分布式配置中心组件 spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程 Git 仓库中。在 spring cloud config 组件中，分两个角色，一是 config server，二是 config client。server 提供配置文件的存储、以接口的形式将配置文件的内容提供出去，client 通过接口获取数据、并依据此数据初始化自己的应用。

最后

大家看完有什么不懂的可以在下方留言讨论，也可以关注我私信问我，我看到后都会回答的。也欢迎大家关注我的公众号：前程有光，金三银四跳槽面试季，整理了 1000 多道将近 500 多页 pdf 文档的 Java 面试题资料，文章都会在里面更新，整理的资料也会放在里面。谢谢你的观看，觉得文章对你有帮助的话记得关注我点个赞支持一下！