前言
团队，总会有人离开，总会有人加入。。。总会有一个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
（Pod是Kubernetes中能够创建和部署的最小单元，是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。）
，里面包含三个容器。。这种称之为同构架构。。。在分布式存储中，如果使用同构架构，那么增加一个副本，那么就会。。。拷贝大量的数据。。而且数据不是使用集群的整理资源。。。所以一般用异构架构，也就是数据进行切分，然后切分之后，副本分布在不同的交换机，不同的rack之上，从而在进行增加副本的，还是很容易的。
总结
可扩展性。。。不是说说而已，不是分布在几台机器上就是可扩展了，增加一个节点，需要同步多少数据？一个节点永久性宕机，需要多少时间来进行故障恢复？故障恢复时间也是一个很好的度量范围。
本文分享自微信公众号 - SRE运维实践（gh_319dd73ec076），作者：NAN
标签：扩容,存储,可扩展性,聊聊,进行,数据,节点,分布式 来源： https://blog.csdn.net/goTsHgo/article/details/122286927
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。