【Spring Cloud 3】分布式架构下的高可用设计与可伸缩设计

约定不等于承诺〃 2021-09-07 05:59 262阅读 0赞

# 第一章 分布式架构下的高可用设计 #

## 一、避免单点故障 ##

1.  负载均衡技术（failover、选址、硬件负载、去中心化的软件负载）
2.  热备
3.  多机房（同城容灾、异地容灾）

## 二、应用的高可用性 ##

1.  故障监控（系统监控（CPU、内存）、链路监控、日志监控）、自动预警
2.  应用的容错设计、服务降级、限流的自我保护
3.  数据量（数据分片、读写分离）

## 三、分布式架构下的可伸缩性设计 ##

1.  垂直甚至
2.  提升硬件能力
3.  水平伸缩
4.  增加服务器

## 四、加速静态内容访问速度 CDN ##

CDN 全称是 Content Delivery Network，中文释义是内容分发网络。

CDN 的作用是把用户需要的内容分发到离用户最近的地方进行响应，这样用户能够快速获取所需要的内容。

CDN 本质上就是一种网络缓存技术，能够把一些相对稳定的资源放到距离最终用户较近的地方，一方面可以节省整个广域网的带宽消耗，另外一方面也可以提升用户的访问速度、改善用户体验。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70][]

## 五、如何实现高可用 ##

### 1、入口层 ###

入口层，通常指Nginx和Apache等层面的东西，负责应用（不管是Web应用还是移动应用）的服务入口。我们通常会将服务定位在一个IP，如果这个IP对应的服务器当机了，那么用户的访问肯定会中断。此时，可以用keepalived来实现入口层的高可用。例如，机器A 的IP是 1.2.3.4，机器 B 的 IP 是 1.2.3.5, 那么再申请一个 IP 1.2.3.6（称为⼼跳IP）， 平时绑定在机器A上，如果A当机，IP会自动绑定在机器B上；如果B当机，IP会自动绑定在机器A上。对于这种形式，我们将DNS绑定到心跳IP上，即可实现入口层的高可用。

但这个方案有一点小问题。

第一，它的切换可能有一到两秒的中断，也就是说，如果不是要求到非常严格的毫秒级就不会有问题。

第二，对入口的机器会有些浪费，因为买了两台机器的入口，可能就只有一台机器用上。对一些长连接的应用可能会导致服务中断，这时候就需要客户端做配合做一些重新创建连接的工作。简单的说，对于比较普通的业务来说，这个方案就能解决一部分问题。

这里要注意，keepalived在使用上会有一些限制。

1.  两台机器必须在同一个网段，不再同一个网段，没有办法实现互相抢IP。
2.  内网服务也可以做心跳，但需要注意的是，以前为了安全我们会把内网服务绑定在内网IP上，避免出现安全问题。但为了使用keepalived，必须监听在所有IP上（如果监听在心跳IP上，那么机器没有持有该IP时，服务无法启动），简单的方案是启用 iptables, 避免内网服务被外网访问。
3.  服务器利用率下降，这时可以考虑做混合部署来改善这一点。

比较常见的一个错误是，如果有两台机器，两个公网IP，DNS上把域名同时定位到两个IP，就觉得已经做了高可用了。这完全不是高可用，因为如果一台机器当机，那么就有一半左右的用户无法访问。

除了keepalive，lvs也能用来解决入口层的高可用问题。不过，与keepalived相比，lvs会更复杂一些，门槛也会高一些。

### 2、业务层 ###

业务层通常是由PHP、Java、Python、Go等写的逻辑代码构成的，需要依赖于后台数据库及一些缓存层面的东西。如何实现业务层的高可用呢？最核心的就是，业务层不要有状态，将状态分散到缓存层和数据库。目前大家通常喜欢将以下几种数据放入业务层。

第一，session，即用户登录相关的数据，但好的做法是将session放在数据库里，或者一个比较稳定的缓存系统中。

第二，缓存，在访问数据库时，如果一个查询很慢，就希望将这些结果暂时放到进程里，下次再做查询时就不用访问数据库了。这种做法带来的问题是，当业务层服务器不只是一台时，数据很难做到一致，从缓存拿到的数据就可能是错误的。

一个简单的原则就是业务层不用有状态。

在业务层没有状态时，一台业务层服务器宕机了，Nginx/Apache会自动将所有的请求打到另外一台业务层的服务器上。由于没有状态，两台服务器没有任何差别，所以用户完全感受不到。如果把session放在业务层里面的话，那么面临的问题是，这个用户以前是登录在一台机器上的，这个进程死掉之后，用户就会被登出了。

