一、微服务介绍

1. 什么是微服务

2. 微服务由来

3. 为什么需要微服务？

3.1 最期的单体架构带来的问题

3.2 微服务与单体架构区别

3.3 微服务与SOA区别

4. 微服务本质

5. 什么样的项目适合微服务

6. 微服务折分与设计

6.1 微服务设计原则

7. 微服务优势与缺点

7.1 特性

7.2 特点

7.3 缺点

8. 微服务开发框架

9. Sprint cloud 和 Sprint boot区别

二、微服务实践先知

1. 客户端如何访问这些服务？（API Gateway）

2. 服务之间如何通信？（服务调用）

3. 这么多服务怎么查找？（服务发现）

4. 服务挂了怎么办？

5. 微服务需要考虑的问题

三、微服务重要部件

1. 微服务基本能力

2. 服务注册中心

2.1 zookeeper服务注册和发现

3. 负载均衡

3.1 负载均衡的常见策略

4. 容错

4.1 容错策略

5. 熔断

6. 限流和降级

7. SLA

8. API网关

9. 多级缓存

10. 超时和重试

11. 线程池隔离

12. 降级和限流

13. 网关监控和统计

一、微服务介绍

1. 什么是微服务

维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

2. 微服务由来

微服务的提出者是马丁福勒；他在论文中这样描述到，

While there is no precise definition of this architectural style

就目前而言，对于微服务业界并没?有一个统一的、标准?的定义

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

3. 为什么需要微服务？

当组织开始构建更复杂的应用程序时，编写单体应用程序的做法变得越来越成问题，微服务就应运而生。传统上，应用程序是作为单体构建的，所有代码都集中在一个大的代码库中。由于没有明确区分不同功能，因此更新应用程序的一部分时，可能会无意中影响到完全不相关的功能。即使进行简单的更改，你也必须重新部署整个应用程序，如果出现问题，则所有内容都会受到影响，而不仅仅是要被更新或扩展的组件。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间.基于微服务的体系结构是一种更具说明性的SOA类型，它源于现实世界的用例，并已被众多组织成功采用。

3.1 最期的单体架构带来的问题

在早期，单体架构的这种扩展方式可以很好的满足使用需求，但随着时间的推移，这种方式就会产生很多问题，具体表现如下：

1.应用复杂度增加，更新、维护困难

一个简单的应用会随着时间的推移而逐渐变大。一旦应用变的庞大而又复杂，那么开发团队将会面临很多问题，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都很难进行二次开发或维护。

2.易造成系统资源浪费

虽然使用负载均衡的方式可以对项目中的服务容量进行水平扩展，但由于传统单体架构的代码中只有一个包含所有功能的WA R包，所以在对服务容量扩容时，只能选择重复的部署这个WA R包来扩展服务能力，而不仅仅是扩展了所需的服务。这样导致其他不需要扩展的服务也进行了相应的扩展，但这种扩展是不需要的，因此这种方式会极大的浪费资源。

3.影响开发效率

当一个应用越大时，启动时间就会越长。开发和调试的过程中，如果有很大一部分时间都要在等待中渡过，那么必然会对开发效率有极大的影响。

4.应用可靠性低

传统单体应用架构在运行时的可靠性比较低，当所有模块都运行在一个进程中时，如果任何一个模块中出现了一个Bug，可能会导致整个进程崩溃，从而影响到整个应用。

5.不利于技术的更新

传统单体应用架构一旦选定使用某些技术，则后期的开发和扩展将在这些技术的基础上实现。如果需要更改某种技术，则可能需要将整个应用全部重新开发，这种成本是非常大的。当然，传统单体应用架构的问题还不只这些，但出现这些问题的根本原因可以说就是由于传统单体架构中一个WA R包内包含了系统的所有服务功能所导致的。随着业务变的越来越多，问题也就越来越多。

3.2 微服务与单体架构区别

单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

3.3 微服务与SOA区别

首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

3.4 微服务的优缺点

优点：

1.高内聚的目标模块方法--专注于一个业务功能；
2.开发简单，易于维护，效率高；
3.无语言的限制实现；低耦合的特性；
4.特殊的：微服务只是业务逻辑的代码，不会与 Html.css 和其他界面组件混合；
5.微服务有自己的数据库，自己存储数据库的能力，也可以是用统一的数据库；

