问题描述
想知道如何比较不同基础设施的规模和复杂性。他想知道可以测量和比较哪些方面，例如节点数量、服务器数量、架构等。这些度量和变量在比较时有什么不同？哪些度量有意义，并且在工作类型上有实际差异的基数是多少，而不仅仅是额外的工作量。
用户还想知道如何判断一个基础设施是“非常大”还是“非常复杂”，以及它们之间的区别是什么。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
规模度量
规模的度量可以大致分为三个不同的类别，我将其定义为管理的深度、外包或作为服务消耗的深度，支持的服务的广度和实例、服务器和客户的数量的高度。复杂性的度量在很大程度上取决于所选择的系统架构、支持人员的组织结构和所需的技能集。深度和技能集是规模和复杂性的双重增加因素。
规模度量
请注意：以下大部分规模要求也可以通过系统架构、技能集和组织结构需求增加复杂性。
基础设施的深度
你将多少基础设施外包给其他人，增加了多少深度：
- 你是否只使用软件作为服务来完成所有工作？
- 你是否完全在公共云、私有云或混合云中运行，或者使用某些平台即服务（PaaS）？
- 你是否使用基础设施即服务（IaaS）？
- 你是否在租用的数据中心空间中使用托管基础设施？
- 你是否拥有或租用硬件？
- 服务提供商是否管理基础设施监控？
- 服务提供商是否管理基本系统管理？
- 服务提供商是否管理硬件故障和维护？
- 服务提供商是否管理机架和服务器安装？
- 服务提供商是否管理内部网络？
- 服务提供商是否管理互联网连接和路由？
- 你是否只有合同远程支持的数据中心？
- 你是否在自己的数据中心或自己的数据中心中托管所有内容？
基础设施的广度
你支持的不同类型的服务是什么？
- 计算资源
- 物理服务器
- 虚拟化层（VMWare）
- 容器层（Docker、Kubernetes、Mesos）
- 无服务器层（Lambda、Functions）
- 存储资源
- 独立存储设备
- 服务器中的RAID
- 大型独立关系数据库集群
- 时间序列数据库
- 对象存储集群
- 网络资源
- 可观察性资源
- 系统日志服务器
- 指标和图形系统
- 搜索集群
- 自动化资源
- 备份/恢复资源
- 复合服务
- ELK、Hadoop等
基础设施的高度
- 你需要每个资源的规模是多少？你是在单个服务器/实例上运行服务，还是需要使用机器集群？
- 你需要多少冗余？
- 你的可用性要求是什么？
- 你对服务的延迟和吞吐量有什么要求？
- 你需要地理分布的基础设施吗？（国际业务、延迟要求或符合GDPR、数据本地化法律等的法规合规性）
- 你在每个地理位置需要多个数据中心吗？
复杂性度量
系统架构
当涉及到基础设施复杂性时，它与基础设施支持的分布式系统的复杂性非常密切相关。你必须考虑两种类型的系统：
- 支持各个服务的分布式系统。
- 由服务之间的相互依赖性创建的分布式系统。
分布式系统的复杂性
基础设施支持的每个服务本身的复杂性水平可能不同，对基础设施的要求也不同。支持服务的系统可以包括：
- 单线程。
- 多线程（共享内存、共享磁盘）。
- 具有数据分片的并行系统。
- 高可用故障转移（主/备）（冷备、温备、热备）。
- 高可用集群（N+M）。
- 实时集群。
服务之间的相互依赖性
让我举个例子。假设你的基础设施将测试结果报告到ElasticSearch集群。你的值班电话依赖于ElasticSearch提供的监控和测试数据。ElasticSearch集群的地理分布使其依赖于你的数据中心的网络连接。现在，你的一个互联网提供商决定在周六晚上进行未经通知的维护，吞吐量下降，你的流量被重定向到备份提供商，监控流量被降低到客户数据流量，监控事件的摄入速度变慢，你的值班电话疯狂响个不停。
每当两个服务、基础设施的两个部分相互依赖时，它们就会创建一个新的单一分布式系统，其复杂性应该独立评估。这种依赖关系可以被消除或减少。请记住，系统的冗余和可用性仅取决于它所依赖的所有服务的交集。
组织结构
这是一个独立的章节…人往往是IT基础设施整体系统中被忽视的一部分。当涉及到人员时，我们很少考虑冗余、可用性和延迟因素，但与计算机系统一样，这些问题也会影响维护基础设施的组织的复杂性，而且它们的复杂性有时很容易超过计算机系统的复杂性。参与维护基础设施的人员可能涉及多个时区、语言、地理位置、公司、薪资水平和法律法规。这些因素中的任何一个都是复杂性增加的迹象。
结论
在比较IT基础设施的规模和复杂性时，可以使用不同的度量标准。规模可以通过深度、广度和高度来衡量，而复杂性则取决于系统架构和组织结构。了解这些度量标准可以帮助你更好地理解和比较不同基础设施的规模和复杂性。