友情提示：有一段时间比较流行cookie session，就是将session中的数据加密之后放在客户的cookie里，然后下发到客户端，这样也能做到与服务端完全无状态。但这里面有很多坑，如果能绕过这些坑就可以这样使用。

第一个坑是怎么保证加密的秘钥不泄露，一旦泄露就意味着攻击者可以伪造任何人的身份。

第二个坑是重放攻击，如何避免别人通过保存cookie去不停地尝试验证码，当然也还有一些其他的攻击手段。

如果没有好办法解决这两个问题，那么cookie session尽量别用，那么将session放在缓存中比放在cookie中要好一点。

### 3、缓存层 ###

非常简单的架构里是没有缓存这个概念的。但在访问量上来之后，MySQL之类的数据库扛不住了，比如在SATA盘里跑MySQL，QPS到达200、300甚至500时，MySQL的性能会大幅下降，这时就可以考虑用缓存层来挡住绝大部分服务请求，提升系统整体的容量。

缓存层做高可用一个简单的方法就是，将缓存层分得细一点儿。比如说，缓存层就一台机器的话，那么这台机器当了以后，所有应用层的压力就会往数据库里压，数据库扛不住的话，整个网站（或应用）就会随之当掉。而如果缓存层分在四台机器上的话，每台只有四分之一，这台机器当掉了以后，也只有总访问量的四分之一会压在数据库上面，数据库能扛住的话，网站就能很稳定地等到缓存层重新起来。在实践中，四分之一显然是不够的，我们会将它分得更细，以保证单台缓存当机后数据库还能撑得住即可。在中小规模下，缓存层和业务层可以混合部署，这样可以节省机器。

### 4、数据库层 ###

在数据库层面实现高可用，通常是在软件层面来做。例如，MySQL有主从模式(Master-Slave)，还有主主模式(Master-Master)都能满足需求。MongoDB也有ReplicaSet的概念，基本都能满足大家的需求。

总之，要想实现高可用，需要做到这几点：入口层做心跳，业务层服务器无状态，缓存层减小粒度，数据库做一个主从模式。对于这种模式来讲，我们做的高可用不需要太多服务器，这些东西都可以同时部署在两台服务器上。这时，两台服务器就能满足早期的高可用需求了。任何一台服务器当机用户完全无感知。

# 第二章 分布式架构下的可伸缩设计 #

## 一、可伸缩性/可扩展性(Scalable/scalability) ##

可伸缩性(可扩展性)是一种对软件系统计算处理能力的设计指标，高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够保证旺盛的生命力，通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。

可伸缩性和纯粹性能调优有本质区别， 可伸缩性是高性能、低成本和可维护性等诸多因素的综合考量和平衡，可伸缩性讲究平滑线性的性能提升，更侧重于系统的水平伸缩，通过廉价的服务器实现分布式计算；而普通性能优化只是单台机器的性能指标优化。他们共同点都是根据应用系统特点在吞吐量和延迟之间进行一个侧重选择，当然水平伸缩分区后会带来CAP定理约束。

软件的可扩展性设计非常重要，但又比较难以掌握，业界试图通过云计算或高并发语言等方式节省开发者精力，但是，无论采取什么技术，如果应用系统内部是铁板一块，例如严重依赖数据库，系统达到一定访问规模，负载都集中到一两台数据库服务器上，这时进行分区扩展伸缩就比较困难，正如Hibernate框架创建人Gavin King所说：关系数据库是最不可扩展的。

## 二、性能和扩展性 ##

*  什么是性能问题？ 如果你的系统对于一个用户访问还很慢，那就是性能问题；
 *  什么是扩展性问题？ 如果你的系统对一个用户来说是快的，但是在用户不断增长的高访问量下就慢了。

## 三、延迟和吞吐量 ##

延迟和吞吐量是衡量可扩展性的一对指标，我们希望获得低延迟和高吞吐量的系统架构。所谓低延迟，也就是用户能感受到的系统响应时间，比如一个网页在几秒内打开，越短表示延迟越低，而吞吐量表示同时有多少用户能够享受到这种低延迟，如果并发用户量很大时，用户感觉网页的打开速度很慢，这意味着系统架构的吞吐量有待提高。

