聊聊分布式的可扩展性

前言

樱花灿烂的季节，满地的绿叶攀上指尖。

春天，总是容易萌生懵懂的心理。。。这就是一堆人辞职的理由？？？

团队，总会有人离开，总会有人加入。。。总会有一个leader，当服务器的数量增加的时候，业务增加的时候，总会进行相关的扩容或者缩容，那么这个团队的扩展性如何？

增加了更多的事儿，leader是否能抗住？是否能分配所有的任务？是否能进行负载均衡？是否能对下属进行状态监控？在有人离职的时候，交接的任务是否很多？新来的人刚上线的时候，负载为0，大量的任务压来会不会直接把新人的IO耗尽。。。。

这种团队的架构和分布式系统感觉。。。一样一样的。。。

分布式的扩展性

分布式，是个系统都喜欢冠名为分布式系统，毕竟也是属于高大上的名词。。。

说到分布式，凭什么你的扩展性就好？凭什么你就没有性能瓶颈？

你是分布式，不同的节点分布在不同的host上就是分布式了？你是分布式就扩展性好了？未必吧。。。

那么扩展性从哪几个方面来进行考虑呢？

1、 控制节点不能成为瓶颈

在一个团队增加更多的事件，更多的告警，更多的故障的时候，总有一个领导者来进行分配任务，那么这个领导者的时间就那么多，会不会成为瓶颈？话说，将熊熊一窝。。。

在分布式系统中，一般都会带有元数据控制节点，例如etcd的存储，强一致性的master节点；k8s使用的就是etcd存储，强一致性的控制节点，例如日志来进行同步相关的元数据，从而保证数据的一致性。

分布式文件系统中，内存中需要保存大量的元数据信息，例如目录结构，如果目录文件达到几万个，需要多少内存？那么内存是否就成了扩展性的瓶颈。。。

在很多的设计中，可以将元数据进行分级存储，也就是弄一个二级索引，主控节点仅仅保存和二级索引之间的元数据，而二级索引用来保存部分的文件映射关系，从而可以解决控制节点成为瓶颈。

其实这种设计，就是为什么团队大了，各种领导，各种小头目，各种组长全部冒出来了，因为一个master实在是扛不住那么多事儿，所以分配专职的人来进行管理，而master只要管理这些专职的人就行了。

在减少master的压力上面，还可以使用权限下放的策略，例如在需要写入数据的时候，可以直接在客户端进行缓存元数据信息，然后直接写入到存储节点的服务器上，从而可以减少访问master的次数。

其实作为一个master，职责多多，对外统一暴露的服务能力。。。那么你能管好一个团队？借鉴下分布式系统的master节点也不错，下发任务，调度执行，负载均衡，健康情况检查，元数据管理等等。。。

2、 扩容的灵活性和灵活性

在一个团队中，增加一个人，说容易也容易，在一个团队中，减少一个人，说简单也简单。。。

在分布式系统中，主要是用来存储的，那么在进行扩容的时候，首先就要考虑到扩容的时候的数据迁移。。。数据量太大，怎么来迁移。。。迁移的时间是否允许，迁移个十年八载的，谁能受得了。。。

在团队进行交接的时候，交接就那么一个月。。。交接个十年八载的。。。这不用辞职了。。。哈哈

在扩容的时候，增加一个副本，可以大大的提高客户端读取的速度，但是如果增加一个副本就需要迁移几T的数据，如果这个几T的数据都是在一台机器上，那么得多久？网速20MB/s，那么就需要1T/20好久好久。。。

在k8s中，以pod为单位进行扩容，但是，这个根本就不会有多少数据存在，只需要拉取镜像，然后创建容器，运行容器就好了，1分钟内就可以完成。。。这种扩容的灵活性和自动化程度还是很好的。。

当扩容的时候，如果文件的数据都是分散在各个集群节点之上，那么扩容起来就比较灵活了，因为这样进行迁移数据的时候，用的整个集群的计算能力，存储能力和网络能力，而不是一台机器的计算存储网络资源。

3、 扩容的自动化

在一个团队中，如果整个组离职了。。。。增加一个组的难度有多难。。。各种技能的人进行搭配。。

在数据库的存储中，一般都是使用主备的模式，增加备用节点可以大大的提高读的性能，但是在分布式数据库中，进行了垂直分割水平分割，也就是分库分表。。这种如果扩容起来是否麻烦？

单个的主备，增加一个备用节点还是很简单的，只要进行日志同步就好了，而对于分布式数据库，根据业务进行切割表，得到各种子表，又根据hash算法进行切表，每个库里面存储一部分的数据。。。要扩容，那么就必须全部进行扩容，当有8个节点的时候，要想扩容，只有扩容8个节点，这样迁移的数据量不会很大，因为相当于每个分库进行扩容了，只要迁移分库的数据就好了。。

如果业务继续增大，写性能跟不上了，那么怎么扩容？只有将业务进行重新分割，继续切分为数据库。。。这样就各种数据迁移的太多了，相当于所有的数据都要进行迁移。

在k8s中，如果进行扩容，是以pod为单位，如果里面有三个容器，那么会直接增加一个pod，里面包含三个容器。。这种称之为同构架构。。。在分布式存储中，如果使用同构架构，那么增加一个副本，那么就会。。。拷贝大量的数据。。而且数据不是使用集群的整理资源。。。所以一般用异构架构，也就是数据进行切分，然后切分之后，副本分布在不同的交换机，不同的rack之上，从而在进行增加副本的，还是很容易的。

总结

可扩展性。。。不是说说而已，不是分布在几台机器上就是可扩展了，增加一个节点，需要同步多少数据？一个节点永久性宕机，需要多少时间来进行故障恢复？故障恢复时间也是一个很好的度量范围。