快速扩张网站的十个妙招

英文原文地址：http://java.dzone.com/articles/10-things-i-learned-about

世界各地的云专家们弹性价值主张的流量模式：

这是“难道我被玩弄了吗？（HIBP，注：这是一个网站，进入https://haveibeenpwned.com/，输入你的邮箱或者账号就可以查看是否被入侵）”，这个网站的访问量几乎是一瞬间从100每小时涨到12000-每小时。

这是上周才发生的事情，访问量在一夜之间增长了60倍：9月10日2015个访问量—9月11日124036个访问量。当访问量这样疯狂飙升时一般是因为发生了有趣的事情，在这里我将要分享两个我已经良好付诸实践的妙招。

吼吼——为什么流量涨得这么疯狂呢？那是因为新闻头条报导说500万gmail账户被黑了。当然，这则新闻指的是有500万个账号尚未查明的用户密码被俄罗斯黑客盗取了。但我们并不是用这则消息来幸灾乐祸或者恐吓世界各地的用户从而让他们使用我们的网站（HIBP）。我使用了一种比较具有挑战性的方法来收拾这个局面，下面就让我分享一些干货：

1）早作打算

你也知道，如果没有办法衡量现状你就不能改善全局，如果不能证实你的测量就不能把握未来的趋势。你可以借助以下三个工具来做这些事情：

Google Analytics：可以对目标网站进行访问数据统计和分析，并提供多种参数供网站拥有者使用。我的分析源图就是使用这个工具来获取的，特别实时的分析图表，我用它统计了特定时间的访问量（至少统计了那些不阻止追踪器的用户数）。

New Relic：如果你的网站没有使用Azure(这是一个主流工具，它是一个提供Rails性能监测服务的网站)，New Relic提供了不同级别的监测功能，免费的是Lite版本。

事实上，对于沉重的负载来说这是一个真正有用的工具，用它监测的时候还可以将系统的运行速度放慢进行观察。我在进行了分类扩展之后才抓取的上图 —— 图中展示了从凌晨2:30开始出现了许多错误并且.NET CLR的时间不短增加，你可以看到在早晨六点之前有大量的活动在进行。NewRelic同时也是一个任何时间任何地点都可以运行的工具。我只需要观察这个运行在iPad上的APP显示界面上显示的网页总请求量就可以了解所发生的这一切（这是和API的主要差别），最有用的是浏览器和服务器的时序以及浏览器的网络时延、DOM渲染（New Relic添加了一些客户端脚本来实现的）和APP在服务器端的性能的反映。

Azure Monitoring: 这个工具你也可以免费获取，它是Azure管理门户的一部分。这个工具会计量诸如付费这一类的参数，因此也是值得一看的：

它还可以用于我一会就要提及的报警。

2）警钟长鸣

我预料到周四上午将会发生戏剧性的变化，因为我的收件箱里塞满了如下所示的警报：

这是由Azure发出一个的关于CPU的警报，当CPU超过某个阈值的时候我就会收到一个这样的警报。这类警报都是在之前我提到的那个监视屏上配置的，这个警报让我料想到一些不寻常的事件正在发生。

另一个非常有用的工具是NewRelic，特别是当出现一个总故障或” Apdex”指标下降时（网站定期的去ping一个端节点并测试数据库和存储表的连通性）。Apdex是NewRelic测量用户满意度的一个方法，其实这个方法无非就是看一下数据库操作时间、请求排队时延和CLR时间是否满足用户体验度和容忍度。这是一个真正的用户：这个家伙在世界另一边的数据中心旁边的4G网络中建立一个蹩脚的连接来加载它。这里就不在说这件事情了，但这确实是周六上午我在写这篇文章的三天前Apdex发生的事情。

在最低的那个点上，超过25万的人卡得不行，虽然页面加载上来了，但就是太慢了。总之，我很高兴收到了这个警报。

当然，你一定会问——为什么系统会变慢？难道我没有“云级”吗，还是我将Azure的云级小题大做了？是的，只是我还有一个小问题…….

3）从最大值着手

如果你觉得扩张的理念比较生疏或者不清楚在Azure中怎样实现它，先阅读下上面最后一个环节的链接。简单来说，它是指增加更多同样的实例而不是扩大实例的尺度。在Azure中意味着我可以这样做：

