微服务架构设计（一）------概述

最新推荐文章于 2024-10-03 10:45:00 发布

大风车转悠悠

最新推荐文章于 2024-10-03 10:45:00 发布

阅读量1.6k

点赞数

分类专栏：架构

本文链接：https://blog.csdn.net/qq_33189961/article/details/100888576

版权

架构专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文重要参考，创作基础：https://blog.csdn.net/zmbaliqq/article/details/84936551

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

微服务的兴起和移动应用快速发展相对应；不同于传统的软件架构和服务，微服务调用的参数接口具有更大的融合性和灵活性；

什么是微服务

“微”：狭义来讲就是小，可以是组件粒度小等。

“服务”：一定要区别于系统，服务是一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

找了以下两种解释：

1、微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。

2、微服务是一种软件架构风格，目标是将一个复杂的应用拆分成多个服务模块，每个模块专注单一业务功能对外提供服务，并可以独立编译及部署，同时各模块间互相通信彼此协作，组合为整体对外提供完整服务。由于每个模块都独立部署，各自拥有互不干扰的内存空间，模块之间无法直接调用所以需要借助 RPC （远程过程调用协议）或 HTTP 协议让各个模块之间传递通信报文及交换数据，实现远程调用整个通信管理的过程也是微服务架构重要的组成部分。

微服务架构就像是活字印刷术，每个文字模都可以看成是一个微服务，它可以独立地提供印刷服务，又可以将模块之间组合，最终形成一篇完整文章提供更为复杂的印刷服务

微服务与SOA区别

微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。

SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署。

什么样的项目适合微服务

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

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

微服务由来

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

为什么要使用微服务

在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。一个打车软件的架构图如下：

尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。

这种单体应用比较适合于小项目，优点是：

开发简单直接，集中式管理
基本不会重复开发
功能都在本地，没有分布式的管理开销和调用开销

当然它的缺点也十分明显，特别对于互联网公司来说：

开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
代码维护难：代码功能耦合在一起，新人不知道何从下手
部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
扩展性不够：无法满足高并发情况下的业务需求

所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。

比如，前面描述的系统可被分解为：

每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求。API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

早期的单体架构带来的问题

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

1.复杂性逐渐变高

比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

2.技术债务逐渐上升

公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

3.部署速度逐渐变慢

这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

4.阻碍技术创新

比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

5.无法按需伸缩

比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

微服务与单体架构区别

单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

微服务设计原则

单一职责原则

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

服务自治原则

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

轻量级通信原则

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

接口明确原则

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

微服务优势与缺点

特点

易于开发和维护

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

启动较快

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

局部修改容易部署

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

技术栈不受限

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

按需伸缩

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

缺点

运维要求较高

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

分布式的复杂性

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

接口调整成本高

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

重复劳动

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

微服务与垂直应用

MVC 模式构建的垂直应用非常适合项目初期，使用其能够方便地进行开发、部署、测试，但随着业务的发展与访问量的增加，垂直应用的问题也随之暴露出来，而微服务架构可以很好地解决这些问题。

代码维护：

垂直应用里大部分逻辑都部署在一个集中化、单一的环境或服务器中运行。垂直应用程序通常很大，由一个大型团队或多个团队维护。庞大的代码库可能给希望熟悉代码的开发人员增加学习成本还会让应用程序开发过程中使用的开发环境工具和运行容器不堪重负，最终导致开发效率降低，可能会阻止对执行更改的尝试。

微服务架构将这个庞大并且复杂的应用拆分成多个逻辑简单且独立的小应用，每个小应用交由不同的团队或开发人员维护，彼此之间互不干扰通过标准接口互相通信。对于希望熟悉代码的开发人员来说只需掌握他所负责的应用即可，这样做的好处是简单、快速、逻辑清晰

部署：

垂直应用需要处理一个庞大的应用程序，编译、部署需要花费很长时间，一个小的修眈就可能导致重新构建整个项目。

微服务架构中对其中某一个服务进行修改，只需重新编译、部署被改动的服务模块，即独立部署。

资源控制：

垂直应用里，当请求量过大导致单台服务器无法支撑时，一般会将垂直应用部署在多台服务器形成服务集群，井通过反向代理实现负载均衡集群中的每个服务必须部署完整的应用，但在实际业务需求中仅有部分功能使用频繁，但这种架构必须为不常用的功能分配计算资源。

微服务将提供功能的各服务拆分为多个服务模块，它具有天生的集群属性，能够轻松地根据用量部署。

例如：

系统中的消息功能使用频率占了整个系统的 90% ，而密码找回功能则只占到 2% 为了分解消息功能的压力，

以传统负载均衡的方式进行集群化时，每个服务必须为使用量只有 2% 的密码找回功能分配资源，这无疑造成了浪费。

