互联网架构的数学解释——互联网架构定义及特性

Posted on | Edited on | In

  在这个互联网的时代，可以说人们的衣食住行等方方面面都离不开互联网带来的便利，互利网技术也成为了目前炙手可热的话题。同时互联网技术是一个很大的领域，气象万千、包括万象，也不是本专栏三言两语能够描述清楚的，本专栏只聚焦于互联网架构这一个相对来说比较小一些的范围。

1 互联网架构的定义

  架构一词就字面意思是指比喻事物的组织、结构、格局，并广泛应用在建筑领域，随着计算机和软件技术的发展，也逐渐将架构一词用于软件架构中，是一系列相关的抽象模式，用于指导各类软件系统各个方面的设计。互联网架构也就是指将软件运行在互联网之上形成的架构，但是如果仅仅只是讨论所谓的软件未免显得比较狭义了，目前的互联网架构应该是包括硬件、软件、网络甚至包括一整套构建、运维以及管理流程，笔者翻阅各类资料并未找到对互联网架构这一术语有着明确的定义，为避免歧义或者误会，本专栏将互利网架构定义如下：

互联网架构是指以互联网为依托，能够支撑用户正常“访问”为中心，并达到满足一定业务目的为前提，综合各种技术及管理形成的一整套组织和结构。

2 互联网架构的特性

2.1 特性的基本解释

  互联网架构作为一整套组织和结构，也应该存在相应的衡量指标，用来描述某一种互联网架构的好坏，包括：

  • 可用性（Availability）：是指系统在执行任务的任意时刻能正常工作的概率。
  • 可靠性（Reliability）：是指从它开始运行到某个时刻，这个时间段内正常运行的概率。
  • 可扩展性（Scalability）：是指系统通过添加资源(使硬件更强大(向上扩展)或添加更多节点(向外扩展))来容纳更大负载的能力。
  • 弹性（Elasticity）：是指系统在向外扩展时动态处理负载所需的资源的能力。
  • 一致性（Consistency）：是指系统更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
  • 分区容错性（Partition tolerance）：是指系统在遇到某节点或网络分区故障的时候，仍然能够对外提供外界无法感知故障的“访问”的能力。

2.2 特性的指标量化

  可靠性一般采用MTTF(Mean time To Failure)平均失效前时间、MTTR(Mean Time to Restoration)平均恢复时间、MTBF(Mean time Between Failure)平均故障间隔时间这几个指标进行衡量，如图 所示：

1
2
3
4
5
MTTF = \frac{\sum\limits_{i=1}^nTw_i}{N}

MTTR = \frac{\sum\limits_{i=1}^n(Ts_i + Tr_i)}{N}
 
MTBF = MTTF + MTTR

  可用性是表示系统在任意时刻能够正常工作的概率，定义为：

1
2
3
4

Availability = \frac{MTTF}{MTTF + MTTR} 
             = \frac{\sum\limits_{i=1}^nTw_i/N}{\sum\limits_{i=1}^n(Tw_i + Ts_i + Tr_i)/N}
             = \frac{\sum\limits_{i=1}^nTw_i}{\sum\limits_{i=1}^n(Tw_i + Ts_i + Tr_i)}

  通俗上常有几个九来表示，以一年为周期计算，不同九的级别对应不可用时间如下表：

可用性 年服务不可用时间
99%（2个9） 3.65天
99.9%（3个9） 8.76小时
99.99%（4个9） 52.56分钟
99.999%（5个9） 5.26分钟
99.9999%（6个9） 31.54秒

  通过上述量化指标可以看出，可用性与可靠性有所不同，但是也存在一定关联性，提高系统可靠性MTTF指标在某种程度上可以提高系统的可用性，但是可用性高的系统不一定可靠性高。比如A系统每年因故障中断十次，每次恢复平均要15分钟，B系统每年因故障中断2次，每次需6小时恢复。依据上述量化公式，A系统MTTF≈36.5天，Availability≈99.97%，B系统MTTF≈182.3天，Availability≈99.86%，则A系统可用性比B系统高，但可靠性比B系统差。

  可扩展性是指扩展硬件或者增加节点来提高负载的能力，由于系统中存在不同组件，为简单便于计算，假设不同组件的扩展统一抽象为节点单元，每一个节点单元单独使用可承受的负载为tps，扩展至N个节点单元整个系统可承受的负载为TPS，定义系统的可扩展性为：

