分布式系统关键技术之流量与数据调度

迈不过友情╰ 2022-05-16 14:11 550阅读 0赞

![640?wx\_fmt=gif][640_wx_fmt_gif]

流量调度：不要将流量调度和服务治理混为一谈 (服务治理是流量调度的前提)；主要功能；关键技术。

状态数据调度：完整解决数据 Scale 问题的应该还是数据结点自身，相应的技术方案。

流量调度（是内部的，更是外部接入层的事；中心之外的事，边缘计算，类似于 CDN 上完成的事）

服务治理（内部系统、中心的事），所以两个还是应该分开的。

### 一、流量调度的主要功能： ###

1.自动地进行流量调度，提升整个系统的稳定性；

2.让系统应对爆品等突发事件时，在弹性计算扩缩容的较长时间窗口内 、底层资源消耗殆尽的情况下，保护系统平稳运行，提高系统架构的稳定性和高可用性。

此外，这个流量调度系统还可以完成以下几方面的事情。

**服务流控。服务发现、服务路由、服务降级、服务熔断、服务保护等。**

**流量控制。负载均衡、流量分配、流量控制、异地灾备（多活）等。**

**流量管理。协议转换、请求校验、数据缓存、数据计算等。**

这些都应该是一个 API Gateway （API网关）应该做的事。

### 二、流量调度的关键技术 ###

好的 API Gateway 需要具备以下的关键技术。

**1.高性能**。使用高性能的语言。

**2.扛流量**。需要使用集群技术，在集群内的各个结点中共享数据。像 Paxos、Raft、Gossip 这样的通讯协议 Gateway 需要部署在广域网上，集群的分组技术。

**3.业务逻辑**。简单的业务逻辑，像 AWS 的 Lambda 服务一样，可注入不同语言的简单业务逻辑。

**4.服务化**。通过 Admin API 来不停机地管理配置变更的，而不是通过一个.conf 文件来人肉地修改配置。

### 三、状态数据调度 ###

最难办的就是**有状态的服务**了，保存一些**数据**，**不能丢失**的，需要随服务一起调度的。

把问题转移到了**第三方服务**上， Java中没有状态，但是 **Redis 和 MySQL** 有状态。

所以，分布式系统架构中出问题的基本都是这些存储状态的服务。数据存储结点在 Scale 上比较困难，成了一个单点的瓶颈。

### 四、分布式事务一致性的问题 ###

要想让数据有高可用性，就得写多份数据，会导致数据一致性的问题；数据一致性的问题又会引发性能问题。

在**解决一致性问题**时，我们有一些技术方案。

Master-Slave 方案。

Master-Master 方案。

两阶段和三阶段提交方案。

Paxos 方案。

3 年前写的《分布式系统的事务处理》这篇文章。可看到各种不同方案的对比

![640?wx\_fmt=other][640_wx_fmt_other]

分布式系统事务基本上都是两阶段提交的变种。阿里的 TCC–Try–Confirm–Cancel，或是我在亚马逊见到的 Plan–Reserve–Confirm 的方式，通过**业务补偿，或在业务应用层**上做的分布式事务的玩法，基本上都是**两阶段提交**（或变种）。

**应用层**上解决**事务问题**，只有“**两阶段提交**”这样的方式，**数据层**解决事务问题，**Paxos 算法**则是不二之选。

### 五、数据结点的分布式方案 ###

数据存储结果有太多不同的 Scheme，有文件系统，有对象型的，有 Key-Value 式，有时序的，有搜索型的，有关系型的……这个“数据存储的动物园”中，基本上都在解决数据副本、数据一致性和分布式事务的问题。

比如：AWS 的 Aurora，改写了 MySQL 的 InnoDB 引擎。为了高可用的 SLA，写 6个副本。其不像MySQL 的通过 bin log 的数据复制，而是更为“惊艳”地复制 SQL 语句，使用各种 tricky 的方式来降低 latency。使用多线程并行、使用 SQL 操作的merge 等。

MySQL 官方也有 **MySQL Cluster** 的技术方案。MongoDB、国内的 PingCAP 的 TiDB、国外的 CockroachDB，还有阿里的 **OceanBase** 都是为了**解决大规模数据的写入和读取**的问题而出现的数据库软件。

**文件存储的**，需要分布式文件系统的支持。一个 **Kafka 或 ZooKeeper** 把数据存储到**文件系统上**。**结点有问题**时，**再启动**一个 Kafka 或ZooKeeper 的实例，也要把它们持久化的数据**搬迁到另一台机器上。**

（注意，虽然 Kafka 和 ZooKeeper 是 HA 的，数据会在不同的结点中进行复制，但是我们也应该搬迁数据，这样有利用于新结点的快速启动。否则，新的结点需要等待数据同步，这个时间会比较长，可能会导致数据层的其它问题。）

需要一个底层是分布式的文件系统，新的结点只做一个简单的远程文件系统的 mount 就可以把数据调度到另外一台机器上了。

解决**数据结点调度的方案**应该是**底层的数据结点**，业务层可以像操作单机数据库一样来操作分布式数据库，阿里的用于**分库分表的数据库中间件** TDDL 都会成为**过渡技术**。

#### 状态数据调度小结 ####

应用层上的分布式事务一致性，只有两阶段提交这样的方式。

底层存储可以解决这个问题的方式是通过一些像 Paxos、Raft 或是 NWR 这样的算法和模型来解决。

状态数据调度应该是由分布式存储系统来解决的，这样会更为完美。但是因为数据存储的Scheme 太多，所以，导致我们有各式各样的分布式存储系统，有文件对象的，有关系型数据库的，有 NoSQL 的，有时序数据的，有搜索数据的，有队列的……

状态数据调度应该是在 IaaS 层的数据存储解决的问题，而不是在 PaaS 层或者 SaaS层来解决的。有三种方案：

1.使用比较廉价的开源产品，如：NFS、Ceph、TiDB、CockroachDB、ElasticSearch、InfluxDB、MySQL Cluster 和 Redis Cluster 之类的；

2.另一种是用云计算厂商的方案。

3.如果不差钱的话，可以使用更为昂贵的商业网络存储方案。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

[640_wx_fmt_gif]: /images/20220503/9c53579be8884e8fa18ccfb937313d17.png
[640_wx_fmt_other]: /images/20220503/0c0ceed23e5d4b55a6d880dfd7563bd3.png
[640_wx_fmt_jpeg]: /images/20220503/efea179df7114a27a0d712b7662774a9.png