原创声明：本文系作者原创，谢绝个人、媒体、公众号或网站未经授权转载，违者追究其法律责任。
在前一篇《分布式系统架构技术分析（一）》中，我们已经对分布式系统的主要特征、组成要素及运行机制进行了初步的分析。当然，真实构建和运行一个分布式系统涉及的细节要比文章中阐述的复杂很多，如何保障大型分布式系统的低成本和高可用，是很有挑战性的工作。其中容量规划和容灾管控是两个重点。
容量规划
分布式环境下的容量规划主要是满足日常业务增加对于容量的要求，以及应对突发的活动带来的流量高峰。日常容量规划的方法是根据业务增加的趋势以及业务增长需要达到的目标，提前几个月将该容量准备好。针对突发活动的容量规划，需要提前制定业务指标，包括涉及的活动业务场景、每个场景的每秒并发访问量、请求成功率、请求响应时间等，评估的方法主要有单机容量评估和集群容量评估，涉及的评估对象主要有网络设备、在线应用服务器、在线存储服务器、近线实时计算服务器和离线计算服务器。
应用服务器单机的处理能力估算公式 TPC-C = ∑ (每秒钟服务处理量 * 标准的服务性能比率) / (1 - 冗余率)，比如 A 应用同时提供 serviceX 和 serviceY，在一秒内需要同时处理 serviceX 1000 笔和 serviceY 2000 笔，每个 serviceX 的标准的服务性能比率为 0.5，每个 serviceY 的标准的服务性能比率为 2，考虑 30% 的系统冗余率，那该应用服务器单机处理能力(tpmc) = ((1000 * 0.5) + (2000 * 2)) / (1 – 30%) = 6428。每个应用服务器根据自己系统提供的服务以及访问量计算出单机的处理能力。 存储服务器单机的处理能力除了考虑请求处理能力的估算外，还需要考虑硬盘的容量，主要估算的方法为每条数据库记录需要的硬盘空间，秒级需要提供的并发访问数，提供该并发能力持续的时间，估算的公式为 = ∑(SQL 每秒钟处理量 * SQL 记录需要的空间) * 时间，计算出在日常和活动峰值期间需要的硬盘容量，为了保障数据库空间够用，需要冗余 30% 的硬盘空间。 网络设备的容量估算主要涉及网络的 IP 资源、网络上行和下行带宽容量、网络延迟，评估的方法主要是根据业务峰值需要的网络流量进行带宽合并计算，按网络流量的上限估算网络带宽容量，IP 资源根据整体业务需要的 VM 资源数量来估算。
分布式环境下的集群容量评估根据业务执行的链路，把涉及的网络设备、应用服务器、存储服务器等串联起来考虑，将业务指标（业务场景、场景并发数、请求成功率、请求响应时间）逐级下放到对应的服务器上。使用的方法可以通过链路分析，将需要评估业务涉及的链路从入口到结束串联起来，分析这个路径中每一个服务器需要处理的服务以及对应的并发访问量，然后根据总的容量要求计算出每个应用服务器、存储服务器需要达到的容量要求，最后根据服务器需要达到的容量除以单机的容量，得出每一个服务器需要的机器数量，按照计算出来的机器数量给对应的服务器扩容，以达到业务指标要求的容量。
在分布式环境下的集群容量受到很多因素的影响，只靠容量分解和单机容量评估得到业务容量不是 100% 的可靠，还需要线上有环境可以验证集群的容量是满足业务指标要求的。线上业务指标的验证可以通过模拟真实用户并发的发请求的过程，客户端压力机根据事前准备好的压测脚本发起压测流量，模拟真实的业务场景和容量指标，观察业务的成功率、业务响应时间、集群的稳定性和服务器的性能表现，通过真实场景压测验证过的容量我们才认为是可靠的容量要求。
容灾管控
在分布式环境下，应用系统一般设计成无状态的，单机故障只需要将其「踢出」集群即可。在第一小节中提到，系统间通信一般会采用消息或者 RPC 的方式。无论哪种方式，都需要一个寻址路由的过程，如 RPC 中客户端调用到服务端的场景，如果做客户端路由，则客户端会从可用的服务端机器列表中做负载均衡计算，选择一台调用。这些地址信息的注册和发现能力有一组负责寻址的集群负责，一旦单机故障发生，故障服务端机器与寻址服务器断开连接，或者心跳无反应，寻址服务器就会将其「踢出」可用列表，并将新的列表通知到所有的客户端，从而让客户端调用正常可用的机器，实现单机故障的自恢复。消息发布和订阅场景下，单机故障也是同样处理。
DB 为有状态是服务器，其单机故障的处理机制会相对复杂一些。比较常见的方案是利用数据库本身的主备切换机制，即每一个数据库都采用「主库+备库」的部署方式，主库故障时通过主备切换工具自动切换到备库提供服务。这种模式好处是一般 DB 都支持，操作相对简单，恢复后的处理也比较简单，但坏处是延迟时间较长，而且根据业务情况可能需要短时间的禁写，一般需要人为参与。
数据库本身的主备切换机制有较多局限性，在分布式环境下往往会有多样性的 DB 备份需求，例如远距离，大数据量，多备份等场景，可以通过 DB 的操作日志来实现更为强大、灵活的数据源同步备份组件，依靠类似 Mysql 的 binlog，Oracle 的 redolog 等来支持复杂备份场景，从而更为灵活的支持单机故障的恢复。
为应对网络设备单机故障，需要在网络架构设计上就考虑冗余，主要分为设备冗余和链路冗余：
设备冗余：物理设备（应用服务器或者网络设备）都会上联多台网络设备，某台网络设备出现故障，整个网络拓扑会自动收敛，进出流量改为从正常运行的网络设备通过，业务基本无感知。
链路冗余：骨干网络设备间的物理连接，采用双链路或者多条物理线路冗余的方式，防止单点故障。如果单条线路故障剩余冗余链路可以继续工作保障通信正常。
通过建立同城双活、异地近距离双活、异地多活等机房架构，应用层与数据层都进行水平拆分，多个机房内同时承担用户访问流量，不同机房集群间为互备关系，确保系统不间断运行。
数据层的分布式部署结构中，不同机房集群间为互备关系，通过计算 DB 所关联的业务系统，得出受影响的应用列表，并通过与 DB 单机故障一样的方式，推送数据库切换指到互备机房的 failover 集群，来应对某个单元维度的数据库集群故障。
一般来说，整个机房的应用集群均出现问题的可能性较小，一旦出现则视为机房级故障，其处理方式与网络设备集群故障的处理方式一样，通过容灾管控系统把整体架构上各层的流量（包括入口网关+业务层+数据层+出口网关等）切换到同城或者异地的正常机房中。
为了更好实现无限伸缩性、精准容量规划和持续可用的容灾管控机制，蚂蚁金服分布式架构经过多年演化，我们完成了异地多活的单元化架构，并在 SOFA 和蚂蚁金融云上沉淀这一架构能力，关于单元化架构的概念陈述，读者可以参考《素描单元化》这篇文章。
相关热文
长按二维码关注我们 ▶▶▶
点击【阅读原文】获取招聘信息或发送简历到 sofa@cloud.alipay.com，期待您的加入！