分布式架构设计之接入层

1、定义

把跟客户端直连的服务器称为接入服务器，一个或多个接入服务器构成的接入层。

• 接入层作为用户（包括内部用户和外部用户）与关键服务器的隔离层，直接接收用户的请求，并转发给应用服务器
• 对于一个功能单一，用户少，并发小的系统，接入层的确没有必要独立出来。
• 接入服务器是直接更用户连接的，它直接影响用户体验。接入服务器故障或者是重启肯定会影响到用户，而其他业务模块故障或者重启则不一定会影响用户体验

2、优势

• 1、降低接入层与业务耦合度，减少地稳定度模块对高稳定度模块的不良影响。
• 2、使接业务层专注于业务处理，降低业务层设计的复杂度。
• 3、接入层专注于消息转发，可以有效降低消息的丢失率，从而提高系统的稳定性。
• 4、接入层以较小的代价大幅提高用户接入体验。

3、技术方案

网络延迟有什么要求？并发有多大？但消息平均长度多少？用户规模多少？用户地域分布是什么情况？用户的网络环境怎样？

3.1、考虑的问题（负载均衡和高可用）

1、负载均衡

• 采用一定的分配算法将网络请求分发到后端的多个服务器，从而获得更高的性能。实现负载均衡功能的软/硬件称为 负载均衡器 。本文中的负载均衡特指将客户的http请求分发到后端的web服务器或应用服务器。

2、高可用

• 为了避免负载调度器的单点故障，部署多个负载调度器节点，通过并行或主从的方式同时工作。

3、会话保持

• 会话服务器端维持的状态信息，使得服务器能够识别同一客户的多次请求之间的关联。会话保持是指负载均衡器上的一种机制，通过会话保持，负载均衡器能够识别同一客户端多次请求的关联性，并能够将相关联的请求分配到同一台后端服务器上。

4、配置灵活性

• 因为需要整合各应用系统的URL，对于子域名、虚拟目录等进行统一规划和分配，需要考虑配置的灵活性和分流策略的多样性。

3.2、设计方式

3.2.1、单个IP地址接入

流程：
1）浏览器通过DNS-server，域名解析到ip
2）浏览器通过ip访问web-server

缺点：
1）非高可用，web-server挂了整个系统就挂了
2）扩展性差，当吞吐量达到web-server上限时，无法扩容

3.2.2、多个IP地址随机接入

通过在DNS-server上对一个域名设置多个ip解析，来扩充web-server性能及实施负载均衡的技术

1、过程：

• 1）多部署几份web-server，1个tomcat抗1000，部署3个tomcat（Apache组织提供的一种Web服务器）就能抗3000
• 2）在DNS-server层面，域名每次解析到不同的ip

2、优点：

• 1）零成本：在DNS-server上多配几个ip即可，功能也不收费
• 2）部署简单：多部署几个web-server即可，原系统架构不需要做任何改造
• 3）负载均衡：变成了多机，但负载基本是均衡的

3、缺点：

• 1）非高可用：DNS-server只负责域名解析ip，这个ip对应的服务是否可用，DNS-server是不保证的，假设有一个web-server挂了，部分服务会受到影响
• 2）扩容非实时：DNS解析有一个生效周期
• 3）暴露了太多的外网ip

3.2.2、单IP地址 反向代理

1）站点层与浏览器层之间加入了一个反向代理层，利用高性能的nginx来做反向代理
2）nginx将http请求分发给后端多个web-server

优点：
1）DNS-server不需要动
2）负载均衡：通过nginx来保证
3）只暴露一个外网ip，nginx->tomcat之间使用内网访问
4）扩容实时：nginx内部可控，随时增加web-server随时实时扩容
5）能够保证站点层的可用性：任何一台tomcat挂了，nginx可以将流量迁移到其他tomcat

缺点：
1）时延增加+架构更复杂了：中间多加了一个反向代理层
2）反向代理层成了单点，非高可用

3.2.3、反向代理 高可用方案（keepalived）

keepalived：一款用来检测服务状态存活性的软件，常用来做高可用

1）做两台nginx组成一个集群，分别部署上keepalived，设置成相同的虚IP，保证nginx的高可用
2）当一台nginx挂了，keepalived能够探测到，并将流量自动迁移到另一台nginx上，整个过程对调用方透明

优点：
1）解决了高可用的问题
缺点：
1）资源利用率只有50%
2）nginx仍然是接入单点