1
Scalability = \frac{TPS}{N*tps}

  一般系统随着节点单元的增加系统的负载能力并不是完全线性增加的，存在着一定的损耗，如果损耗越小，则称系统的可扩展性越好。

  弹性是指系统在向外扩展时动态处理负载所需的资源的能力，针对云的资源共享和互联网的使用量起伏特点所提出的“热扩展”要求，以非人工干预的、反应式的、近实时的资源调整来应对负载变化，尤其是不可预见的使用量高峰，从而提高服务容量、资源利用率和降低成本。

  定义系统随着时间变化预测访问量为f(t),定义系统最高负载能力随时间变化能力为g(t),假设在初始T0时刻系统预测访问量与系统最高负载相同，随着业务发展或者活动的推出，系统预测访问量会随之变化，对于弹性系统可以动态调整系统资源使得系统最高负载能力也随之变化，有点类似于对系统加上一定的激励以及对该激励做出的响应，如果系统对激励的响应越快越准备，则称系统的弹性越好，可定义为：

1
Elasticity = \frac{\int_{T_0}^{T_1} g(t) {\rm d}t}{\int_{T_0}^{T_1} f(t) {\rm d}t}

  在谈到一致性的时候，大家一般可能都会想到强一致性，最终一致性等等，但是个人总觉得稍显含糊，不够严谨，如果两个分布式系统都是最终一致性，能够有办法评价一致性的好坏呢？本文尝试通过定义量化的指标来衡量一致性，假设该系统的数据副本数量为N，一次成功写操作记为W(D,v)=0，在此时间T0之后如果任何的读操作R(D)均为v，则表示该系统是强一致性，如果存在某个时间T，对于任何T时间之后的读请求，均有R(D)=v，则表示该系统为最终一致性，T值的最小值约小，则表示一致性越好，该最小T值记为MTTC(Min time to Consistency)，数学语言描述为：

1
MTTC = \min\{ T | T \ge 0, R(D)_{t > T} =v \}

  分区容错性是指系统在遇到某节点或网络分区故障的时候，仍然能够对外提供外界无法感知故障的正确“访问”的能力。这里的正确“访问”是指能够对数据正确访问，而不是正常“访问”，如果系统返回之前的旧数据也叫做正常访问，只能说明可用，不能代表分区容错。假设系统的假设该系统的数据副本数量为N，系统的分区为M，当m个分区故障之后，系统仍然能够提供正确“访问”的能力，m值越大，则说明系统分区容错性越好，定义为分区容错率（Partition Tolerance Rate）为：

1
PTR = \frac{\max\{ m \}}{N}

  这里将数据副本与分区数量进行了区分，是考虑到实际确实存在某些架构分区的概念可能比较大，或者说这个分区存在某种程度上的层次，后续文章中会进行相关案例介绍，当然，大部分架构在设计时将分区数量默认与副本数量相同，在满足大多数业务需求的同时降低了系统的复杂度。

3 互联网架构的分析

  互联网架构作为本专栏的主要研究对象，也可以按照架构分析的视角对互联网架构进行分析，主要是通过不同层级的视角对互联网架构的林林总总进行分类梳理，力求抽象并找出共性。

3.1 域架构

  域架构是指目前研究以及应用都比较多，实实在在用于支撑用户正常“访问”的架构，不同的层级从具体到抽象又可分为业务问题域架构、公共问题域架构、基础问题域架构。

  • 业务问题域架构：是指可以实际应用于具体业务领域问题的架构，比如电商秒杀、金融支付、海量商品详情、订单交易、千人千面、视频直播等具体业务场景所对应的架构，在某种程度上可以与业务开发架构师设计的架构相对应，同时更加倾向于业务中台的相关架构。
  • 公共问题域架构：是指用于支撑上述具体业务问题域架构的较为公共问题的架构，比如搜索、推荐、IM、分布式事务、隔离、限流等等，在某种程度上可以与公共组件或者中间件架构相对应。
  • 基础问题域架构：是指用于实现公共问题域架构的基础架构，比如分布式锁、缓存、队列、池化复用、同步异步、负载均衡等，通过这些基础架构的组合、连接等实现公共问题域架构。

3.2 架构元及数学解释

  架构元在理解上可以与数据元对应，是组成架构的最小单元或者原子单元，是对基础问题域架构进行进一步抽象而形成，同时也可以作为互联网架构与数学理论解释的桥梁。在本专栏的后续文章中会随着域架构分析的深入逐步介绍架构元的类型以及种类。

4 总结

  本文对互联网架构给出了定义以及衡量指标的数学描述，并对互联网架构进行了抽象分析，主要是总结个人对互联网的理解，其中难免会有一些偏差，写的不好或者错误的地方还希望大家多多指点。

本专栏下一篇文章会对互联网常用架构中业务问题域架构进行梳理，并整理出一些常用具有代表性的业务问题架构，尽请期待。