构建可靠性、可伸缩性&可维护性系统

admin管理员组

文章数量:1436988

构建可靠性、可伸缩性&可维护性系统

在如今现代应用系统中,我们更多是关注数据密集系统而非计算密集系统,即计算机发展到如今,CPU已然不是构建一个应用系统程序的限制, 更多的挑战在于数据规模的增长, 数据的复杂度变化以及数据变化的速度.

完整数据流系统是如何运作

一般地, 一个完整的系统数据流架构如下:

• 用户通过API发送客户端请求, 如果是查询请求, 会先从缓存中查询, 命中缓存则返回;
• 如果没有命中缓存, 则回源查询数据库返回;
• 同时还有另一个应用程序系统监听数据库的数据变化(Capture changes to data), 这个时候做两个动作, 一个是更新缓存令缓存失效; 一个是构建搜索索引方便用户基于搜索场景进行检索.
• 如果是搜索请求, 那么我们的应用系统就会从全文搜索系统检索关键词对应的数据ID列表并查询数据库数据组装返回.
• 如果是数据日志埋点等消息通知,则应用系统会通过MQ异步发送到其他进程系统进行处理,比如需要发送邮件通知.

通过上述数据流架构, 我们构建一个应用程序系统可能需要包含以下功能:

• Database: 支持数据存储以便于后续能够再次检索查询到这些数据.
• Cache: 能够记住一项耗费资源的数据计算结果以便于加速下次查询效率.
• Search Indexes: 能够根据关键词去数据系统中检索数据.
• Stream Processing: 能够连续不断地接收并处理来自跨进程异步发送的消息.
• Batch Processing: 能够定时处理大规模累积的数据集.

如何去思考数据系统

通过上述的数据流系统, 我们可以知道客户端对于应用系统内部如何运作是一个黑盒, 其中封装隐藏实现的细节; 同样地,我们的数据库对于应用程序而言也是一个黑盒, 同样将具体细节实现进行封装隐藏起来. 如果我们对上述的数据流系统进行分层,那么我们对应的每个层次关注的细节都会不同.

因此从一个数据层开发视角看,构建一个数据系统需要考虑以下问题:

• 可靠性: 如何确保数据正确且完整?
• 可伸缩性: 如何在确保数据正常运作下面临数据规模的增加仍然能够保持良好的性能,即如何扩展以应对负载的增加?
• 可维护性: 如何在面临诸多不同因素下能够高效地在原有系统进行迭代以保证系统正常运行.

系统关注要素

1) 可靠性与可用性

• 什么是可靠性?

系统面临硬件、软件或者人为错误, 系统也能够继续正确运行, 即无差错地执行预期操作. 强调是系统的质量, 可靠性通过软件测试进行修复.

• 什么是可用性?

可用性更强调系统是否能够正常运转,即是否可以进行操作, 是否有响应? 强调是架构层面的质量, 可用性无法避免, 需要在架构层次上通过冗余机制来保证.

• 可靠性与可用性例子

可靠性: 我们通过调用一个在线计算系统计算 2+3 的结果, 结果却得到6, 说明这个系统不可靠, 可能存在bug, 因此通过测试组件回归并修复.

可用性: 我们同样地调用一个在线计算系统计算2+3得到5的结果, 说明是可靠的, 但是有时候有响应有时候因为超时而无响应, 超时或者服务宕机导致无响应, 这个时候说明系统是可靠但不可用.

因此抛开架构层面, 我们设计一个数据系统, 要先保证数据完整且正确, 也就是需要具备可靠性:

• 硬件故障会导致数据错乱甚至是数据丢失, 那么当我们再次查询的数据就不对了
• 软件故障, 比如上述计算的bug导致计算结果不正常, 那么当再次查询数据结果也不对.
• 人为错误, 比如我们的系统依赖外部的配置, 这个时候需要人工手动下发配置, 结果配置缺失或者配置错误导致软件朝着不可预期的方向执行导致数据错乱, 这个时候我们查询数据结果也不对.

