软件架构伸缩性的六大法则（下）
极客时间编辑部
讲述：丁婵大小：7.69M时长：05:36
你好，欢迎收听极客视点。
构建可伸缩性的系统是每个软件架构师都应该掌握的知识。软件架构师伊恩·高顿（Ian Gorton）总结了六条构建可伸缩系统的经验法则，他称这些通用规则可以作为架构师指南，应对不断增长的负载和数据量处理需求。在上一篇文章中，我们分享了其中的三条，本文继续分享其余三条法则。
数据层最难伸缩
数据库实际上是每个系统的核心。它们通常包括“事实来源”事务数据库，包含了业务正常运行所需的核心数据和向数据仓库提供临时数据项的运营数据源。
核心业务数据包括客户概况、交易和账户余额，它们必须是正确、一致且可用的。
运营数据包括用户会话长短、每小时的访问者和页面浏览计数。这些数据通常有一个保质期，可以基于时间段进行聚合和汇总。因此，我们可以更容易地捕获和存储运营数据。然后，使用者定期检索数据并将其写入到数据存储。
随着系统请求处理层的伸缩，共享事务数据库的负载会逐渐增加。随着查询负载的增长，它们迅速成为瓶颈。查询优化变得非常有用，同样，也需要添加更多的内存，让数据库引擎能够缓存索引和表数据。但最终数据库引擎都会耗尽资源，需要进行更彻底的改变。
首先要注意的是，在数据层做出数据结构变更是件痛苦的事情。如果修改了关系型数据库的模式，可能需要运行脚本重新加载数据来匹配新模式。在脚本运行期间，系统就不能执行写操作，这可能会让客户不高兴。
NoSQL、无模式的数据库降低了对重新加载数据库的需求，但仍然需要修改查询代码来匹配修改后的数据结构。如果你的业务数据中有一些数据项的格式已被修改，而有些保留原始格式，那么你可能还需要进行数据对象版本控制。
进一步伸缩可能需要使用分布式数据库，或许包含只读副本的首领和追随者模型就足够了。大多数数据库都很容易配置这种模式，但需要进行密切的监控。当首领发生宕机，故障转移需要花费一些时间，有时候还需要手动干预。这些问题都非常依赖数据库引擎。如果采用无首领模式，则必须做好跨节点的数据分布和分区。
缓存、缓存、再缓存
降低数据库负载的一种方法是尽可能避免经常访问数据库，而这就是缓存的用武之地。好的数据库引擎应该能够尽可能多地利用节点缓存。这是一个简单而有用的解决方案，但成本可能很高。
如果不是必需的，为什么一定要查询数据库呢？对于经常读取和很少发生变化的数据，可以先尝试从分布式缓存中获取。这需要进行远程调用，但如果你需要的数据刚好存在于高速网络的缓存中，这也比查询数据库实例快得多。
在引入缓存层后，我们需要修改处理逻辑，先从缓存中获取数据。如果你想要的内容不在缓存中，就要查询数据库，然后将结果放到缓存中，并将其返回给调用者。你还需要决定何时删除或让缓存失效，这取决于应用程序对陈旧数据的容错程度。
在伸缩系统时，设计良好的缓存方案绝对是无价的。如果你可以通过缓存处理很大比例的读取请求，那么就可以购买额外的数据库容量，因为它们不需要处理大多数请求。这意味着在为越来越多的请求增加容量时，可以避免复杂而痛苦的数据层修改。
监控是可伸缩系统的基础
所有的团队在面对大工作负载时都需要解决的一个问题是进行大规模测试。真实的负载测试很难进行，假设你想测试一个已有的部署，看看如果数据库大小增加 10 倍之后是否仍然能够提供快速的响应。你首先需要生成大量的数据，这些数据最好与实际的数据集和数据关系特征相呼应。你还需要生成一个真实的工作负载，是用于读取，还是用于读和写？然后你再加载和部署数据集，并进行负载测试，这可能需要使用负载测试工具。
另一种选择是进行监控。简单的系统监控包括监控基础设施。如果资源耗尽，例如内存或磁盘空间不足或者远程调用失败，你都应该收到报警，以便在糟糕的事情发生之前采取补救措施。
监控是必要的，但还不够。随着系统的伸缩，你需要了解应用程序行为之间的关系。你还需要知道什么时候回路断路器会由于下游延迟增加而断开微服务连接，什么时候负载均衡器开始生成新实例，或者消息在队列中停留的时间是否超过了指定的阈值。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论