你看出问题了吧？是的，我将计数的最大值设为3。这就是了，这就是当Azure 按照我的要求运行时Apdex指标就变差了。仔细一想，这样做其实是很蠢的：有一个东西来限制你的成本使得你直到下个月买账单的时候才震惊的发现最终扩张的实例不到十个，但是如果你收到了预警就不一样了，让我解释一下：

Azure以分钟为单位来收取费用，转到上一个实例，使用一个半小时之后关掉它，这时你需要支付90分钟的费用。不管这个实例的规模多大，90分钟之内Azure所有的功能都是免费的。如果你的预警有更高的要求（你可以通过Azure管理门户来实现），只要环境一发生变化你就可以快速扩张，尽管在发生之前取决于你的配置。考虑到长远利益，比起省钱可能导致劣质的用户体验我更喜欢多花几美元来扩张十个实例从而建立一个舒心的网站。

当然，这就要看你究竟想不想要规模，我很不喜欢你说，“哇，我的网站非常好，顶多让用户遭了一点点罪”。一些人可能会担心诸如DDoS攻击的影响，但是这一类问题你可以用上面提到的工具快速监控。

所以一定设置好你最大上限，然后设置好你的警报并停止杞人忧天。（稍后会讨论到成本问题）

4）未雨绸缪之扩大规模篇

扩张（增加实例）可以自动发生，但是扩大（使其变大）网站规模却是一个手动的过程。虽然两者都会给你提供更多的容量但是实现方法却不尽相同。在Azure有关规模的博客上，我发现从小规模的实例变成中规模的会对性能和成本产生双倍影响，从中规模编导大规模也会有双倍的变化，所以趁早加大实例就会方便你日后伸展拳脚。

当我意识到自己设置的实例上限数过低时，我不仅将每个实例而增加到10还把他们都变成了中规模的。为什么呢？部分是由于我不确定10个小规模的实例是否足够，同时我也想抛出一些重量级的资源让网站恢复正常。

另外一个方面就是尺寸大的实例不会很快被淹没。请看下面这张图：

这是在午夜发生的727个访问，凌晨1点753个，2点9042个，3点11910个，这种大规模的变化在很短的时间内发生了。回到之前提到的博客看看具体细节，你可以看看当在Azure上增加一个实例时会有什么变化（配置的一小会）如果有需求的话。将“冷却的时间设置为45分钟，以使Azure有一段时间去累积增加一个实例之后会发生的变化并观察决定是否还需要在增加一个。流量增长的如此疯狂，一个附加的小实例在冷却时间结束之前就会被淹没，一个中等规模的实例将会给它更多的喘息空间。

当然大规模的实例会有更多喘息的空间，这个需求发生在凌晨1点我们两岁的女儿吵醒了我的美梦的夜晚，我的妻子就跑去照顾孩子的时候我作为一个忧心忡忡的父亲，决定去查看有四个中等规模实例的HIBP 是否能满足每分钟2200个请求，我把实例的规模扩大后安心的上床睡觉，当然，只要你愿意你也可以增加更多的实例。（哇，小孩子实在太棒了！）

5）Azure的弹性令人瞠目结舌

很显然HIBP受到了彻底的打击，当一个网站变得手忙脚乱时就会出错，很明显的错误之一是速度变慢以及之前提及的Apdex问题，另外还有就是在该网站下的负载会抛出各种类型的错误。NewRelic可以发现上面的这些错误，下面就是它所发现的：

关键点是右上角的0.0078%错误率，也就是说，在这片文章写作的前一周，每128000个请求中就会发生一个错误。既然都是基于请求的，网站自然可以进行处理并且用NewRelic监控。红线表明HIBP的访问量会下降（NewRelic远程连接到它并且会更新检查）。说这个是想告诉你，NewRelic报告网站之前即使处于离线状态通过浏览器也可以访问到它，就是说中间掉线一会也没有问题。用ping功能发现RTT时间为2.66s。

当然网站被淹没和还没有准备好时会有网关超时是不可避免的，但在这些条件下也可以建立良好连接。