3.2.4、水平扩展（Linux Virtual Server）

lvs：Linux Virtual Server，使用集群技术，实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器
　1）通过DNS轮询来线性扩展入口lvs层的性能
2）通过keepalived来保证高可用
3）通过lvs来扩展多个nginx
4）通过nginx来做负载均衡，业务七层路由

4、常见技术方法

4.1、反向代理和正向代理

4.1.1、代理（Proxy）

引出代理之前，首先介绍C/S架构，也即是Client-Server的架构。

对于请求量非常少的服务，这样的部署不会有什么问题，但如果这个服务请求量上来的时候，这样部署的架构就很有问题了。

• 首先一个很客观的问题：如果单从服务器的物理特性来看，这个服务器就不能支持这么高的请求量。这种情况下，就迫使开发者去把服务迁移到一个CPU更强、内存更高，综合性能更好的服务器。通过更换服务器当然可以解决这个问题。
• 第二个问题：如果服务Server单节点发生了故障，就必然会影响整个服务，因为对于众多的Client客户端都是连接的一个Server服务端。

基于代理的可横向拓展的C/S架构

在这个部署的架构当中，除了Server节点，还多出了一个叫“Proxy”的节点，那么这个节点是干嘛的呢？

“Proxy”的这个节点，它把他接收的所有的请求都转发到他后面的Server节点当中，然后等待Server节点处理请求，再从Server节点取回执行结果返回到Client。所以“Proxy”的这个节点，他实际上不处理任何的请求。

对于上述服务器性能不足的问题：假设Server节点S1性能到达瓶颈了，不能处理更多的请求了。我们可以添加Server节点S2，同时告诉“Proxy”节点，让他把部分原来转发到S1节点的请求转发到我这里来。这样子通过服务分流减少压力的方法就可以解决原来S1节点性能不足的问题了。

单点服务器挂掉了怎么办：还是考虑Server节点S1和S2，两者所能够提供的服务是一样的，假设某一个时候S1挂掉了，这时如果有“Proxy”节点的存在，并且“Proxy”节点能够察觉到S1挂掉了的话，那么让“Proxy”节点把原来要转发给S1节点的请求转发到S2进行处理就可以了，这样子通过服务冗余的方法就可以解决原来S1突然挂掉影响服务的问题。

“Proxy”节点相当于一个中介，或者说是一个代理，代理Client去寻找实际的Server节点去完成服务。这样子的模式在现实生活也非常常见，在买房子的时候，通常由房产中介帮助你完成和卖者之间的手续，而不需要你亲自去处理这些事情，你只需要协调好自己与中介之间的手续就好了，这里的中介，就和我们的“Proxy”节点所做的工作非常类似。

4.1.2、反向代理和正向代理

理解了什么是“代理”，离我们理解什么是“反向代理”就只差“反向”两个字了，与“反向”相对的，就是“正向”，本质上来讲，代理都是存在于Client和Server之间，但是由于性质不同，所以也分为这两种.

假设由A、B和C三人，他们之间存在借钱的关系。

对于正向代理，理解起来就是：

1、A需要钱，A知道C由很多钱，想向C借钱
2、但是A和C有矛盾，于是A想到通过B去借C借钱
3、B向C借到钱了，C不知道是A的存在
4、这样B就帮助A借到了Z的钱

在这个过程，B就充当了代理借钱的角色，并且是代替A去借钱的，这样就是正向代理。

接着是反向代理：

1、A需要钱，C有很多钱，A不知道C很多钱
2、A找B借钱
3、B知道C有很多钱
4、B向C借钱，并把借到的钱给A，而没有使用自己的钱借给A
5、A拿到钱以后，以为钱是B的，A不知道C的存在

在这个过程当中，B也充当了代理借钱的角色，不过这次不是代替A去借的，而是用C的钱借给A的，换言之即是代替C将钱借给了A，这就是反向代理。

两者区别

• 1、服务对象不同
  • 正向代理，代理的是客户端，也就是例子中的A，服务端不知道实际发起请求的客户端
  • 反向代理，代理的是服务端，也就是例子中的C，客户端不知道实际提供服务的服务端
  • 总括：正向代理隐藏真实客户端，反向代理隐藏真实服务端