缺点：

1.开发人员的系统的复杂性（处理分布式）
2.多个服务包的增多，运维压力增大；

也就是我们分布式要解决的：

系统环境版本依赖，
服务之间的通信响应
数据一致性
性能，并发，稳定性

4. 微服务本质

微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

参考维基百科英文版，简单梳理后的微服务出现的历史：

2005年：Dr. PeterRodgers在Web ServicesEdge大会上提出了“Micro-Web-Services”的概念。
2011年：一个软件架构工作组使用了“microservice”一词来描述一种架构模式。
2012年：同样是这个架构工作组，正式确定用“microservice”来代表这种架构。
2012年：ThoughtWorks的James Lewis针对微服务概念在QCon San Francisco 2012发表了演讲。
2014年：James Lewis和Martin Flower合写了关于微服务的一篇学术性的文章，详细阐述了微服务。

顺便说一句，这几个人都是大名鼎鼎的，名字可能陌生，但是摆出他们的作品，相信多少是有些了解的。 Martin Flower是《重构》、《UML 精粹》的作者；Robert Martin，人称 Bob 大叔，敏捷专家，《代码整洁之道》、《架构整洁之道》的作者。既然微服务是SOA架构的一种变体，那么，谈微服务，SOA就是一个跨不过去的一个话题。

5. 什么样的项目适合微服务

5.1 适合做成微服务的项目特点

微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

能不能做成微服务，取决于四个要素：

小：微服务体积小，2 pizza 团队。
独：能够独立的部署和运行。
轻：使用轻量级的通信机制和架构。
松：为服务之间是松耦合的。

5.2 微服务的设计原则：

1、单一职责原则

2、服务自治原则

3、轻量级通信原则

4、接口明确原则

6. 微服务折分与设计

从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节
拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

6.1 微服务设计原则

单一职责原则

意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

服务自治原则

意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

轻量级通信原则

首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

接口明确原则

由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

7. 微服务优势与缺点

7.1 特性

每个微服务可独立运行在自己的进程里；
一系列独立运行的微服务共同构建起了整个系统；
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

7.2 特点

易于开发和维护

由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。

启动较快

这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。

局部修改容易部署

在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。

技术栈不受限

比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。

按需伸缩

我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。

7.3 缺点

运维要求较高

对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

分布式的复杂性

对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

接口调整成本高

比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

重复劳动

对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

8. 微服务开发框架

目前微服务的开发框架，最常用的有以下四个：

Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
Dubbo：http：//dubbo.io
Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
Consul、etcd&etc.（微服务的模块）

9. Sprint cloud 和 Sprint boot区别

9.1 含义不同

springboot：一个快速开发框架，它简化了传统MVC的XML配置，使配置变得更加方便、简洁。

springcloud：是建立在SpringBoot上的服务框架，进一步简化了配置，它整合了一全套简单、便捷且通俗易用的框架。

9.2 作用不同

springboot：为了提供一个默认配置，从而简化配置过程。

springcloud：为了给微服务提供一个综合管理框架。

9.3 使用方式不同

springboot：可以单独使用。

springcloud：springcloud必须在springboot使用的前提下才能使用。

9.4 特征不同

springboot：

spring应用：通过调用静态 run（）方法创建独立的 Spring 应用程序。
Web应用程序：我们可以使用嵌入式Tomcat，Jetty或Undertow创建HTTP服务器。无需部署 WAR 文件。
外化配置：弹簧启动也提供基于产品的应用程序。它在不同的环境中也同样有效。
安全性：它是安全的，内置于所有HTTP端点的基本身份验证中。
应用程序事件和监听器：Spring Boot必须处理许多任务，应用程序所需的事件。添加用于创建工厂文件的侦听器。

springcloud：

智能路由和服务发现：在创建微服务时，有四个服务很重要。服务发现就是其中之一。这些服务相互依赖。
服务到服务调用：要连接所有具有序列的从属服务，请注册以调用终端节点。
负载均衡：将网络流量适当分配到后端服务器。
领导选举：应用程序作为第三方系统与另一个应用程序一起使用。
全局锁定：两个线程不能同时访问同一资源。
分布式配置和分布式消息传递

