可扩展性是系统在不损失性能的情况下扩展的能力。当业务增长时，软件需要跟上。本指南介绍了构建可扩展系统的基本概念、架构模式和实用策略。
What is Scalability
可扩展性衡量系统如何响应增加的负载。即使有更多的用户、数据或请求，可扩展的系统也能保持足够的性能。
Vertical Scalability
增加单机资源：更多CPU、内存、磁盘。简单，但有物理限制并且成本不断增加。
Horizontal Scalability
将更多机器添加到系统中。在多个服务器之间分配负载。理论上无限，但需要适当的架构。
Elastic Scalability
能够根据需求自动扩展。在高峰时增加资源，在平静时刻减少资源。 Optimizes cost.
Why Scale
User Growth
More users generate more requests. The system needs to absorb growth.
Data Augmentation
Data grows exponentially. Storage and processing need to keep up.
Availability
分布式系统能够更好地承受故障。 If one server goes down, others continue.
性能
Distributing load improves response times. Users have a better experience.
Scalable Architecture Principles
Statelessness
服务器不维护会话状态。 Any server can serve any request. Facilitates load balancing.
Loose Coupling
通过明确定义的接口进行通信的独立组件。 Changes in one do not affect others.
Asynchronous Processing
Heavy jobs are processed in the background.请求很快返回，处理稍后进行。
缓存
Stores frequent results to avoid reprocessing.减少银行和服务的负担。
架构模式
结构良好的整体
对于初学者来说，一个有组织的 [monolith0] 可以垂直扩展，然后拆分。不要低估。
微服务
系统分为小的、独立的服务。每个都单独缩放。 Greater operational complexity.
无服务器
按需执行的功能。自动缩放。您只需为使用付费。适用于不可预测的负载。
事件驱动
组件通过事件进行通信。最大解耦。自然的异步处理。
基础设施组件
负载均衡器
在服务器之间分发请求。来自 AWS 的 Nginx、HAProxy、ALB。对于水平缩放至关重要。
API网关
单一入口点。路由、[身份验证1、速率限制。 Kong，AWS API 网关。
消息队列
用于异步通信的队列。 RabbitMQ、SQS、卡夫卡。它将生产者和消费者脱钩。
分布式缓存
服务器之间共享缓存。 Redis、内存缓存。减少[数据库2 上的负载。
CDN
全球分布的静态内容。 Cloudflare、CloudFront。减少源端的延迟和负载。
扩展数据库
阅读副本
只读副本分发 SELECT 查询。主服务器接收写入，副本读取。
分片
在多个银行之间水平分割数据。每个分片包含数据子集。
查询缓存
银行前面的Redis或Memcached。避免重复查询。
NoSQL 银行
DynamoDB、MongoDB、卡桑德拉。专为水平缩放而设计。一致性的权衡。
新SQL
蟑螂数据库、TiDB。通过传统 SQL 保证水平扩展。
异步处理
工作队列
工作人员在后台处理任务。芹菜、Sidekiq、公牛。解耦请求处理。
事件流
卡夫卡，运动。实时处理事件流。随分区线性扩展。
批处理
火花、Hadoop。批量处理大体积。适合分析和 ETL。
可观察性
集中日志记录
所有服务的日志集中在一处。 ELK 堆栈，洛基。对于分布式调试至关重要。
指标
普罗米修斯、Datadog、CloudWatch。监控健康状况和性能。警报问题。
分布式追踪
Jaeger、Zipkin、X 射线。跟踪多个服务的请求。识别瓶颈。
部署策略
###蓝绿
两个相同的环境。空闲时部署，准备好时切换。即时回滚。
金丝雀
针对一小部分用户的新版本。如果稳定则逐渐增加。
滚动更新
一次更新一个实例。始终有可用容量。
云和基础设施
容器
Docker 封装了应用程序和依赖项。 [Kubernetes3 大规模编排。
自动缩放
根据指标自动添加/删除实例。 AWS ASG、GCP 实例组。
基础设施即代码
Terraform、Pulumi、CloudFormation。版本化且可复制的基础设施。
弹性标准
断路器
停止失败的服务调用。避免级联错误，允许恢复。
退避重试
增加间隔再试一次。防止恢复期间过载。
###舱壁
按操作类型隔离资源。某一方面的失败不会影响其他方面。
超时
操作时间限制。防止请求无限期锁定资源。
性能与优化
分析
识别代码中的瓶颈。优化重要的地方，而不是你认为的地方。
连接池
重用银行连接。避免创建连接的开销。
压缩
压缩 HTTP 响应。减少带宽并缩短加载时间。
延迟加载
仅在必要时加载数据。减少初始处理。
权衡
CAP 定理
一致性、可用性、分区容错性。选择两个。了解您的系统的权衡。
操作复杂性
分布式系统的操作更加复杂。评估一下你是否真的需要它。
成本
更多的基础设施成本更高。平衡性能和预算。
何时升级
需要的迹象
- 响应时间增加。
- 超时错误。
- 始终保持高CPU/内存。
- 用户抱怨速度慢。
容量规划
项目成长。在您迫切需要基础设施之前准备好基础设施。
常见错误
在需要之前进行扩展
过早的复杂性。从简单开始，必要时扩展。
绕过数据库
银行往往是瓶颈。如果银行已经饱和，那么扩展应用程序就没有意义。
不要测试负载
发现受控环境中的限制，而不是高峰生产中的限制。
结论
可扩展的架构是有意识的决策的结果。了解原理，选择适当的模式，并从一开始就构建[可观察性4]。从简单开始，随着业务的发展而发展。目标是为成功做好准备。
##常见问题解答
1) 我应该从[微服务5开始吗？ 不。从结构良好的整体开始。必要时迁移到[微服务6]。
2) 哪个[数据库7扩展性最好？ 这取决于用例。 DynamoDB 和 Cassandra 的扩展性非常好。具有只读副本的 PostgreSQL 可服务于多种场景。
3) [Kubernetes8是否需要扩展？ 不一定。在许多情况下，无服务器或 PaaS 可能更简单。
4) 我怎么知道我是否需要攀爬？ 监控指标。响应时间、错误率、资源使用情况。当指标恶化时采取行动。
5) 水平可扩展性总是更好吗？ 不会。垂直更简单，可能就足够了。当垂直达到极限时，水平是必要的。
另请阅读
- [可扩展的软件架构 - 扩展的最佳实践9
- [可扩展的软件架构-初创公司的最佳实践10
- [可扩展的软件架构-小型团队的最佳实践11
- [应用程序可扩展性：完整的技术指南12
- [应用中的微服务：移动分布式架构13
- [单体 vs 微服务：选择哪种架构14