6）未雨绸缪之优化篇

这是一个关于规模的小魔法 —— 更快的网站扩张得更好。我知道，很有启发，是不是？！ :)

回想下我在十二月份写的文章：《小优化带来大惊喜》。当时红极一时的景象同样令人印象深刻。虽然和上周相比显得有点苍白无力，但是正是它迫使我优化了网站。我会给你展示我在说些什么，下面表示今天的网站：

牢记目标是尽可能扩展该网站的规模，让我们所有的请求都是加载haveibeenpwned.com：

什么？什么？是的，总共才四个请求，到特定网站的请求量低主要有三个原因：

1 我使用公用的CDN来部署每一个我能部署的设备，我将在下一点讨论这个项目情况，毕竟这些事说起来得费一番唇舌。

2 我的所有网站图标都使用Azure CDN服务商，这样使网站可以及时处理和分发到世界各地。唯一的怨言就是当我希望CDN端节点能够指向图像路径的时候我需要手动把他们放到CDN的blob存储器里面。当每一个新的转储被加载和排序时会耗时1到2分钟。

3 所有JavaScript和CSS代码都是被绑定和压缩的。较少的HTTP请求对用户来说更省流量对网站来说可以转储更少比特的请求。虽然我可以手动复制它但是将它绑定到CDN服务上回事一个号的选择，轻松的编辑代码然后让ASP.NET 去做它自己的事情比你经常改变一些东西更重要。

当然你还可以进一步的改善。首先，对网站图标来说32KB已经足够多了，从域名组合的角度来讲它是所有其他内容大小的两倍！结果证明我把它设置成64px也是绰绰有余的，理想情况下是48px。所以我把它的尺寸压缩了一半，然后放到了CDN下面并在我的模板头部添加了一个链接。每个客户端的请求都会加载这个网站和这个32KB的网站图标。这将会延续到下一次我更新代码的时候。

另一件使得网站很干净的事情是加载前一页的时候几乎没有处理过程；仅仅是由控制器返回一个视图。然而，它确实是违反Azure数据库的SQL语句操作，吞吐量如下：

哈哈 ——它几乎是线性的。是的，因为它在进行缓冲，主页几乎每5分钟从数据库进行加载（使用ping命令检查数据库的连通性，因此图中的速率为2.5cpm）。当实例发生变化和存储到另一个机器内存的时候速率会时不时的有些变动，但是这对最繁忙的页面也没有丝毫影响。这意味着数据库操作和高频率加载的服务之间是相互独立的，事实上最繁忙的查询是检查是否有人订阅已经存在数据库中的服务，它的高峰期看起来如下所示：

这里在两个小时内仅仅有34300个呼叫或者每两秒钟一个呼叫。当然这很幸运它是那种不需要频繁的访问数据库的网站，如果负载呈斜坡上升导致大量的数据库链接操作会大大削弱你的响应时间。因此我不会频繁操作数据库，我怎么检查可能被玩弄的账户呢？在我的《Azure的154百万条存储记录 – “我被愚弄”的故事》一中已经解释的很详细了。简单来说，嗯，标题什么的就不用管了—— 它是Azure存储表。正如博客里所说的，当你想通过一个关键字来查找一行结果是非常快的，正如我在HIBP所做的一样，关键字就是邮箱地址。我的意思是我的存储表如下：

两个很大的尖峰看起来很怪异，这是因为在周四早晨我加载了我的5M的gmail账户之后第二天又加载了一个5M的mail.ru账户和1M的Yandex。使得网站尽可能的忙，和11M的突破速率相比他们的速率相比不值一提。

但是我们也可以在此之前看到一些有用的状态，例如服务器平均时延为7ms。7ms！事实上，即使很大的负载延时都稳定在4ms左右。你能看到的唯一变化就是成功率和某人在查询账户无果时的简单原因。当然这是由设计决定的，如果将邮件地址查询改成有机搜索将会减少一半的时间，这个系统的设计实际上是在插入新的行，因此成功率是在上升的。

尽管这一节就要结束了，由于我的网站扩张了规模所以我可以很有效的开始使用我的网站了。我并没有夸大它们的重要性；优化对增长至关重要，即使在正常模式下使用也会好很多，所以在你需要之前及早做优化。