二、微服务实践入门需知

1. 客户端如何访问这些服务？（API Gateway）

传统的开发方式，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括

提供统一服务入口，让微服务对前台透明
聚合后台的服务，节省流量，提升性能
提供安全，过滤，流控等API管理功能
我的理解其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

2. 微服务中的服务之间如何通信？

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。

REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）
异步消息调用(Kafka, Notify)

RESTful API ：现在前后端分离比较流行，RESTful API 大家应该都比较熟悉。REST 是一种使用 HTTP 协议的进程间通信机制，一般使用 Json 来传递数据;
gRPC ：是一个高性能、开源和通用的 RPC 框架，基于 ProtoBuf ( Protocol Buffers ) 序列化协议开发，支持众多开发语言。面向服务端和移动端，基于 HTTP/2 设计，带来诸如双向流、流控、头部压缩、单 TCP 连接上的多复用请求等特性;
异步消息：使用消息中间件来实现，比如 RabbitMQ、Kafka 等。

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

3. 这么多服务怎么查找？（服务发现）

服务发现是微服务架构中关键的组成部分，服务发现说白了就是客户端怎么找到服务端的地址（ip和端口），这个问题可以很简单也可以很复杂，这里主要介绍服务发现的大致原理。

下面通过大家接触最多的场景：访问网页的过程讲解服务发现。

网络通讯的前提条件

所有的网络应用，客户端和服务端通讯的前提条件就是客户端得知道服务端的ip地址和端口号，例如：你要访问一个网页，浏览器得知道网页服务器的ip和端口号是多少，才可以向网页服务器发送请求，最终取回网页内容进行展示。

3.1 dns服务发现

我们平时打开网页的时候，记住的是域名，不知道服务器ip和端口，但是浏览器通讯必须要服务器的ip地址和端口，这个时候浏览器会借助dns服务器，用域名作为请求参数，去dns服务器查询域名对应的ip地址，过程如下图。

通过域名去dns服务器查询服务器ip地址的过程就叫dns服务发现，就是通过dns服务器，发现了web服务的地址。

说明：通过dns服务器只能查询域名对应的ip地址，没有端口号，不过对于http协议默认端口就是80，https对应的是443，所以浏览器可以确定网页服务器的端口号。

3.2 注册中心

基于注册中心的服务发现，就好比如存在一个地方，集中登记所有的服务地址信息，需要的时候去注册中心查询服务地址即可，注册中心提供了服务健康检查，发现服务异常了，就自动剔除掉对应的服务地址。

流程说明：

首先服务启动的时候，主动往注册中心，注册自己的服务名和地址信息。
客户端通过服务名，到注册中心查询服务的地址。
客户端通过地址连接服务，进行通信。

当然注册中心也支持，主动将变化的服务地址信息推送到客户端，客户端在本地就可以查询服务地址。

注册中心通常也支持服务健康检查，如果注册中心发现某个服务地址异常了，就会剔除无效的地址。

到目前为止有不少成熟的开源软件，例如：consul、etcd、ZooKeeper都可以实现服务发现，其中consul是专门针对注册中心实现，后续教程会专门讲解如何使用开源方案实现服务发现。

4. 服务挂了怎么办？

分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。我们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升时，导致数据库load彪高，影响了所在应用的性能，从而影响所有调用这个应用服务的前台应用。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

重试机制
限流
熔断机制
负载均衡
降级（本地缓存）这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

5. 微服务需要考虑的问题

API Gateway
服务间调用
服务发现
服务容错
服务部署
数据调用

三、微服务重要部件

1. 微服务基本能力

2. 服务注册中心

服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。

