Web扩展基本概念总结
Web扩展基本概念总结
本文转自：https://arcentry.com/blog/scaling-webapps-for-newbs-and-non-techies/ 渣翻作为自己笔记，如有错误请指出。本人也是菜鸡，接触互联网不久，对于后台开发还未入门，翻译不对的地方请见谅。
这篇文章总结了Web扩展的基本概念——从单一的服务器开始，到能够服务数百万用户的web应用，本文主要面向新手与非专业人员，大牛请绕道。
Let’s get started!
扩展…什么？！？
你刚刚建立了自己的网站，在线商店，社交网络或其他任何你想要的东西，并把它放在了互联网上，事情进展的非常顺利：每天都有几百个用户访问你的网站，请求能够得到快速的回复，订单也能即刻处理，一切看起来似乎都那么顺利。
突然可怕的事情发生了：你成功了推广了你的产品！（You become successful!）
成千上万的用户开始涌入，每时每刻每分每秒…这个对你来说无比美妙的消息对于你的服务器底层架构来说无疑是见鬼一样。因为现在它需要扩展了，这意味着它需要：
- 同时服务更多的用户
- 随时都要运行而不能死机
- 服务全球的用户
怎样扩展
如果实在几年前，本文会首先讨论垂直扩展（scaling up）与水平扩展（scaling out）的优劣。简而言之，垂直缩放意味着在更强大的计算机上运行相同的东西，而水平缩放意味着并行运行许多进程。
而现在没人再讨论这些东西了，原因很简单：
- 计算机变得更强大的同时，成本也成指数型增长
- 硬件限制了计算机的速度极限，也限制了垂直扩展
- 多核CPU意味着一台计算机也可以有效的进行并行运算，所以为什么不一开始就使用并行呢？
行，水平扩展，就决定是你了！
那…该怎么做呢？
1.单一服务器+数据库
这可能是你的后端最早的样子，单一的应用服务器运行着你的业务逻辑，数据库存储着长期运行需要的数据，看起来还不错。但这种配置想要满足更高需求的唯一办法就是使用更强大的计算机。这就没意思了。
2.增加一个反向代理（Reverse Proxy）
为你的架构做大规模扩展的第一步是加上“反向代理（Reverse Proxy）”。我们可以把它看作宾馆的前台小姐姐（嗯？！）。当然你也可以不设置前台直接让客人去他的房间。但实际上没有宾馆会这样，他们的前台小姐姐都会有序的检查客人是否能够进入房间（订没订房）并且检查房间号是不是对的。而且当某个房间需要被打扫时，前台也需要友善的提醒他们而不是让他们住到一团糟的房间里。这一切就是反向代理做的事情。代理，通常来说就是接受并且转发请求的过程。而一般来说这些请求都是从我们的服务器发送到互联网，但这次，是请求来自互联网，需要路由到我们的服务器，所以我们称之为“反向代理”。
这样的代理完成了以下的任务：
- 健康检查 ：确定我们的服务器是否还在运行中
- 路由：转发请求到正确的端点
- 认证：确定用户是被允许访问服务器的
- 防火墙：保证用户只能访问我们允许他们访问的一部分网络
3.负载均衡器简介（Load Balancer）
大部分的反向代理都有一招：他们也可以充当负载均衡器。负载均衡器是一个很简单的概念：想象一下，你的网上商城有一百个用户都准备同时付款，而不幸的是你的交易服务器只能同时处理50笔订单。怎么解决？
同时用两台交易服务器不就行了！
负载均衡器的工作是将付款请求分配到两个服务器：用户1去左边的服务器，用户2去右边的，用户3也去左边的。。以此类推
那如果有500个用户要同时付款怎么办？当然，你可以使用十个服务器，然后让负载均衡器处理传入的付款请求。
4.扩展数据库
使用负载均衡器后我们可以在多个服务器之间分担负载。但你有没有发现问题？即使我们可以使用成百上千个服务器去处理请求，但它们都是从同一个数据库存取数据。
那我们能不能用一样的方式扩展数据库呢？很不幸，不能这么做
这里的主要问题是一致性（consistency），系统的各个部分都要保证使用数据的一致，不一致的数据会导致各种问题。比如订单被多次执行：两个90块钱的订单都从一个100块钱的账户里面扣钱等等。。所以要怎么在扩展数据库的同时保证一致性呢？
我们能做的第一件事就是把数据库分成多个部分，一个部分专门负责接收并存储数据，而其他所有的部分都负责检索存储的数据。这个方案有时被称为主从配置（Master/Slave setup）或者单写多读（Write with Read-replicas）。前提是假设服务器从数据库读数据的频率高于写数据的频率。这个解决方案的好处是保证了一致性，因为数据只被写入单个实例并且一个方向流动——从写入到读取。缺点是我们仍然只有一个数据库实例要写入。 这对于中小型Web项目来说没问题，但是如果你的项目是Facebook那肯定要出事。
5.微服务（Microservices）
到目前为止，我们只用了一台服务器处理所有的工作：处理付款，订单，库存，服务网站，管理用户帐户等。
这不一定是件坏事 ——单个服务器意味着更低的复杂性，因此我们开发人员不那么头疼。 但随着规模的增加，事情开始变得复杂和低效：
- 我们的服务器的不同部分被用于不同的范围，对于每个用户登录，可能有几百个网页和资源要被处理和服务，而所有这些工作都是由同一台服务器完成的
- 我们的开发团队随着我们应用程序的发展而增长，但随着越来越多的开发人员在同一台服务器上工作，他们更有可能彼此产生冲突
- 只有一台服务器意味着如果我们想要发行一个新版本，则需要所有事情都处理完成。当一个团队想要发布新版本而另一个团队才完成了一般的工作时，那就只能打一架了
这些问题的解决方案是一个架构规范，它掀起了开发世界的风暴：微服务。原理很简单：将服务器分解为功能单元，并将它们部署为单独的，互连的迷你服务器。这样做有几个好处：
- 每个服务都能被单独扩展，使我们能够更好的适应需求
- 开发团队可以独立工作，每个团队都负责自己的微服务生命周期（创建，部署，更新等）
- 每个微服务可以使用它自己的资源，比如它自己的数据库（进一步减少了第4章中描述的问题）
6.缓存和内容分发网络（Caching & Content Delivery Networks）
比提高工作效率更好的是什么？
根本不用工作！（毕生的梦想）
我们的网络应用程序的很大一部分由静态资源组成，如图像，javascript和css文件，某些产品的预渲染登陆页面等等。我们不需要在每次请求中都重新计算或重新提供这些资源，而是使用“缓存”——一个小型存储器，它只需记住最近的结果，并将其交给所有需要的人，而无需打扰底层服务器。
缓存的大兄弟叫内容分发网络，简称CDN——遍布全求的一系列巨大缓存。它让我们能够从物理上最靠近用户的存储器来为用户提供内容，而不用每次都横跨全球传输数据。
7.消息队列（Message Queues）
你去过公园吗？有没有直接买票进场的经历？大概没有，很大可能你都需要排队等待买票。*机构，邮局和游乐园入口都是“子容量并行”概念的很好例子——他们是平行的：多个售票亭同时出售门票，但似乎永远不足以立即为每个人服务，结果就是队列的形成。
相同的概念被用于大型Web应用程序。 每分钟都有成千上万的图像上传到Instagram，Facebook，每个图像都需要进行处理，调整大小，分析和标记——这是一个耗时的过程。 因此，不要让用户等到上传完成所有这些步骤。 接收图像的服务器只做三件事：
- 存储原始、未经处理的图像
- 确认上传用户
- 添加虚拟便利贴形成一个堆，指明之后需要做的事情
自此开始，便利贴被多个服务器接收，每个服务器完成其中一个任务，勾选它并将注释放回堆中，直到我们的待办事项列表完成。管理这堆便利贴的系统称为“消息队列”。 使用这样的队列有许多优点：
- 它将任务和处理器解耦了。需要处理的图像时多时少，可用的处理器也是一样。通过简单的积压任务而不是立刻处理，我们能够保证系统保持响应并且没有任务丢失
- 它让我们可以按需求扩展。启动更多处理器很耗费时间，当很多用户尝试上传图像时，已经太晚了。通过将我们的任务添加到队列中，我们可以推迟配置额外容量来处理它们
如果我们按照上面的所有步骤操作，我们的系统现在已能够提供大流量。 但是，如果我们想要变得更大呢？还有几个选择：
8.分片，分片，分片（Sharding, Sharding, Sharding）
什么是分片？？好吧，首先深呼吸，准备好了吗，来看：
分片是一种通过将应用程序堆栈分成多个单元来并行化应用程序堆栈的技术，每个单元负责某个键或命名空间。
好吧，但其实挺简单的：假如你需要给Facebook的两亿用户提供个人资料，你可以将你的架构分成26个Mini-Facebook，每一个为不同首字母的用户服务。
分片也不一定是要根据首字母来分，你可以根据任何指数来进行分片，比如地址，使用频率之类的。你可以用这种方式对你的服务器，数据库或者你堆栈的几乎任何方面来分片，这取决于你的实际需求。
9.均衡负载均衡器的负载（Load-balancing the load-balancer）
不管你的负载均衡器性能有多好，即使你花了大价钱买了高性能的负载均衡器，单个负载均衡器能够处理的请求依然受到硬件的限制。
幸运的是，有一个全球性，分散且非常稳定的层，可用于在流量到达我们的负载均衡器之前对流量进行负载均衡。最棒的是，它还是免费的！
它就是大名鼎鼎的——域名系统（DNS），它可以将域名映射到实际的IP地址，比如将”arcentry.com“映射到”143.204.47.77“。它让我们能够为每个域名指定多个IP地址，而不同的IP地址指向不同的负载均衡器。