7）巧用带宽！

是的，对于之前提到的公用CDN，我尽量用它去做所有我能做的事。这包括jQuery,Bootstrap (CSS and JS) 和 Font。如下：

基于以下几个原因，这是一个非常明智的做法。首先，它使HIBP避免了去处理四个额外的请求和新用户进来产生的那69KB数据。好的，我将会把这些和JS、CSS绑定到网站上使得所有的请求都是一样的，但是带宽使用大体一致是我想到了一点：我不需要为数据付款。在繁忙的时候，从数百万的用户中分出多个69kb来使用，这样即使使用16GB的带宽你也不需要付款。

最后一点只是速度的问题而已。做了这么多就是为了拿下Apdex 指标并使网页为人们工作。公用CDN不仅会将数据放在距离请求较近的位置，因为他们很大很流行（很显然Google jQuery就是其中之一），会有相当一部分的人之前已经加载并且在他们的浏览器中缓存过它。不会有比从本地缓存中直接取出来更快的方式。

当谈到地理的时候，不可避免的要谈论的就是为什么我不使用Azure的流量管理，不把网站分布到世界各地的Azure的数据中心。这样非常容易做到（正如斯科特在这个链接中解释的一样）并且未来我也会这样做，不过这个时候网站绝大多数时间还在单一的一个实例中运行着。把另外一个节点放进来，比如欧洲，就会使我的网站成本加倍。请注意，如果负载时恒定的一个单一的实例还不够，在第二个位置不仅要使他更快还要在重负载的情况下扩张规模，由于离数据中心很近所以用来处理与日俱增的规模这是个聪明的方法。

8）时刻准备好快速发布

处理快速斜坡上升的请求要求你能够快速的做出反应。我很早之前决定要做的一件事就是删除一条我前几天要放弃的代码。这样做是打算摆脱另一个线程并给Google Analytics发送一个记录一个API被调用的时间，这是之前我通过客户端来追踪的一个记录（直接调用API网页会找不到用户）。我不是很确定所有通过服务器出站的请求是否会对Google Analytics有不利的影响，所以我把它给pass掉了。

想法是这样的：因为代码处于一个准备发布的状态，我所有需要做的就是改变它，放到 GitHub 上等待奇迹发生：

这是一个很低调的过程。响应时间有点混乱（我经常看到NewRelic 上显示网站反应比一分钟一个碎片还要慢的情况），但是这个问题很容易处理，并且他不会对用户有形的使用网站产生影响。关键点是我改变他们并让他们按意愿生存。当需求逐步上升时，我有一个点子是如何使用代码减轻负载。唯一的障碍就是我进行改变的能力，我不能再一个重负载的情况下对环境丝毫没有影响的快速做出反应。

当然在我已经建立自动化的情况下快速发布的能力会有所下降。四年前我写了《你的部署是错误的》，是对自动化价值进行的一系列的喋喋不休。近来，当我看到别人用Visual Studio或者god forbid可持续的基础上部署网站时我也有点畏缩了，这是FTP操作部分的解决方案。使用诸如GitHub和 Azure’sKudu服务等工具让代码变得更有意义是有原因的。这样去做别再回头！

9）精益求精——找出最佳参数

让我很高兴的一件事是不管你是扩大，压缩还是进，出网站的整个转换期间规模对记录都没有影响。当将实例规模扩大的时候我并不确定逻辑基础发生了变化是否会导致请求失败。一些图上可能会显示小高峰，但是我并有看到请求在下降或者任何显示用户请求中断的迹象。

尽管我的实例大小仍是中等规模周五晚上已经在逐步下降，并且已经下降到只有一个实例。然后一会两个，一会一个，一会又两个。然后又一会，好吧，它是下面这种情况（每种颜色代表一个不同的逻辑机器）：

就好像悠悠球一样。两个实例的平均CPU平均值在一个实例的阈值之下就需要减少一个实例，但是如果在阈值之上就要求增加一个。每次都回落到一个点上并不是一个“快乐的地方”，NewRelic会报告说 Apdex又下降了一些。显然我的CPU下边界太高了并且我需要减少一个实例以免计算功率不会造成影响。