• 2、安全模型不同
  • 正向代理允许客户端通过它访问任意网站并且隐藏客户端自身，因此必须采取安全措施以确保仅为授权的客户端提供服务
  • 反向代理都对外都是透明的，访问者并不知道自己访问的是代理，访问者不知道服务节点的存在，认为处理请求的就是代理节点

总而言之，正向代理是从客户端的角度出发，服务于局域网用户，以访问非特定的服务，其中最典型的例子就是翻墙；反向代理正好与此相反，从服务端的角度出发，服务于所有用户，隐藏实际的服务节点，服务节点的架构对用户透明，以代理节点统一对外服务。

4.2、负载均衡策略

常见的负载均衡算法

• 1、 轮询(Round-Robin)、
  • 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
• 2、 源地址 Hash（一致性哈希）、
  • 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器。
• 3、最少连接数
  • 根据服务器当前的连接情况进行负载均衡的，当请求到来时，会选取当前连接数最少的一台服务器来处理请求。由此也可以延伸出，根据服务器 CPU占用最少，根据单位时间内处理请求的效率高低等进行服务器选择。最小连接数法只是动态分配服务器的一种算法，通过各种维度的参数计算，可以找到适合不同场景的更均衡的动态分配服务器的方案。

4.3、限流

限流就是限制流量，就像你宽带包了1个G的流量，用完了就没了。通过限流，我们可以很好地控制系统的qps，从而达到保护系统的目的。

限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

常见以下限流算法：包括
1、计数器算法

• 有时我们还会使用计数器来进行限流，主要用来限制一定时间内的总并发数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流，是一种简单粗暴的总数量限流，而不是平均速率限流。

2、滑动窗口法（和TCP滑动窗口不太一样）
3、漏桶算法

• 漏桶一个固定容量的漏桶，按照固定常量速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝。漏桶可以看做是一个具有固定容量、固定流出速率的队列，漏桶限制的是请求的流出速率。

4、令牌桶算法

• 令牌桶是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌，填满了就丢弃令牌，请求是否被处理要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌。令牌桶中装的是令牌。

4.4、服务降级

服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的返回。

1、降级服务的特征

• 1、原因：整体负荷超出整体负载承受能力。
• 2、目的：保证重要或基本服务正常运行，非重要服务延迟使用或暂停使用
• 3、大小：降低服务粒度，要考虑整体模块粒度的大小，将粒度控制在合适的范围内
• 4、可控性：在服务粒度大小的基础上增加服务的可控性，后台服务开关的功能是一项必要配置（单机可配置文件，其他可领用数据库和缓存），可分为手动控制和自动控制。
• 5、次序：一般从外围延伸服务开始降级，需要有一定的配置项，重要性低的优先降级，比如可以分组设置等级1-10，当服务需要降级到某一个级别时，进行相关配置

2、降级预案
在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

• 1、一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
• 2、警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
• 3、错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
• 4、严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

3、服务降级分类

• 1、降级按照是否自动化可分为：自动开关降级（超时、失败次数、故障、限流）和人工开关降级（秒杀、电商大促等）。
• 2、降级按照功能可分为：读服务降级、写服务降级。
• 3、降级按照处于的系统层次可分为：多级降级。

4、自动降级分类

• 1、超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
• 2、失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
• 3、故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
• 4、限流降级：当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）

4.5、 服务熔断

服务熔断和电路熔断是一个道理，如果一条线路电压过高，保险丝会熔断，防止出现火灾，但是过后重启仍然是可用的。

而服务熔断则是对于目标服务的请求和调用大量超时或失败，这时应该熔断该服务的所有调用，并且对于后续调用应直接返回，从而快速释放资源，确保在目标服务不可用的这段时间内，所有对它的调用都是立即返回，不会阻塞的。再等到目标服务好转后进行接口恢复。

4.6、防雪崩

雪崩：
如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用。

针对造成服务雪崩的不同原因，可以使用不同的应对策略

• 1.流量控制
• 2，改进缓存模式
• 3，服务自动扩容
• 4，服务调用者降级服务

参考

1、https://www.jianshu.com/p/8cd069820f79
2、https://www.cnblogs.com/holbrook/archive/2012/10/16/2726915.html
3、https://www.cnblogs.com/baby123/p/5892168.html
4、https://www.cnblogs.com/brandonli/p/5221218.html
5、https://www.zhihu.com/question/24723688/answer/583903276
6、https://cloud.tencent.com/developer/article/1457494