服务注册中心是服务发现的核心。它保存了各个可用服务实例的网络地址（IPAddress和Port）。服务注册中心必须要有高可用性和实时更新功能。上面提到的 Netflix Eureka 就是一个服务注册中心。它提供了服务注册和查询服务信息的REST API。服务通过使用POST请求注册自己的IPAddress和Port。每30秒发送一个PUT请求刷新注册信息。通过DELETE请求注销服务。客户端通过GET请求获取可用的服务实例信息。 Netflix的高可用（Netflix achieves high availability ）是通过在Amazon EC2运行多个实例来实现的,每一个Eureka服务都有一个弹性IP Address。当Eureka服务启动时，有DNS服务器动态的分配。Eureka客户端通过查询 DNS来获取Eureka的网络地址（IP Address和Port）。一般情况下，都是返回和客户端在同一个可用区Eureka服务器地址。其他能够作为服务注册中心的有：

etcd —– 高可用，分布式，强一致性的，key-value，Kubernetes和Cloud Foundry都是使用了etcd。
consul —–一个用于discovering和configuring的工具。它提供了允许客户端注册和发现服务的API。Consul可以进行服务健康检查，以确定服务的可用性。
zookeeper —— 在分布式应用中被广泛使用，高性能的协调服务。 Apache Zookeeper 最初为Hadoop的一个子项目，但现在是一个顶级项目。

2.1 zookeeper服务注册和发现

简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。如下图所示：

具体来说，zookeeper就是个分布式文件系统，每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port}, 比如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条目录：分别为/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。

zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.19.20.01:16888。

服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。

更为重要的是zookeeper 与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。

3. 负载均衡

服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务。此时客户端进行服务的负载均衡。

3.1 负载均衡的常见策略

3.1.1 随机

把来自网络的请求随机分配给内部中的多个服务器。

3.1.2 轮询

每一个来自网络中的请求，轮流分配给内部的服务器，从1到N然后重新开始。此种负载均衡算法适合服务器组内部的服务器都具有相同的配置并且平均服务请求相对均衡的情况。

3.1.3 加权轮询

根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

3.1.4 IP Hash

这种方式通过生成请求源IP的哈希值，并通过这个哈希值来找到正确的真实服务器。这意味着对于同一主机来说他对应的服务器总是相同。使用这种方式，你不需要保存任何源IP。但是需要注意，这种方式可能导致服务器负载不平衡。

3.1.5 最少连接数

客户端的每一次请求服务在服务器停留的时间可能会有较大的差异，随着工作时间加长，如果采用简单的轮循或随机均衡算法，每一台服务器上的连接进程可能会产生极大的不同，并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录，记录当前该服务器正在处理的连接数量，当有新的服务连接请求时，将把当前请求分配给连接数最少的服务器，使均衡更加符合实际情况，负载更加均衡。此种均衡算法适合长时处理的请求服务，如FTP。

4. 容错

容错，这个词的理解，直面意思就是可以容下错误，不让错误再次扩张，让这个错误产生的影响在一个固定的边界之内，“千里之堤毁于蚁穴”我们用容错的方式就是让这种蚁穴不要变大。那么我们常见的降级，限流，熔断器，超时重试等等都是容错的方法。

在调用服务集群时，如果一个微服务调用异常，如超时，连接异常，网络异常等，则根据容错策略进行服务容错。目前支持的服务容错策略有快速失败，失效切换。如果连续失败多次则直接熔断，不再发起调用。这样可以避免一个服务异常拖垮所有依赖于他的服务。

4.1 容错策略

4.1.1 快速失败

服务只发起一次待用，失败立即报错。通常用于非幂等下性的写操作

4.1.2 失效切换

服务发起调用，当出现失败后，重试其他服务器。通常用于读操作，但重试会带来更长时间的延迟。重试的次数通常是可以设置的

4.1.3 失败安全

失败安全，当服务调用出现异常时，直接忽略。通常用于写入日志等操作。

4.1.4 失败自动恢复

当服务调用出现异常时，记录失败请求，定时重发。通常用于消息通知。

4.1.5 forking Cluster

并行调用多个服务器，只要有一个成功，即返回。通常用于实时性较高的读操作。可以通过forks=n来设置最大并行数。

4.1.6 广播调用

广播调用所有提供者，逐个调用，任何一台失败则失败。通常用于通知所有提供者更新缓存或日志等本地资源信息。

5. 熔断

熔断技术可以说是一种“智能化的容错”，当调用满足失败次数，失败比例就会触发熔断器打开，有程序自动切断当前的RPC调用,来防止错误进一步扩大。实现一个熔断器主要是考虑三种模式，关闭，打开，半开。各个状态的转换如下图。