这里会有一些别的问题；当你从两个实例掉到一个实例，你的规模丢失了50%。这是一个大跳跃但一切都是平等的，比起两个中等规模的实例四个小实例具有更多的可协调性。无论如何，我将最小的实例扩展到两个所以我可以安心的去睡觉了。最大的变化是在一夜之间从三分之二掉到三分之一这比你失去一半的马力要好得多。

即使到了周日早晨，仍然在一到两个实例之间跳跃。我已经做了一堆阈值的调整然后就不用管它哪些稍微不稳定的状态。你只要记住，只要Apdex 的数据时可取的用户就会用得很舒心，不需要频繁的切换实例。

最终，我把它设为默认这意味着增加一个实例:

这是删除一个实例：

只要这样做了之后一切就都安定下来了，Apdex 指标良好，仅在一台机器上的实例也很稳定，各方面都很舒心。

我想说的是每个app都不尽相同。不同的触发器表明的负载的变化可能对规模和节点的需求都不一样。你只需要考虑在网站不会变慢的情况下去掉不必要的成本就可以了。负载测试只能告诉你这么多；我之前做的测试只是集中在一小部分的性能上（仅仅在API上），还有一些更复杂的方法来复制真实世界的用户行为，但是没有什么像真实世界一样测量系统，这不是无中生有，而是较流行的老办法。

10）放松，只谈钱！

当一切尘埃落定之后，很多人会问，要用多少钱？这些听起来并不便宜，对吗？我们先来分析下Azure的计费门户。

首先是在这股疯狂的浪潮中的波动情况：

有一点小无奈是负载和实例随时间的变化不管在经典门户或者微软新推出的shiny one都不能良好的可视化。无论如何，他展示了我们所熟悉的规模的趋势，但我现在最关心的是收费情况。（顺便提一下，我看到CPU的占用率有些奇怪，即使没有了负载也是，我将留到最后来说）

我使用了在正常情况下通常不会使用的三种类型的资源。第一种是小型标准网站的计时。这通常很简单 —— 我整天都在使用并且只有一个实例，所以我一天付24小时的费用。你可以在下图看到前几天他都运行的很稳定：

在第10日有了跳跃，然后11日和12日相当低。然后我运行了中等规模的实例所以成本又转移到了另一层面。从上图可以看到的主要是：我的小型网站消费了25.80小时但实际上我没有用这么长的时间。很明显一天的消费超过24个小时是因为有多个实例不间断的运行。

然后是中等规模的网站。我并没有按照常规运行中等规模的实例而是在11日和12日手动扩张了网站的规模和消费时间：

所有在这里的时间都可以用于额外的负载，所以这里有55.03个中等规模的小时。

这个大家伙是我在11日的凌晨一点扩大的，因为我有点偏执狂，然后早晨起来的时候又把他们变成了中等规模的：

多个大实例立刻运行起来并在7个小时之内用了20.34的消费。噢 —— 顺便说一下，Azure的计费非常精细所以我们的账单时20.34083个小时。

让我们把他们加起来并计算出成本：

是的，总成本是21.65$。这相当于我几小天的卡布奇诺的消费。事实上，在这几天我将HIBP扩展到足以支持成千上万的这段时间内，我花的咖啡钱比这还要多。

当然，消费也会随着负载而增长，例如带宽和存储转发。但这并不重要。等等，为什么不重要呢？让我用带宽来证明：

在疯狂的使其我用了20GB额外的流量，让我们看看成本如何：

还不到卡布奇诺的一半。存储转发也是一样的—在这里他们甚至不值一提。

整个过程的消费低于25$。这就是为什么之前我写《我不需要捐款，为什么我用他们来搭建“我被愚弄了吗？”》——因为即使在尖峰的时候成本都这样低。我得到了一些善意的资助，但正如前面这篇博客解释的一样，这些消费并不会让我勒紧裤腰带。

总结

更重要的是，从我的经验来看短期内使用大规模（相对来说）是比较便宜的。从某种意义上来说，可以趁早堆积多个实例（我准备把它增加到10个）接下来我将会看看，也就是说，有四个实例已经投入使用并且负载逐步变快，我会尽早加大实例的规模。我决定比起由于规模不足而不能满足需求让用户有了不好的体验我宁愿多花点成本。

