微服务架构中各层的高可用设计

我不是女神ヾ 2024-03-24 16:40 48阅读 0赞

## 典型的微服务架构 ##

![在这里插入图片描述][6bc29445330a429db092f25f065f35a4.png]

## 接入层&反向代理层 ##

![在这里插入图片描述][d38e199f69704682a6db1b029af15913.png]

## 网关层 ##

负责流控和熔断降级  
![在这里插入图片描述][b246da4eda094a6eaae57484743b9ced.png]

[https://blog.csdn.net/qq798280904/article/details/130026867][https_blog.csdn.net_qq798280904_article_details_130026867]

## RPC ##

![在这里插入图片描述][5bcd001cebc84ea18c722e3d3e53c8ac.png]

## Zookeeper ##

![在这里插入图片描述][8ead40f23c8543f0a33b99bb3193b622.png]  
Leader:  
主要承担了以下的功能

事务请求的唯一调度和处理者，保证集群事务处理的顺序性，所有 Follower 的写请求都会转给 Leader 执行，用来保证事务的一致性

集群内部各服务器的调度者：处理好事务请求后，会将数据广播同步到各个 Follower，统计 Follower 写入成功的数量，超过半数 Follower 写入成功，Leader 就会认为写请求提交成功，通知所有的 Follower commit 这个写操作，保证事后哪怕是集群崩溃恢复或者重启，这个写操作也不会丢失。

Follower:  
处理客户端非事务请求、转发事务请求给 leader 服务器

参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）

参与 Leader 选举的投票

可以看到由于只有一个 Leader，很显然，此 Leader 存在单点隐患，那么 ZK 是怎么解决此问题的呢，首先 Follower 与 Leader 会用心跳机制保持连接，如果 Leader 出现问题了（宕机或者因为 FullGC 等原因无法响应），Follower 就无法感知到 Leader 的心跳，就会认为 Leader 出问题了，于是它们就会发起投票选举，最终在多个 Follower 中选出一个 Leader 来（这里主要用到了 Zookeeper Atomic Broadcast，即 ZAB 协议，它是为 ZK 专门设计的一种支持崩溃恢复的一致性协议）  
详见  
[https://blog.csdn.net/qq798280904/article/details/129965877][https_blog.csdn.net_qq798280904_article_details_129965877]

## Redis ##

分片集群，所谓分片集群即将数据分片，每一个分片数据由相应的主节点负责读写，这样的话就有多个主节点来分担写的压力，并且每个节点只存储部分数据，也就解决了单机存储瓶颈的问题，但需要注意的是每个主节点都存在单点问题，所以需要针对每个主节点做高可用，整体架构如下  
![在这里插入图片描述][4b818b03cd5248e693617517468c7e63.png]

原理也很简单，在 Proxy 收到 client 执行的 redis 的读写命令后，首先会对 key 进行计算得出一个值，如果这个值落在相应 master 负责的数值范围（一般将每个数字称为槽，Redis 一共有 16384 个槽）之内，那就把这条 redis 命令发给对应的 master 去执行，可以看到每个 master 节点只负责处理一部分的 redis 数据，同时为了避免每个 master 的单点问题，也为其配备了多个从节点以组成集群，当主节点宕机时，集群会通过 Raft 算法来从从节点中选举出一个主节点。

## ES ##

![在这里插入图片描述][52fb0df788c648c5b21895a450f958f5.png]

创建了多个节点，分片（图中 P 为主分片，R 为副本分片）的优势就体现出来了，可以将分片数据分布式存储到其它节点上，极大提升了数据的水平扩展能力，同时每个节点都能承担读写请求，采用负载均衡的形式避免了单点的读写压力

ES 的写机制与 Redis 和 MySQL 的主从架构有些差别（后两者的写都是直接向 master 节点发起写请求，而 ES 则不是），所以这里稍微解释一下 ES 的工作原理

首先说下节点的工作机制，节点（Node）分为主节点（Master Node）和从结点（Slave Node），主节点的主要职责是负责集群层面的相关操作，管理集群变更，如创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点，主节点也只有一个，一般通过类 Bully 算法来选举出来，如果主节点不可用了，则其他从节点也可以通过此算法来选举以实现集群的高可用，任何节点都可以接收读写请求以达到负载均衡的目的

再说一下分片的工作原理，分片分为主分片（Primary Shard，即图中 P0，P1，P2）和副本分片（Replica Shard，即图中 R0，R1，R2），主分片负责数据的写操作，所以虽然任何节点可以接收读写请求，但如果此节点接收的是写请求并且没有写数据所在的主分片话，此节点会将写请求调度到主分片所在的节点上，写入主分片后，主分片再把数据复制到其他节点的副本分片上，以有两个副本的集群为例，写操作如下  
![在这里插入图片描述][185470be473b4c74a172a002670b04b4.png]

## kafka ##

![在这里插入图片描述][cd76072028184300ac7bd05cb497af18.png]

## mysql ##

数据量大了之后就要分库分表了，于是就有了多主，就像 Redis 的分片集群一样，需要针对每个主配备多个从  
![在这里插入图片描述][d8d8d43cfab1462894569241577d940d.png]

[6bc29445330a429db092f25f065f35a4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/ee16534782c94421842a1cc2bf2a9367.png
[d38e199f69704682a6db1b029af15913.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f788ef702ef944f189ff0a8a2cde823d.png
[b246da4eda094a6eaae57484743b9ced.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/8eb07a33d0c6409c8a00820635694ca9.png
[https_blog.csdn.net_qq798280904_article_details_130026867]: https://blog.csdn.net/qq798280904/article/details/130026867
[5bcd001cebc84ea18c722e3d3e53c8ac.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1a77c14b6d1d4552b4b5d883b192c39d.png
[8ead40f23c8543f0a33b99bb3193b622.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c4b3f89d4f7f43deb400bf22e3b40325.png
[https_blog.csdn.net_qq798280904_article_details_129965877]: https://blog.csdn.net/qq798280904/article/details/129965877
[4b818b03cd5248e693617517468c7e63.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f486909e35bb4b02b3043265dce4525f.png
[52fb0df788c648c5b21895a450f958f5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/c8b2550e9fe74b2eb844e623ac947b30.png
[185470be473b4c74a172a002670b04b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/f70c2cb7da9746e99a55356ad11c4b70.png
[cd76072028184300ac7bd05cb497af18.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/d264d7e266a34003b82c5ab240dda193.png
[d8d8d43cfab1462894569241577d940d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/24/1caa889c94a243eea02f689d65b99c10.png