我们在处理异常的时候，要根据具体的业务情况来决定处理方式，比如我们调用商品接口，对方只是临时做了降级处理，那么作为网关调用就要切到可替换的服务上来执行或者获取托底数据，给用户友好提示。还有要区分异常的类型，比如依赖的服务崩溃了，这个可能需要花费比较久的时间来解决。也可能是由于服务器负载临时过高导致超时。作为熔断器应该能够甄别这种异常类型，从而根据具体的错误类型调整熔断策略。增加手动设置，在失败的服务恢复时间不确定的情况下，管理员可以手动强制切换熔断状态。最后，熔断器的使用场景是调用可能失败的远程服务程序或者共享资源。如果是本地缓存本地私有资源，使用熔断器则会增加系统的额外开销。还要注意，熔断器不能作为应用程序中业务逻辑的异常处理替代品。

有一些异常比较顽固，突然发生，无法预测，而且很难恢复，并且还会导致级联失败（举个例子，假设一个服务集群的负载非常高，如果这时候集群的一部分挂掉了，还占了很大一部分资源，整个集群都有可能遭殃）。如果我们这时还是不断进行重试的话，结果大多都是失败的。因此，此时我们的应用需要立即进入失败状态(fast-fail)，并采取合适的方法进行恢复。

我们可以用状态机来实现CircuitBreaker，它有以下三种状态：

关闭( Closed )：默认情况下Circuit Breaker是关闭的，此时允许操作执行。CircuitBreaker内部记录着最近失败的次数，如果对应的操作执行失败，次数就会续一次。如果在某个时间段内，失败次数（或者失败比率）达到阈值，CircuitBreaker会转换到开启( Open )状态。在开启状态中，Circuit Breaker会启用一个超时计时器，设这个计时器的目的是给集群相应的时间来恢复故障。当计时器时间到的时候，CircuitBreaker会转换到半开启( Half-Open )状态。
开启( Open )：在此状态下，执行对应的操作将会立即失败并且立即抛出异常。
半开启( Half-Open )：在此状态下，Circuit Breaker会允许执行一定数量的操作。如果所有操作全部成功，CircuitBreaker就会假定故障已经恢复，它就会转换到关闭状态，并且重置失败次数。如果其中任意一次操作失败了，Circuit Breaker就会认为故障仍然存在，所以它会转换到开启状态并再次开启计时器（再给系统一些时间使其从失败中恢复）

6. 限流和降级

保证核心服务的稳定性。为了保证核心服务的稳定性，随着访问量的不断增加，需要为系统能够处理的服务数量设置一个极限阀值，超过这个阀值的请求则直接拒绝。同时，为了保证核心服务的可用，可以对否些非核心服务进行降级，通过限制服务的最大访问量进行限流，通过管理控制台对单个微服务进行人工降级

7. SLA

SLA：Service-LevelAgreement的缩写，意思是服务等级协议。是关于网络服务供应商和客户间的一份合同，其中定义了服务类型、服务质量和客户付款等术语。典型的SLA包括以下项目：

分配给客户的最小带宽；
客户带宽极限；
能同时服务的客户数目；
在可能影响用户行为的网络变化之前的通知安排；
拨入访问可用性；
运用统计学；
服务供应商支持的最小网络利用性能，如99.9%有效工作时间或每天最多为1分钟的停机时间；
各类客户的流量优先权；
客户技术支持和服务；
惩罚规定，为服务供应商不能满足 SLA需求所指定。

8. API网关

这里说的网关是指API网关，直面意思是将所有API调用统一接入到API网关层，有网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短链接支持、容错能力。有了网关之后，各个API服务提供团队可以专注于自己的的业务逻辑处理，而API网关更专注于安全、流量、路由等问题。

9. 多级缓存

