关于泰捷商城项目与如何作一个高可用的网站

hi 各位， 上两周一直都在作泰捷商城这个项目。这个项目的目的就是卖泰捷出品的WEBOX。这是我第一次作有关电子商务的网站。各类头绪。其实原始需求很简单，只卖一件商品，每星期只卖一次。 可是online to offline是历来不是一件简单的事情。由于这一次你所作的事情不只仅是在线上，而是不少事情要发生在线下的真实世界里。这是一件很是的消耗精力的事情。但人又是生活在现实生活中。好比订单的流转。由于这一次咱们不只仅是作一个订单，而是要把订单真正的转换成工厂生产出来的货物，并且要经过物流公司真正的把货物运送到顾客的手中。再好比说钱的流转，要作到即时又安全。

6月24日，商城的第一次上线就遇到了很严重的问题。事情是这样。因为程序错误，在中午12点开售的时候，倒计时完成，可是购买入口的按钮一直都没有出现。因而当时全部人开始刷新咱们的官网。而咱们的官网的首页有很是多的图片，并且有的图片甚至没有进行压缩。好比一张只有几十个像素乘以几十个像素的图片居然有1.2MB的大小。所以产生了大量的并发链接和502错误。浏览器上咱们的官网根本打不开或者是打开速度很是慢，而这又会致使更多的页面刷新。简而言之，咱们的官网瘫痪而用户请求像滚雪球同样愈来愈大，也就是服务器雪崩。

不过不幸中的万幸是虽然咱们的官网服务器崩溃了，可是咱们商城的服务没有受到太多的影响。由于它们在物理上是隔离的。并且由于官网的崩溃，避免了用户在同一时间蜂拥到商城服务器。由于崩溃的时候，咱们的运营人员在论坛和QQ群等地方发布咱们商城服务器真正的购买入口URL，但这种场景，用户是没有办法在同一时间蜂拥到商城的。咱们卖完1000台的时候已是中午1点半了，比预计的时间慢了太多。最初咱们预计在10分钟以内就会卖光。

第一次泰捷售卖就这么草草收场了。虽然不是特别成功，可是因为这是泰捷成立以来卖出的第一批WEBOX，次日咱们仍是在公司开了几瓶香槟。我想这是我最尴尬的一次庆功了。我人生中开过三次香槟。第一次是微信注册用户过2亿（当时是做为编外人员参加的，只吃饭不能抽奖）。第二次是微信海外注册用户超过1亿。这是第三次了。不过此次确实是很是的尴尬，我都没好意思喝香槟。

总结一下这一次的抢购。失败的地方：

1 购买入口放在的页面太多图片，下载速度过慢。

2 程序错误致使购买入口没法展现。

3 大量的用户刷新请求致使雪崩。

成功的地方：

1 官网服务器与商城服务器分离，一边崩溃的时候，另一边没有受到影响。

总结了第一次的得失，咱们改进的地方第一就是把咱们官网的展现购买入口的页面作的很是简单，基本上没有图片。第二在倒计时完成的时候不发起任何的动态请求。第三把官网所有改为用CDN的形式访问。其实基本上只须要把图片所有放在CDN上就能够了。不过所有放在CDN上更加保险一点，不过费用也更高。

再作一些更深层次的思考，如何作一个高并发的网站？ 如何预估一个网站的设计容量是否足够？

首先要考虑系统可能可能出现瓶颈： 带宽，并发链接数, CPU和IO、内存。如何评估带宽和并发链接数不会超限？ 首先须要预估出你的PV。特别是抢购类的网站，用户过来冲垮你可能就是开始的那一两秒钟的事情。因此你必需要搞清楚在那一两秒中的时间有多少人一块儿刷你的网页。

而后咱们发现， 带宽、并发链接数和内存是不太好经过压力测试去模拟真实状况的。由于利用压力测试比较容易模拟的是大量的重复transaction， 而很差模拟的是大量的并发transaction。好比你能够模拟100、200、400、1000个客户端去重复发送请求产生压力，但你很难去模拟1W,2W，10W个真实的客户端请求。不过，能够经过你的PV来计算出真实的带宽、并发链接数和内存。

计算方法以下：

带宽　＝　PV * 平均每页面的资源数 *平均每一个资源的大小

并发链接数　＝　带宽 / 平均下载速度 = PV * 平均每页面的资源数 * 平均每一个资源的平均下载时间

举例来讲明：

PV是100/s， 每一个页面要下载30个资源， 平均每一个资源大小为100KB。

带宽 =  100/s * 30 * 100 KB = 300MB/s 

平均每一个资源下载速度为 100KB/s

并发链接数 = 300MB/s / 100KB/s = 3000

内存须要根据并发链接数来估算，

例如当你在100并发链接时 占用1MB内存， 那么3000并发链接时， 内存估计消耗为30MB。 不尽准确，但能够做为参考。 

CPU基本和平均每秒请求量相关。

IO和平均每秒请求量先关，和CACHE大小和命中率相关。

在优化静态网站的时候，能够根据上面的公式来作优化。好比怎么下降带宽？ 回到公式， 带宽　＝　PV * 平均每页面的资源数 *平均每一个资源的大小。 能够有不少方法， 好比咱们能够经过下降平均每一个页面的资源数量来解决， 减小一些图片或者是其余资源。也能够下降每一个资源的平均大小，多使用304或者是压缩一下图片和JS等。 还有就是下降PV， 好比用一些AJAX的请求代替页面的所有刷新等。

另一个问题就是动态请求的容量如何预估的问题了。首先要压力测试去测试出全部动态请求的最大QPS。 找出QPS最低的那个请求即为系统的短板。系统的最短板的QPS即为动态请求的最大容量了。动态请求的最大容量不能知足系统的请求怎么办？ 纵向扩容， 平行扩容， 优化代码， 实在没有办法，还能够作过载保护，实现服务柔性可用。不过这个议题的内容太大，不作过多讨论了。

通过总结， 咱们在7月1日的第二次抢购就比第一次进步了许多。人生中总有不少第一次的事情会发生， 第一次可能成功也可能会失败。我想失败不可怕，关键是吸收教训作好下一次。