主要的事情就是对app的开发和运维。有一个能在这种情况下和正常情况下良好优化的app是很重要的。我最近看到有设计缺陷的app也会畏缩，他们从第一天起就注定了花费大量资金——缺少数据库索引，会话过程堆积如山，没有绑定客户资产——这些都会降低扩张的能力并意味着你会更快的付出更多代价。你再来看看部署也是一样的，一个家伙只是在本地编译然后将所有东西通过网络上传——这些都是不必要的。

关于Azure一类的服务我最喜欢的是他们真正的展现了网站的规模并且更民主化。任何人都可以跳到门户立刻获得服务，几年前这是由基础设施领域唯一的专业人士通过漫长的时间和昂贵的成本才能处理的“大铁”。而现在你可以通过一杯卡布奇诺的预算就可以被授权着手开始。

快速扩张网站的十个妙招相关推荐

服务器信号怎么提高,手机信号差怎么办？这里有3招快速提高手机信号的妙招！...
原标题:手机信号差怎么办?这里有3招快速提高手机信号的妙招! 随着智能机的发展,我们的生活和手机越来越息息相关了,所以现在很多人最担心的事就是手机没流量,连接不了WiFi以及手机信号差了.针对前两个问 ...
夏季快速入睡的7个妙招
1.从300倒数,每次递减3.很多人入睡难是因为无法分散注意力,而这种复杂无趣的数数方式却是一种有效的分心技巧,同时也是快速入睡的好方法. 2.下午两点后别喝咖啡.因为咖啡因的作用可持续8小时以上,5 ...
快速记忆英语单词的妙招
这么多年的一个最大感触,就是要想在成为一个高级Coder,英语水平起了很关键性的作用.大家知道,多数开发语言是老外开发设计出来的,想了解他们的思想,必须去看原滋原味的英文我们才会进步更快,看译文学习那 ...
晚上睡不好怎么办？快速入睡5个小妙招
大家在晚上是否会有睡眠不好.失眠的困扰?但是往往遇到这些情况时,我们可以怎样改善我们的睡眠状态,提高睡眠质量?可以在睡前做一些放松身心的活动,放松一下自己的心情,这样我们可以很快入睡,下面是可以在睡眠 ...
微信公众号开发快速获取openID（小妙招）
其实这个也是我个人看了好几篇博客总结出来的,现在就给大家整理在下面. 1.首先我们要获取微信code,因为在获取openID需要微信code参数,详情查看微信文档. 微信开放文档 public sta ...
如何在手机上压缩视频？快速压缩视频的小妙招
如何在手机上压缩视频?相信大家都曾遇到过视频过大无法发送,或者发送的时间过长.遇到这种情况,我们不应该盲目等待,其实我们应该想办法压缩视频的大小,这样就能提高发送的速度了.小编这里来教大家简单的操作方 ...
快速入睡10个小妙招，这些助眠产品帮你一招入睡
失眠会对一个人的身体机能造成很大的损害,长期失眠不及时改善,会导致自己身体免疫力日渐降低,但是如果长期靠服用一些助眠药物,也会对身体造成一定的损害,下面这些对身体没有损害的助眠好物大家可以试试看~ 1 ...
如何将PPT转换成Excel表格？教大家一种转换小妙招
怎么把PPT文件转换成Excel表格呢?大家对于这两种文件格式的转换见到的并不多,正因为不常见,所以在遇到的时候很难有方法能够解决.其中在工作中,用于演讲展示的PPT文件使用完后,可能里面的数据比较多 ...
avws扫描出来的漏洞怎么利用_如何用Acunetix网站漏洞扫描软件快速进行扫描？告诉您几个小妙招！...
扫描网站和网站应用需要花费很长时间.影响扫描速度的因素有: 1.网页服务器性能和响应时间 2.网站大小 3.后台数据库速度 4.扫描软件同时扫描的网站数量 5.漏洞检测的数量 6.Acunetix服务 ...

快速扩张网站的十个妙招

快速扩张网站的十个妙招相关推荐

最新文章

热门文章