最简单的缓存就是查一次数据库然后将数据写入缓存比如redis中并设置过期时间。因为有过期失效因此我们要关注下缓存的穿透率，这个穿透率的计算公式，比如查询方法queryOrder(调用次数1000/1s)里面嵌套查询DB方法queryProductFromDb(调用次数300/s)，那么redis的穿透率就是300/1000,在这种使用缓存的方式下，是要重视穿透率的，穿透率大了说明缓存的效果不好。还有一种使用缓存的方式就是将缓存持久化，也就是不设置过期时间，这个就会面临一个数据更新的问题。一般有两种办法，一个是利用时间戳，查询默认以redis为主，每次设置数据的时候放入一个时间戳，每次读取数据的时候用系统当前时间和上次设置的这个时间戳做对比，比如超过5分钟，那么就再查一次数据库。这样可以保证redis里面永远有数据，一般是对DB的一种容错方法。还有一个就是真正的让redis做为DB使用。就是图里面画的通过订阅数据库的binlog通过数据异构系统将数据推送给缓存，同时将将缓存设置为多级。可以通过使用jvmcache作为应用内的一级缓存，一般是体积小，访问频率大的更适合这种jvmcache方式，将一套redis作为二级remote缓存，另外最外层三级redis作为持久化缓存。

10. 超时和重试

超时与重试机制也是容错的一种方法，凡是发生RPC调用的地方，比如读取redis，db，mq等，因为网络故障或者是所依赖的服务故障，长时间不能返回结果，就会导致线程增加，加大cpu负载，甚至导致雪崩。所以对每一个RPC调用都要设置超时时间。对于强依赖RPC调用资源的情况，还要有重试机制，但是重试的次数建议1-2次，另外如果有重试，那么超时时间就要相应的调小，比如重试1次，那么一共是发生2次调用。如果超时时间配置的是2s，那么客户端就要等待4s才能返回。因此重试+超时的方式，超时时间要调小。这里也再谈一下一次PRC调用的时间都消耗在哪些环节，一次正常的调用统计的耗时主要包括： ①调用端RPC框架执行时间 + ②网络发送时间 + ③服务端RPC框架执行时间 + ④服务端业务代码时间。调用方和服务方都有各自的性能监控，比如调用方tp99是500ms，服务方tp99是100ms，找了网络组的同事确认网络没有问题。那么时间都花在什么地方了呢，两种原因，客户端调用方，还有一个原因是网络发生TCP重传。所以要注意这两点。

11. 线程池隔离

在抗量这个环节，Servlet3异步的时候，有提到过线程隔离。线程隔离的之间优势就是防止级联故障，甚至是雪崩。当网关调用N多个接口服务的时候，我们要对每个接口进行线程隔离。比如，我们有调用订单、商品、用户。那么订单的业务不能够影响到商品和用户的请求处理。如果不做线程隔离，当访问订单服务出现网络故障导致延时，线程积压最终导致整个服务CPU负载满。就是我们说的服务全部不可用了，有多少机器都会被此刻的请求塞满。那么有了线程隔离就会使得我们的网关能保证局部问题不会影响全局。

12. 降级和限流

关于降级限流的方法业界都已经有很成熟的方法了，比如FAILBACK机制，限流的方法令牌桶，漏桶，信号量等。这里谈一下我们的一些经验，降级一般都是由统一配置中心的降级开关来实现的，那么当有很多个接口来自同一个提供方，这个提供方的系统或这机器所在机房网络出现了问题，我们就要有一个统一的降级开关，不然就要一个接口一个接口的来降级。也就是要对业务类型有一个大闸刀。还有就是降级切记暴力降级，什么是暴力降级的，比如把论坛功能降调，结果用户显示一个大白板，我们要实现缓存住一些数据，也就是有托底数据。限流一般分为分布式限流和单机限流，如果实现分布式限流的话就要一个公共的后端存储服务比如redis，在大nginx节点上利用lua读取redis配置信息。我们现在的限流都是单机限流，并没有实施分布式限流。

13. 网关监控和统计

API网关是一个串行的调用，那么每一步发生的异常要记录下来，统一存储到一个地方比如elasticserach中，便于后续对调用异常的分析。鉴于公司docker申请都是统一分配，而且分配之前docker上已经存在3个agent了，不再允许增加。我们自己实现了一个agent程序，来负责采集服务器上面的日志输出，然后发送到kafka集群，再消费到elasticserach中，通过web查询。现在做的追踪功能还比较简单，这块还需要继续丰富。