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