2) 可扩展性与可伸缩性

• 什么是可扩展性?

可扩展在我的理解主要包含两个层次, 其一是软件层面, 可扩展意味着我们的软件能够适配业务的变化,也是后面可维护性中要具备可演进性,其有两种模式如下:

另一个可扩展层面就是我们架构部署层面上的可伸缩性, 即Scalabilty.

• 什么是可伸缩性?

可伸缩性就是在系统面临规模的增长,我们的性能逐步出现瓶颈,比如机器负载增加、耗时增加等, 那么这个时候可伸缩性是指我们可以通过增加资源来让我们的系统恢复到原有的性能水平.

• 如何评判系统的负载与性能?

负载描述: 假设现在负责一个广告系统, 那么当前系统的负载可以用哪些指标进行衡量呢? 比如应用基础监控,比如请求数、响应数等, 那光这些就足够了吗? 其实不是, 可能还要关注广告数增长的量级、查询依赖下游的超时数与容灾数、构建缓存的命中率等.总结起来就是我们关注的负载是指要用哪些负载指标来衡量一个系统增长的规模.

性能描述: 其一是我们基础资源的指标监控, 比如CPU、占用内存、网络带宽、磁盘IOPS等等, 还有一个是我们的RT,而关注的RT应当从百分比去考量而非平均数,因为平均数我们很难去衡量一个系统具体的性能情况,比如1个请求是1ms,另1个请求是10ms,平均起来是5ms,但能说明什么? 相比百分比而言, 比如P99=10ms的耗时意味系统面临100个请求有99个请求所花费的时间是小于或者等于10ms,存在1个请求是大于10ms.

• 延迟Latency与响应时间RT

延迟（latency）和响应时间（response time）常常被当作同义词使用，但它们并不相同。响应时间是客户端所看到的时间：除了处理请求的实际时间（服务时间）之外，它还包括网络延迟和排队延迟。延迟则是指一个请求在等待被处理的时长，在此期间请求处于未处理状态，等待着服务。 因此RT与延迟关系如下:

代码语言：javascript代码运行次数：0运行复制

RT = t1 + t2 + t3 + t4 + t5

• 应对负载的方法 - 可伸缩性具体方式

纵向扩展: 迁移到更强大的机器

横向扩展: 也称无共享架构, 将负载分散到多台较小的机器上.

3) 可维护性

• 可操作性: 让运维团队能够轻松地使系统平稳运行。
• 简洁性: 通过尽可能消除系统中的复杂因素，让新工程师易于理解该系统。（请注意，这与用户界面的简洁性并非同一回事。）
• 可演进性: 让工程师在未来能够轻松对系统做出更改，以便在需求发生变化时，使系统适应未曾预料到的用例。这也被称为可扩展性、可修改性或可塑性。 这里是指业务扩展性.

总结

• 可靠性意味着即使出现故障，系统也能正确运行。故障可能出现在硬件方面（通常是随机且不相关联的）、软件方面（软件漏洞通常是系统性的，且难以处理）以及人为因素方面（人难免时不时会犯错）。容错技术可以对终端用户隐藏某些类型的故障。
• 可伸缩性意味着即使负载增加，也有办法保持良好的性能。为了讨论可扩展性，我们首先需要有定量描述负载和性能的方法。我们简要地以推特的主页时间线为例来描述负载，并以响应时间的百分位数作为衡量性能的一种方式。在一个具有可扩展性的系统中，你可以增加处理能力，以便在高负载下仍能保持可靠性。
• 可维护性包含很多方面，但本质上是为那些需要与系统打交道的工程和运维团队创造更好的工作条件。良好的抽象可以帮助降低系统的复杂性，使其更易于修改，并适应新的用例。良好的可操作性意味着能够清晰了解系统的健康状况，并且拥有有效的管理方法。

本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2025-03-09，如有侵权请联系 cloudcommunity@tencent 删除架构数据系统性能amp

本文标签： 构建可靠性可伸缩性ampamp可维护性系统