图解：从单个服务器扩展到百万用户的系统
为新手和非技术人员扩展webapps
本指南总结了扩展的基本原则 - 从单个服务器到能够为数百万用户提供服务的Web应用程序。它面向在技术领域工作的新手和非开发人员 - 所以如果您刚刚部署了多云 - terraform-vpn-setup，那么这个不适合您。
对于其他人来说：让我们开始吧！
你刚刚完成了你的网站，网上商店，社交网络或其他任何你想要的东西，把它放在网上，事情进展顺利：每天有几百名访客通过你的网站，请求得到快速回复，订单立即处理，一切都很好地嗡嗡作响。
但后来发生了一件可怕的事：你成功了！
越来越多的用户涌入，数千，数万，每小时，每分钟，每秒......对您的业务来说，这对您的基础设施来说是个坏消息; 因为现在，它需要扩展。这意味着它需要能够：
- 同时为更多的客户提供服务
- 随时随地都可以使用
- 为全球用户提供服务
如何进行扩展？
几年前，这篇文章将首先讨论“垂直”与“水平”扩展。简而言之，垂直扩展意味着在更强大的计算机上运行相同的东西，而水平扩展意味着并行运行许多进程。
今天，几乎没有人正在扩大/垂直扩展。原因很简单：
- 计算机的成本越高，它们就越强大
- 一台计算机只能这么快，对一个人可以垂直扩展的距离设置一个硬性限制
- 多核CPU意味着即使是一台计算机也是有效并行的 - 那么为什么不从一开始就并行化呢？
好吧，水平扩展它！但是需要的步骤是什么？
1.单个服务器+数据库
这可能是您的后端最初看起来的样子。运行业务逻辑的单个应用程序服务器和长期存储数据的数据库。事情很简单，但这种设置满足更高要求的唯一方法是在更强大的计算机上运行它 - 不是很好。
2.添加反向代理
为更大规模准备架构的第一步是添加“反向代理”。把它想象成酒店的接待处。当然，你可以让客人直接去他们的房间 - 但实际上，你想要的是一个中间人，检查是否允许客人进入，她的所有文件都是有序的，并且正在前往实际存在的房间。如果房间关闭，你希望有人用友好的声音告诉客人，而不是让他们陷入困境。这正是反向代理所做的。通常，代理只是一个接收和转发请求的过程。通常，这些请求会从我们的服务器发送到互联网。但是，这一次，请求来自互联网，需要路由到我们的服务器，所以我们称之为“反向代理”。
这样的代理完成了许多任务：
- 运行状况检查可确保我们的实际服务器仍在运行
- 路由将请求转发到正确的端点
- 身份验证可确保实际上允许用户访问服务器
- 防火墙确保用户只能访问我们允许使用的网络部分......等等
3.介绍负载均衡器
大多数“反向代理”还有另外一个技巧：它们也可以充当负载平衡器。负载均衡器是一个简单的概念：想象一下，一百个用户已经准备好在给定的一分钟内在您的在线商店中付款。很遗憾，您的付款服务器只能同时处理50笔付款。解决方案？您只需一次运行两个付款服务器。
负载均衡器的工作现在是分割这两个服务器之间的传入付款请求。用户一个向左，用户二向右，用户三向左，依此类推。
如果有500个用户想立刻付款，你会怎么做？确切地说，您可以扩展到十个支付服务器并将其留给负载均衡器以在它们之间分配传入请求。
4.发展您的数据库
使用负载均衡器可以让我们在多个服务器之间分配负载。但你能发现问题吗？虽然我们可以利用数十，数百甚至数千台服务器来处理我们的请求，但它们都存储和检索来自同一数据库的数据。
那么我们不能以同样的方式扩展数据库吗？不幸的是。这里的问题是一致性。我们系统的所有部分都需要就他们使用的数据达成一致。不一致的数据导致各种毛茸茸的问题 - 订单被多次执行，两笔90美元的付款从一个持有100美元的账户中扣除等等......那么我们如何在确保一致性的同时发展我们的数据库呢？
我们能做的第一件事就是把它分成多个部分。一部分专门负责接收数据并存储数据，所有其他部分负责检索存储的数据。此解决方案有时称为主/从设置或使用只读副本写入。假设服务器从数据库读取的方式比写入数据库的频率更高。这个解决方案的好处在于保证了一致性，因为数据只能写入单个实例，并从一个方向（从写入到读取）从那里流出。缺点是我们仍然只有一个数据库实例要写入。这对于中小型Web项目来说没问题，但是如果你运行Facebook则不会这样做。我们将在第9章中研究进一步扩展数据库的步骤。
5.微服务
到目前为止，我们只处理了一台完成所有工作的服务器：处理付款，订单，库存，服务网站，管理用户帐户等。
这不一定是坏事 - 单个服务器意味着更低的复杂性，因此我们的开发人员不那么头疼。但随着规模的增加，事情开始变得复杂和低效：
- 我们的服务器的不同部分被用于不同的范围 - 对于每个用户登录，可能有几百个网页浏览来处理和资产服务，但所有这些都是由同一台服务器完成的
- 我们的开发团队随着应用程序的发展而增长 - 但随着越来越多的开发人员在同一台服务器上工作，他们更有可能互相踩到彼此的脚趾。
- 只有一台服务器就意味着每当我们想要现场购买新版本时，必须完成所有工作。当一个团队很快想要发布更新时，这会导致危险的相互依赖性，但另一个团队只完成了一半的工作。
这些挑战的解决方案是一个架构范例，它掀起了开发世界的风暴：微服务。这个想法很简单 - 将服务器分解为功能单元，并将它们部署为单独的，互连的迷你服务器。这有很多好处：
- 每项服务都可以单独扩展，使我们能够更好地适应需求
- 开发团队可以独立工作，每个人都负责自己的微服务生命周期（创建，部署，更新等）
- 每个微服务都可以使用自己的资源，例如它自己的数据库，进一步减少了4）中描述的问题。
6.缓存和内容交付网络
什么比提高工作效率更好？根本不需要工作！我们的网络应用程序的很大一部分由静态资产组成 - 永不改变的位，如图像，javascript和css文件，某些产品的预渲染登陆页面等等。我们不是在每次请求中重新计算或重新提供这些资产，而是使用“缓存” - 一个小型商店，只需记住最后的结果，并将其交给所有感兴趣的人，而无需打扰底层服务器。
缓存的更大兄弟被称为“内容交付网络”或简称CDN--遍布全球的大量缓存。这使我们能够从物理上靠近他们的商店向我们的用户提供内容，而不是每次都将数据发送到全球。
7.消息队列
你去过游乐园吗？您是否只是走到售票柜台购买机票？可能不是 - 你有可能最终排队等候。政府机构，邮局和游乐园入口都是“子容量并行”概念的很好的例子 - 是的，它们是平行的：多个售票亭同时出售门票 - 但似乎永远不足以立即为每个人服务结果，队列开始形成。
相同的概念用于大型Web应用程序。每分钟都有成千上万的图像上传到Instagram，Facebook和Co，每个图像都需要处理，调整大小，分析和标记 - 这是一个耗时的过程。因此，不要让用户等到上传完成所有这些步骤。接收图像的服务器只做三件事：
- 它存储未处理的原始图像
- 它确认上传给用户
- 它为一大堆添加了一个虚拟便利贴，指明了需要做什么
从这里开始，这个注释被任意数量的其他服务器接收，每个服务器完成其中一个任务，勾选它并将注释放回堆中 - 直到我们的待办事项列表完成。管理这堆笔记的系统称为“消息队列”。使用这样的队列有许多优点：
- 它解耦任务和处理器。有时需要处理很多图像，有时只需处理少量图像。有时很多处理器都可用，有时只有几个。通过简单地将任务添加到积压而不是直接处理它们，我们确保我们的系统保持响应并且不会丢失任务。
- 它允许我们按需扩展。启动更多处理器需要时间 - 所以当很多用户尝试上传图像时，已经太晚了。通过将我们的任务添加到队列中，我们可以推迟配置额外容量来处理它们
好吧，如果我们按照上面的所有步骤操作，我们的系统现在已准备好提供大量的流量。但是，如果我们想要变大，我们能做什么 - 真的很大？好吧，还有一些选择：
8.分片，分片，分片
什么是分片？好吧，深吸一口气。你准备好了吗？在这里：
“Sharding是一种通过将应用程序的堆栈分成多个单元来并行化应用程序堆栈的技术，每个单元负责某个键或命名空间”
...呼。那究竟是什么意思呢？它实际上非常简单：需要为20亿用户提供Facebook个人资料？将您的架构分解为例如26个迷你Facebook，每个Facebook都为不同字母的用户提供服务。亚伦亚伯拉罕？堆栈A. Zacharias Zuckerberg将为您提供服务吗？堆栈Z它是......
分片不一定基于字母，但可以基于任何数量的因素，例如位置，使用频率（功率用户被路由到良好的硬件）等等。您可以根据需要以这种方式分割服务器，数据库或堆栈的几乎任何方面。
9.对负载均衡器进行负载均衡
单个负载均衡器只能让您到目前为止 - 即使您开始购买一些功能非常强大（且价格极其昂贵）的硬件负载均衡器，但它们可以处理多少请求也存在硬性限制。
幸运的是，有一个全球性，分散且非常稳定的层，可用于在流量到达我们的负载平衡器之前对流量进行负载平衡。最棒的是什么？这是完全免费的。该层是“域名系统” - 或简称DNS。全球注册表将域名（如“arcentry.com”）映射到IP，例如“143.204.47.77”。此注册表允许我们为每个域名指定多个IP，每个IP都会导致不同的负载均衡器。
哎呀，这需要很多东西。谢谢你和我一起待了这么久。我希望这篇博文中有一些有用的东西给你。但是 - 如果你在任何与IT相关的领域工作，那么在阅读本文时可能会有一个问题：“云服务怎么样？”
云计算/无服务器
但是云服务怎么样？嗯 - 它是2018年，对于上述许多问题最便宜和最有效的解决方案非常清楚：
根本不解决它们。
相反，请将其留给您的云提供商，为您提供一个系统，可以根据您的需求进行扩展，而无需担心其错综复杂的问题。
例如，Arcentry不会执行上述任何操作（除了其DB的写/读分割），而只是将其留给Amazon Web Service的Lambda函数来运行其逻辑 - 没有服务器，没有麻烦。
但是云不是你简单开启的东西，你所有的问题都解决了 - 它带来了自己的一系列挑战和权衡。请继续关注本系列的下一篇文章，以了解有关“新手和非技术人员的云”的更多信息
原文链接：
https://arcentry.com/blog/scaling-webapps-for-newbs-and-non-techies/
