如何为从1到10万用户的应用程序设计扩展方案？
极客时间编辑部
讲述：丁婵大小：8.10M时长：05:54
对于创业公司来说，当用户从零扩展到成千上万之后，Web 应用程序该如何支持呢？通常来说，这种情况的解决方案要么是来自突然爆发的紧急事件，要么是系统出现瓶颈进行升级改造。虽然方式不同，但对于一个边缘项目发展成高度可扩展项目，其升级方案是有一些普适的“公式”可以套用。最近，NTWRK 工程师亚历克斯·佩拉托（Alex Perato）以 Graminsta 为例，介绍了当用户从 1 人发展到 10 万人，应用程序的扩展方法。InfoQ 中文站对其进行了编译，如下。
1 位用户：1 台机器
无论是网站还是移动应用，应用程序几乎都包括这三个关键组件：API、数据库和客户端，其中数据库用来存储持久数据，API 服务于数据及与其有关的请求，而客户端负责将数据呈现给用户。
在现代应用程序开发中，客户端往往会被视为一个独立于 API 的实体，这样一来就可以更轻松地扩展应用程序了。
刚开始构建应用程序时，可以让这三个组件都运行在一个服务器上。但是必须考虑当用户不止一位时，是否要将数据层拆分出来。
10 个用户：拆分数据层
拆分数据层，并将其作为一个类似于 Amazon 的 RDS 或 Digital Ocean 的托管数据库的托管服务。这样做虽然成本会比在一台机器上自托管高，但可以获得很多现成且方便的东西，例如多区域冗余、只读副本、自动备份等等。
100 个用户：拆分客户端
需要注意的是，拆分实体是构建可扩展应用程序的关键所在。当系统中的某一部分获得了更多流量，那么就应该把它拆分出来，根据其自身的特定流量模式来处理服务的扩展。这样就可以轻松为多平台构建产品。
1000 个用户：负载均衡器
当新用户越来越多，只有一个 API 实例难以满足所有的流量，这时就需要更多的计算能力。可以在 API 前面添加一个负载均衡器，它会把流量路由到该服务的一个实例上，通过添加更多运行相同代码的服务器来增加可以处理的请求数量。
该负载均衡器会把请求路由到任何一个流量最小的实例上。当一个实例宕机（过载或崩溃）时，其他实例也可以继续运行，响应传入的请求，而不是整个系统宕机。
负载均衡器还支持自动扩展，在流量高峰时可以增加实例的数量，当流量低谷时，减少实例数量。借助负载均衡器，API 层实际上可以无限扩展，如果请求增加，那么只需要不断增加实例就可以了。
10000 个用户：CDN
对于 Graminsta 来说，处理和上传图像为服务器带来了很大的负担。所以，它选择了使用云存储服务来托管静态内容，而 API 应该避免图像处理和图像等业务。从云存储服务得到的另一样东西是 CDN，它将在遍布全球不同的数据中心自动缓存图像。
10 万个用户：扩展数据层
负载均衡器在环境中添加了 10 个 API 实例，使得 API 的 CPU 和内存消耗都很低，CDN 解决了世界各地图像请求的问题，但还需要解决请求延迟的问题。
通过研究发现，数据库 CPU 的消耗占比达到了 80%-90%，因此扩展数据层成为了当务之急。数据层的扩展是一件很棘手的事情，虽然对于服务无状态请求的 API 服务器来说，只需要添加更多实例即可，但是对于大多数数据库系统来说，却不是这样。
要从数据库获得更多信息的最简单方法之一是给系统引入一个新的组件：缓存层。实现缓存最常用的方法是使用内存中的键值存储，且大多数云厂商都会提供数据库服务的托管版本。
当该服务正在进行对数据库相同信息的大量重复调用时，就是缓存“大显身手”的时候了。访问数据库一次，缓存就会保存信息，之后再进行相同请求时，就不必再访问数据库了。缓存服务也更容易扩展，所有高度扩展的应用程序几乎都充分利用了缓存的优势，缓存是构建快速 API 不可或缺的部分，可以提供更好的查询和更高效的代码。
由于对数据库的访问相当多，所以需要在数据库管理系统添加只读副本。借助托管服务，只需要点击一下就可以完成。只读副本将和主数据库保持一致，并且能够用于 SELECT 语句。
以上就是佩拉托团队扩展应用程序的方法，希望能给你带来参考价值。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(1)
- 最新
- 精选
小斧1 位用户：1 台机器 10 个用户：拆分数据层 100 个用户：拆分客户端 1000 个用户：负载均衡器 10000 个用户：CDN 10 万个用户：扩展数据层2
收起评论