可扩展性是系统在不降低性能的情况下扩展的能力。当用户增加时，应用程序需要做出响应。本指南介绍了构建可扩展系统的技术策略。
可扩展性的类型
垂直（放大）
同一台机器上有更多资源：CPU、RAM、磁盘。简单但有限。
水平（横向扩展）
系统中有更多机器。分配负载。理论上无限。
弹性
根据需求自动。它在高峰时上升，在低谷时下降。
常见瓶颈
数据库
查询缓慢、连接耗尽、锁定。
###CPU
密集处理，低效代码。
内存
内存中的数据、缓存、内存泄漏。
输入/输出
磁盘、网络、阻塞操作。
网络
延迟、带宽、竞争连接。
后端策略
无状态服务
服务器上没有状态。任何实例都可以满足任何请求。
负载均衡
分发请求。循环、最少连接、IP 哈希。
###水平缩放
根据指标自动添加实例。
异步处理
繁重的工作要排队。快速响应，稍后处理。
扩展数据库
连接池
重用连接。 PgBouncer、ProxySQL。
阅读副本
读取副本。分发 SELECT 查询。
缓存
Redis、内存缓存。避免重复查询。
查询优化
正确的索引，高效的查询。
分片
水平分割数据。复杂但可扩展。
###NoSQL
DynamoDB、卡桑德拉。原生水平缩放。
缓存
级别
浏览器→CDN→API网关→应用程序→数据库。
###模式
缓存旁路、读通、写通。
无效
TTL、显式失效、事件驱动。
分布式缓存
Redis 集群实现高可用性。
消息队列
目的
解耦组件。尖峰缓冲器。
技术
RabbitMQ、SQS、Redis 队列、Kafka。
###模式
工作队列、发布/订阅、请求/回复。
保证
至少一次、最多一次、恰好一次。
微服务
规模优势
每个服务都是独立扩展的。
挑战
操作复杂性、网络延迟。
通讯
REST、gRPC、消息队列。
服务发现
服务如何找到彼此。
容器和编排
###Docker
封装应用程序。环境之间的一致性。
库伯内特斯
编排。自动缩放、健康检查、滚动更新。
无服务器
按需功能。 [AWS Lambda0，云函数。
CDN
目的
边缘的静态内容。更低的延迟。
卷曲什么
图像、CSS、JS、视频、可缓存 API。
提供商
Cloudflare、CloudFront、Fastly。
自动缩放
指标
CPU、内存、请求、延迟、自定义指标。
政策
目标跟踪、步骤缩放、计划。
冷却时间
缩放操作之间的时间间隔。
合适的尺寸
适合工作负载的实例。
性能优化
分析
确定时间花在哪里。
代码优化
高效算法，避免n+1查询。
延迟加载
按需收费。
压缩
GZIP、Brotli 用于 HTTP 响应。
可观察性
监控
普罗米修斯、Datadog、CloudWatch。
日志记录
集中记录。埃尔克、洛基。
追踪
分布式追踪。耶格，X射线。
警报
主动通知。
韧性
断路器
对于级联故障。
退避重试
增加间隔再试一次。
###舱壁
按操作类型隔离资源。
优雅的降级
当出现故障时部分有效。
负载测试
负载测试
预期正常负载下的行为。
压力测试
寻找突破极限。
尖峰测试
对突然峰值的响应。
浸泡测试
长时间负载下的稳定性。
工具
k6、JMeter、Locust、加特林。
云模式
多可用区
多个区域的高可用性。
多区域
灾难恢复、全局延迟。
现货/抢占式
用于容错工作负载的廉价实例。
结论
可扩展性是有意识的架构的结果。从一开始就计划，不断监控和优化重要的地方。目标是为业务增长做好准备。
##常见问题解答
1) 我什么时候应该开始考虑规模？ 来自建筑。但不要过早优化。
2) 先水平还是垂直？ 垂直的更简单。达到极限时水平。
3) 微服务总是能够更好地扩展吗？ 不一定。设计良好的巨石可以攀爬很多。
4) 我怎么知道我是否需要攀爬？ 监控指标。响应时间和资源使用情况表明。
5) 攀岩花费很多吗？ 这取决于。云允许您付费使用。首先优化代码。
另请阅读
- [应用程序可扩展性：策略和快速指南1
- [可扩展的软件架构：如何构建可增长的系统2
- [应用程序架构：可扩展系统完整指南3
- [应用程序中的缓存4
- [应用程序中的缓存：良好实践和基础知识5
- [应用程序中的缓存：良好实践和基本步骤6