微服务+SpringCloud

1、什么是微服务？

学术上定义（了解）：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，每个服务独立运行在其自己独立的进程中，服务之间相互协调配合，为用户提供最终价值。服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的RESTful API）

业务上定义（面试）：微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地去耦合，，每个微服务提供单个业务功能的服务，一个服务做一件事。从技术角度看就是一种小而独立的处理过程，类似进程的概念，能够自行单独启动或销毁，拥有自己独立的数据库。

2、微服务的优缺点

• 优点

  1、每个服务足够内聚，足够小，代码容易聚焦在一个指定的业务上

  2、微服务是松耦合的，无论是开发还是部署阶段

  3、微服务只是业务逻辑的代码，不会和前端界面组件混合

  4、每个微服务有自己的存储能力，可以有自己的数据库，也可以有统一的数据库

• 缺点

  1、处理分布式系统的复杂性

  2、服务间通信成本增加

  不同机器上的进程是允许相与调用的，当机器A上的进程调用机器B上的进程时，A上的调用进程被挂起，而B上的被调用进程开始执行。调用方可以通过使用参数将信息传送给被调用方，然后可以通过传回的结果得到信息。编程人员看不到任何消息传递过程。这个方法就被程为远程过程调用RPC。

  3、分布式系统的事务处理

3、微服务技术栈有哪些？

技术栈即多种技术的集合体

4、为什么选择SpringCloud作为微服务架构?

具有完整的微服务框架

5、SpringCloud入门概述

基于SpringBoot提供了一整套微服务解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。

• SpringCloud和是什么关系SpringBoot?

  1、SpringBoot专注于快速方便开发单个个体服务

  2、SpringCloud是关注全局的微服务协调处理框架，他将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供配置管理，服务发现，断路器，路由等集成服务

  3、SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开boot，属于依赖关系

  4、SpringBoot专注于快速、方便开发单个微服务个体，SpringCloud关注全局的服务治理框架

6、Duobbo和SpringCloud的对比

最大的区别：SpringCloud选择基于HTTP的的REST方式进行通信，Dubbo选择RPC进行通信

Dubbo的定位始终是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案

7、Eureka

Eureka是一个基于REST的服务，用于定位服务，以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的，有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了。功能类似于zookeeper。

• Eureka Server提供服务注册服务

  各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观地看到

• Eureka Client是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（周期30秒），如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除（默认90秒）。

• 三大角色

  Eureka Server：提供服务注册和发现

  Service Provider：服务提供方将自身服务注册到Eureka，从而使服务消费放能够找到

  Service Consumer：服务消费方从Eureka获取注册服务列表，从而能够消费服务

• Eureka的自我保护

  当EurekaServer节点在短时间内丢失过多客户端时，那么这个节点就会进入自我保护模式，一旦进入这个模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（即不会注销任何微服务），当网络恢复后，该EurekaServer节点会自动退出自我保护模式。

• 服务发现

  对于注册进Eureka里面的微服务，可以通过服务发现来获得该服务的信息

• Eureka对比Zookeeper

  著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）和P（分区容错性）。犹豫分区容错性是分布式系统必须要保证的，因此只能在A和C之间权衡。

  Zookeeper保证的是CP，Eureka保证 的是AP

  当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leade噬举。问题在于，选举leader的时间太长，30〜120s,且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长朗不可用是不能容忍的。

8、Ribbon

主要功能是提供客户端的软件负载均衡算法将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如超时、重试等。简单来说，就是在配置文件中列出负载均衡后面的所有机器，Ribbon会自动帮助你基于某种规则去连接这些机器。

• 核心组件IRule

  根据特定算法从服务列表中选取一个要访问的服务

  七种负载均衡算法：

  RoundRobinRule：轮询

  RandomRule：随机

  、、、

• 自定义负载均衡策略

9、Feign

一个声明式的Web服务客户端，是的编写web服务客户端变的非常容易，只需创建一个接口，然后在上面添加注解即可

10、Hystrix断路器

服务雪崩：多个微服务之间相互调用的时候，假设服务A调用服务B和服务C，服务B和服务C又调用其他 的服务，这就是所谓的扇出。如果扇出的链路上某个微服务的调用响应超时或者长时间不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统的崩溃，即所谓的雪崩效应

Hystrix：是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖会不可避免的调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整个服务的失败，避免级联故障，以提高分布式系统的弹性

断路器：本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个符合预期的，可处理的备选响应，而不是长时间的等待或者抛出调用方法处理的异常，这样就保证了服务调用方的线程不会被长时间的、不必要的占用，从而避免了故障在分布式系统中的蔓延乃至雪崩

• 服务熔断

  熔断机制是应对雪崩效应的一种微服务链路保护机制。

  当扇出链路的某个微服不可用或者响应时间太长时.会进行服务的降级，进而熔断该节点微服务的调用，快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。

• 服务降级

  整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来

  所谓降级，一般是从整体负荷考虑，就是当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值，这样做虽然服务水平会下降，但是好歹可用，比直接挂掉强！

• 服务监控HystrixDashboard

11、Zuul路由网关

Zuul包含了对请求的路由和过滤的两个最主要的功能

期中路由功能负责将外部的请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器的功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。

Zuul和Eureka进行整合，将Zull自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他微服务的消息，也就是以后访问微服务都是通过Zuul跳转后获得。

• 路由

  1、设置代理名称

  2、原真实服务名忽略

  3、设置统一的公共前缀

• 过滤

12、SpringCloud Confic的分布式配置中心

SpringCloud Confic为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同的微服务应用的所有环境提供了一个中心化的外部配置

• 如何使用？

  SpringCloud Confic分为服务端和客户端两部分

  服务端也叫分布式配置中心，他是一个独立的微服务应用，用来连接配置的服务器并为客户端提供获取配置信息，加密/解密等访问接口

  客户端则是通过指定的配置中心来管理这些应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用Git来存储配置信息，这样有助于对环境配置进行版本管理，并且可以通过Git客户端工具来方便的管理和访问配置内容。