微服务简介

微服务Microservices之父，马丁.福勒，对微服务大概的概述如下：

就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通在其常而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。

对于微服务问题有不同的、成套的"解决方案"，如

Dubbo + ZooKeeper
SpringCloud NetFlix
SpringCloud Alibaba
霸王硬上弓般的直接手撸http

他们将多个中间件、框架组合在一起，为构建微服务项目要面临的各种问题（网关、熔断、服务注册与发现等）提供成套的解决方案

SOA：面向服务体系架构微服务

服务治理，服务监控是关键

通信方式：http/rpc

rpc效率高

细嗦效率高

相关理论

CAP 理论

CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：

一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
可用性: 每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
分区容错性: 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。

P 是必须的，因此只能在 CP 和 AP 中选择

根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差

CP：满足一致性，分区容错的系统，通常性能不是特别高

AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

作为分布式服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。

Zookeeper 保证的是 CP ---> 满足一致性，分区容错的系统，通常性能不是特别高

Eureka 保证的是 AP ---> 满足可用性，分区容错的系统，通常可能对一致性要求低一些

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

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务

Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)

当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

BASE 理论

BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。

**基本可用：**在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。
**软状态：**允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。
**最终一致性：**data replications 经过一段时间达到一致性。

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

康威定律

中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构

注册中心-服务发现

zookeeper, eureka, nacos, consul

一般都分为server和client。每个服务实例都要有自己的服务名(服务id)，通常写在配置文件中

properties 复制代码

spring.application.name

服务中心server端要暴漏服务注册地址，client在配置文件中配置注册地址，在启动时向注册地址注册;

当服务调用发生时，注册中心要向client端提供服务列表（ribbon，不知道Dubbo是怎么样的)；

服务列表是谁在向中心获取？ribbon还是client？

服务注册中心，具有以下几个功能：

服务注册。
服务地址的管理。
服务动态感知。

配置中心

一个服务部署部署多个应用实例，每个实例都要单独修改配置文件的话太麻烦了，搞个配置中心统一管理；

配置中心也要集群，也要高可用等；

配置中心也要有版本管理，借助远程仓库（如github）

nacos
config
zookeeper

很多配置中心都集成注册中心，虽然springcloud 中config 和eruka分别担任这两个功能

springclou和hadoop，微服务和分布式概念上什么区别？一个是java组件一个是解决分布式计算？

服务调用

RPC方式： Dubbo，gRpc

Http方式: 朴素的http客户端， Ribbon,OpenFeign, Eureka-Client, Consul-Client

这里就比较复杂了，因为Ribbon就是基于朴素的Http，而feign和Eureka-Client, Consul-Client又集成了Ribbon，，，所以底层都是同一个Http包，但是集成了不同的功能、用法？是那个包，template又是哪个包？

主要问题

服务雪崩

不同服务之间相互依赖，假如一个被依赖的服务不能向上游的服务提供服务，则很可能造成雪崩效应，最后导致整个服务不可访问。

如订单->商品->库存这样的调用链，然后调用库存超时，导致整个超时

让我想起了流水线的游戏，突然拆掉一处导致生产线堵塞

关键词：调用链路

方案

出问题前预防：限流、主动降级、隔离

出问题后修复：熔断、被动降级

熔断_被动降级

降级处理："替身文学"，为服务准备一个挡灾的替身，当服务响应太慢时，与其等待正常响应，不如先返回"请稍后再试"这样的降级处理

比如现实生活中排队太长了，提前告诉排在后面的人"商品已卖完"

如果在某段时间内，调用某个服务非常慢甚至超时，就可以将这个服务熔断，后续其他服务再调用这个服务就直接返回，告诉其他服务："已经熔断了，你别调用我了，过段时间再来试下吧。"

熔断有个原则： 一段时间内，统计失败的次数或者失败请求的占比超过一定阈值，就进行熔断。

详细的原理如下图所示：

熔断原理图

下面是原理介绍：

6.3 统计请求的算法

请求访问到后台服务后，首先判断熔断开关是否打开。
如果熔断开关已打开，则表明当前请求不能被处理。
如果熔断开关未打开，则判断时间窗口是否已满。
如果时间窗口未满，则请求桶中的请求数加 1。
如果返回的响应有异常，则失败桶的失败数加 1，如果返回的响应没有异常，则成功桶的成功数加 1。
如果时间窗口（判断统计错误率）已满，则开始判断是否需要熔断。

6.4 熔断的恢复算法

当熔断后，开关切换到断开状态。
过一段时间后，开关切换为半断开状态（Half-Open）。半断开状态下，允许对应用程序的一定数量的请求可以去调用服务，如果调用成功，则认为服务可以正常访问了，于是将开关切换为闭合状态。
如果半断开状态下，还是有调用失败的情况，则认为服务还没有恢复，开关从半断开状态切换到断开状态。

6.5 统计失败率的时间窗口

时间窗口又分为固定窗口和滑动窗口。

固定时间窗口：

原理：固定时间内统计流量总量，超过阀值则限制流量。

缺陷：无法限制短时间之内的集中流量。

滑动窗口原理：

原理：统计的总时间固定，但时间段是滑动的。

缺陷：无法控制流量让它们更加平滑

时间窗口的原理图在这里：

统计失败率的时间窗口

时间窗口可以比喻为人坐在窗户边，看外面来往的车辆，一定时间内从窗户外经过的车辆。
每次请求，都会判断时间窗口是否已满（如5分钟），如果时间窗口已满，则重新开始计时，且清理请求数/成功数/失败数。
注意：第一次开始的起始时间默认为当前时间。

尝试恢复服务的时间窗口

开关为断开的状态，经过一定时间后，比如 1 分钟，设置为半断开的状态，尝试发送请求检测服务是否恢复。
如果已恢复，则切换状态为关闭状态。如果未恢复，则切换状态为断开的状态，经过 1 分钟后，重复上面的步骤。
这里的时间窗口可以根据环境的运行状态进行动态调整，比如第一次是 1 分钟，第二次是 3 分钟，第三次是 10 分钟。

中间件：

比如阿里系的 Sentinel（推荐），Netflix 的 Hystrix（已停止更新，维护阶段）。

限流、主动降级

服务降级：服务压力剧增的时候根据当前业务情况及流量对一些服务和页面有策略的降级，以此缓解服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务能得到正确的响应（如给一个默认的返回）

关闭边缘服务，以保证核心服务运行

对请求的流量进行控制，只放行部分请求，使服务能够承担不超过自己能力的流量压力。

常见限流算法有三种：时间窗口、漏桶算法、令牌桶算法。

漏桶算法

原理：按照一个固定的速率将流量露出到接收端。

缺陷：面对突发流量的时候，采用的解决方式是缓存在漏桶中，这样流量的响应时间就会增长，这就与互联网业务低延迟的要求不符。

令牌桶算法

原理：一秒内限制访问次数为 N 次。每隔 1/N 的时间，往桶内放入一个令牌。分布式环境下，用 Redis 作为令牌桶。原理图如下：

总结的思维导图在这里：

服务治理

分布式SOA环境下系统的依赖错综复杂。

服务治理主要分为两个方面：

服务管理
- 服务上线下线、服务路由、限流和降级、归组、机房规则、服务授权
相关信息的收集展示：
- 服务基本信息、容量和水准、依赖、调用统计、提供的方法和参数、负责人、统计报表
- 运行状态加监控

依赖管理

服务间互相调用，可能形成复杂的网状依赖

微服务基础理论