建站

前言

代码部署是 Web 开发过程中必不可少的一个环节，伴随着业务的更新迭代，一个项目几乎每天都会有上线操作。

上线就意味着改变现有的页面样式或功能逻辑，这有可能会影响到用户的使用，所以上线部署代码需要谨慎操作。

但不论如何，还是有可能出现无法预料的问题，这个时候需要有快速回滚机制，让线上业务不受影响。

因此，我们需要一种简单高效的办法来部署代码，既能支持频繁发布，又能兼顾安全可靠。…

互联网时代，高并发是一个老生常谈的话题。无论对于一个web站点还是app应用，高峰时能承载的并发请求都是衡量一个系统性能的关键标志。像阿里双十一顶住了上亿的峰值请求、订单也确实体现了阿里的技术水平（当然有钱也是一个原因）。

那么，何为系统负载能力？怎么衡量？相关因素有哪些？又如何优化呢？…

提升 Web 应用的性能变得越来越重要。线上经济活动的份额持续增长，当前发达世界中 5 % 的经济发生在互联网上（查看下面资源的统计信息）。 我们现在所处的时代要求一直在线和互联互通，这意味着用户对性能有更高的期望。如果网站响应不及时，或者应用有明显的延迟，用户很快就会跑到竞争者那边去。

例如，Amazon 十年前做的一项研究表明，网页加载时间减少 100 毫秒，收入就会增加  1%。最近另一项研究凸显了一个事实，就是有一半以上的受调查网站经营者说他们会因为应用的性能不好，而损失收入或客户。…

评价一个网站的“大小”，处于视角的不同，有很多种衡量的方法，类似文章数，页面数之类的数据非常明显，也没有什么可以争议的。但对于并发来说，争议非常之多，这里就从一个技术的角度开始，谈谈几个Web网站的数量级。

相信很多人谈论一个网站的热度，总免不了会询问日均PV，同时在线人数、注册用户数等运营数据，说实话从技术角度来说，这几个数值没有一个可以放在一起比较的——一个静态网站的PV跟一个SNS类/Web Game网站的PV根本就不是一回事。由于互联网有一个传说中的“3秒定律”，可能当下更多的网站技术指标要求1.5秒以内加载整页，或者至少可以达到阅读的标准。如果要较真什么“同时在线”，毫不客气的说，对于HTTP这类短链接的网络协议来说，在WebSocket还不普及的时代，能统计在线纯属扯淡，唯一能做的只是取个时间段，计算下访问用户而已。这些依然可以换算成QPS（Quest Per Second每秒请求数）。就并发而言，我唯一推崇的只有理论最大QPS和悲观QPS。…

PS：下面是性能测试的主要概念和计算公式，记录下：

一．系统吞度量要素：

一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。

单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。…