在微服务架构中，消息功能使用率占据 90% ，则将消息模块多部署几个实例形成集群，而密码找回功能所在的用户模块只部署一个就可以了

稳定：

垂直应用中如果有个小的问题，就可能使整个系统崩溃。

微服务所拆分出的各个模块中，由于模块之间的搞合度很低，当发生问题时影响范围被固定在该模块本身，整个系统依然健全。

主流微服务框架介绍

Dubbo
Spring Cloud
Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）
Consul、etcd&etc.（微服务的模块）

模块拆分

将完整地使用本地调用方式的垂直应用拆分成多个微小的服务，每个服务模块负责提供各自独立的服务接口，并通过网络调用的方式将各个服务模块组织起来形成完整的微服务系统。

拆分逻辑
单模块
基础模块
复杂模块

拆分逻辑：

模块拆分是分布式微服务实施时的困难之，它将直接影响到系统的复杂度、团队协作、代码维护难度、硬件资源分配等方面模块拆分得越细，则能够更灵活地分配硬件资源与更方便地进行团队协作但这样也会增加系统复杂度与代码维护难度，在团队人数较少的情况下无疑增加了负担。拆分模块时需要以具体的业务需求与系统请求压力分布为出发点进行权衡取舍。

系统复杂度：

业务的复杂性决定了被拆分的模块之间必然存在一定的衣赖，模块被拆分得越细就意味着会产生更多的依赖关系，在拆分解辑的同时必然增加了整个系统的复杂度。

团队协作：

微服务天生由多模块组成，各个模块交由具体的专人负责，团队之间通过模块所暴露的服务进行协作拆分模块的同时也确定了团队协作的方式。

代码维护难度：

微服务能够解决在垂直应用中错综复杂的业务逻辑藕合在一起的维护困难问题，但也并不是将模块拆分得越细越好，过多的模块反而会增加工作量与代码维护难度。

硬件资源分配：

系统中存在请求压力不均衡的情况，模块拆分得越细，贝Jj 能更有针对性地为高压力模块分配更多的计算资橱，避免琅费。

单模块

为了设计出低搞合、高内聚的系统，需要确保每个模块都具有一定的独立性，每个模块只完成它所负责的业务功能，井且模块之间做到最少联系及接口简单模块之间的边界则是思考的重点。

单个模块内聚了相关性较强的功能，井且拥有独立的数据库（ ORM ）、单元测试、运行内存、业务逻辑处理等。可以将单个模块看成是一个完整的垂直应用，只是在输入（接受请求）、输出（结果输出）时有差别。

基础模块

一个复杂的业务功能需要依赖多个模块所提供的功能实现在进行模块拆分时需要提前对业务所性及的模块进行梳理。各个模块提供的服务具有一定的原子性，保持独立不重叠 …~ 将不需要依赖其他模块或依赖较少的模块抽象为基础模块，为更为复杂的业务逻辑做准备，提高复用性与扩展性。

复杂模块

为实现复杂业务将基础模块进行聚合重组时，每个模块对自身数据库操作事务的管理比较简单，但基于网络跨模块的二阶事务管理则会将整个过程变得无比复杂，并且耗费更多的资源，所以在进行模块拆分时且尽量规避二阶事务的产生。在无法避免分布式事务的情况下，可以采用 TCC (TryingConfirming Canceling ）补偿性事务解决方案实那才二阶事务的管理。

垂直应用在处理购物车或登录状态管理等功能时一般会基于 Session 实现，但在分布式架构下 Session 的共享与传递会增加整个系统的辑合度并且提高复杂性。模块在处理自身业务逻辑及服务调用时，尽量以无状态协议的角度进行设计，请求完立刻释放资源。维护状态的工作可由服务提供方增加状态检查的服务，但面对高查询、低修改的场景时可以基于约定交由公共缓存系统 Redis ）维护。

复杂的订单模块为了产生一张订单，需要用户模块提供的买卖双方信息，产品模块提供的货物信息，财务模块提供的账户余额、消息模块提供的短信通知等基础服务。

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

传统的开发方式，所有的服务都是本地的，UI可以直接调用。

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

提供统一服务入口，让微服务对前台透明
聚合后台的服务，节省流量，提升性能
提供安全，过滤，流控等API管理功能

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

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

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。这几种方式，展开来讲都可以写本书，而且大家一般都比较熟悉细节了，就不展开讲了。

REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）

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

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点：

客户端做：

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

服务端做：

优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

服务挂了怎么办？

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

重试机制
限流
熔断机制
负载均衡
降级（本地缓存）这些方法基本上都很明确通用，就不详细说明了

微服务需要考虑的问题

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

微服务重要部件

1. 微服务基本能力

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

3. 负载均衡

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

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

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

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

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

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

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查询。现在做的追踪功能还比较简单，这块还需要继续丰富。

参考：