扩展性的目标是用可接受的延迟获得最大的吞吐量。可靠性(可用性)目标：用可接受的延迟获得数据更新的一致性。

## 四、如何实现可伸缩 ##

### 1、入口层 ###

在入口层实现伸缩性，可以通过直接水平扩机器，然后DNS加IP来实现。但需要注意，尽管一个域名解析到几十个IP没有问题，但是很多浏览器客户端只会使用前几个IP,部分域名供应商对此有优化(如每次返回的IP顺序随机)，但这个优化效果不稳定。

推荐的做法是使用少量的Nginx机器作为入口，业务服务器隐藏在内网(HTTP类型的业务这种方式居多)。另外，也可以把所有IP下发到客户端，然后在客户端做一些调度(特别是非HTTP型的业务，如游戏、直播)。

### 2、业务层 ###

业务层的伸缩性如何实现?与做高可用时的解决方案一样，要实现业务层的伸缩性，保证无状态是很好的手段。此外，加机器继续水平部署即可。

### 3、缓存层 ###

比较麻烦的是缓存层的伸缩性，最简单粗暴的方式是什么呢？趁着半夜量比较低的时候，把整个缓存层全部下线，然后上线新的缓存层。新的缓存层启动起来之后，再等这些缓存慢慢预热。当然这里一个要求，你的数据库能抗住低估期的请求量。如果扛不住呢？取决于缓存类型，下面我们先可以将缓存的类型区分一下。

*  强一致性缓存：无法接受从缓存拿到错误的数据 (比如用户余额，或者会被下游继续缓存这种情形)
 *  弱一致性缓存：能接受在一段时间内从缓存拿到错误的数据 (比如微博的转发数)。
 *  不变型缓存：缓存key对应的value不会变更 (比如从SHA1推出来的密码， 或者其他复杂公式的计算结果)。

那什么缓存类型伸缩性比较好呢？弱一致性和不变型缓存的扩容很方便，用一致性Hash即可；强一致性情况稍微复杂一些，稍后再讲。使用一致性Hash，而不用简单Hash的原因是缓存的失效率。如果缓存从9台扩容到10台，简单Hash 情况下90%的缓存会马上失效，而如果使用一致性Hash情况，只有10%的缓存会失效。

那么，强一致性缓存会有什么问题？第一个问题是，缓存客户端的配置更新时间会有微小的差异，在这个时间窗内有可能会拿到过期的数据。第二个问题是，如果扩容之后再裁撤节点，会拿到脏数据。比如 a 这个key之前在机器1，扩容后在机器2，数据更新了，但裁撤节点后key回到机器1，这时候就会拿到脏数据。

要解决问题2比较简单，要么保持永不减少节点，要么节点调整间隔大于数据的有效时间。问题1可以用如下的步骤来解决：

1.  两套hash配置都更新到客户端，但仍然使用旧配置；
2.  逐个客户端改为只有两套hash结果一致的情况下会使用缓存，其余情况从数据库读，但写入缓存；
3.  逐个客户端通知使用新配置。

Memcache 设计得比较早，导致在伸缩性高可用方面的考虑得不太周到。Redis 在这方面有不少改进，特别是 @ngaut 团队基于 redis 开发了 codis 这个软件，一次性地解决了缓存层的绝大部分问题。推荐大家考察一下。

### 4、数据库 ###

在数据库层面实现伸缩，方法很多，文档也很多，此处不做过多赘述。大致方法为：水平拆分、垂直拆分和定期滚动。

总之，我们可以在入口层、业务层面、缓存层和数据库层四个层面，使用刚才介绍的方法和技术实现系统高可用和可伸缩性。具体为：在入口层用心跳来做到高可用，用平行部署来伸缩；在业务层做到服务无状态；在缓存层，可以减小一些粒度，以方便实现高可用，使用一致性Hash将有助于实现缓存层的伸缩性；数据库层的主从模式能解决高可用问题，拆分和滚动能解决可伸缩问题。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70 1][]

上一篇：[【Spring Cloud 2】软件架构设计][Spring Cloud 2]

下一篇：[SpringCloud学习总纲][SpringCloud]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70]: /images/20210813/fcb03f369347408aacd56143d225cb2d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70 1]: /images/20210813/6d7640abfcf84c53b1537f426eb2217c.png
[Spring Cloud 2]: https://blog.csdn.net/guorui_java/article/details/112093407
[SpringCloud]: https://blog.csdn.net/guorui_java/article/details/112055672