关于大型网站技术演进的思考（十九）--网站静态化处理—web前端优化—上（11）

　　网站静态化处理这个系列立刻就要结束了，今天我要讲讲本系列最后一个重要的主题web前端优化。在开始谈论本主题以前，我想问你们一个问题，网站静态化处理技术究竟是应该归属于web服务端的技术范畴仍是应该归属于web前端的技术范畴，要回答清楚这个问题咱们要明确下网站应用的本质究竟是什么？网站的本质其实就是BS，这里的BS我没有带上架构二字，而就是指Browser和Server即浏览器和服务器，而网站静态化技术的做用目标就是让客户端即浏览器的用户体验更好，可是若是咱们想让网站在浏览器上运行的更快，在更快的基础上能设计更多更好的用户体验功能，那么咱们须要作的工做其实就不只仅是着眼于浏览器自己，而是要把和浏览器相关的一切做用因子结合在一块儿考虑，这就是网站静态化技术的本源所在，因此有些朋友认为网站静态化技术实际上是一个服务端技术多于web前端的技术，所以认为网站静态化技术是不属于web前端的范畴，我认为这种理解是不正确的，我想产生这种误导的缘由是不少人都是狭义的理解web前端技术，认为web前端就是以javascript、css以及html所表明的技术，超出这个范畴的技术就不该该属于web前端范畴，我我的以为这种理解也无可厚非，可是这种理解可能会让那些有追求的前端工程师产生一个很差的后果，这个后果就是不灵活的划分本身须要掌握的技术范畴，最终影响自身技术能力的突破，无论是web前端仍是web服务端都应该把作好优秀的网站为己任。BS自己就是一个总体，只有两者结合起来才能产生网站，缺乏其中任何一方，那又何来的网站呢？BS中的S就犹如蝴蝶效益里蝴蝶的翅膀，虽然蝴蝶看起来只是在亚马逊雨林轻轻的挥动了一下，但是这个挥动却能让相距千万里的太平洋上刮起可怕的飓风，所以本人对web前端有个新的认识，咱们不该该把前端只是局限于javascript、css和html这些技术之上，而是应该把本身当作浏览器应用开发专家，一切用做于浏览器的技术和手段都是web前端工程师须要掌握的知识，就像时下的nodejs出现，逼得前端工程师不得不去作服务端开发，不要以为这是被迫的，而要把它当作web前端的逆袭，认为这是理所固然的事情。

　　好了，咱们如今回到web前端优化这个主题吧。Web前端优化技术的普及仍是要归功于互联网两大巨头雅虎和谷歌的贡献，他们经过多年的积累和总结，将这些web前端优化的经验无偿的公布给全世界，从而推进了web前端的发展，这些技术都不是什么秘密，我在网上找到一篇讲解这些技巧的文章，文章就是《Web前端优化最佳实践及工具集锦》。

　　web前端优化技术和网站静态化技术使用目的是一致的，就是让网站变得更快，用户体验更好，我我的认为网站静态化技术其实就是web前端优化的一部分，只不过网站静态化技术是经过服务端的大规模技术改造来实现web前端技术优化，而服务端的这种改造的目的就是让整个网站的后台技术架构更加切合web前端的要求，从而能更好的实现web前端优化。我这里之因此能如此评价网站静态化技术，其实说明网站静态化技术和web前端优化技术必定存在某种强烈的切合点，我我的认为这个切合点就是它们背后使用的理论基点是一致的。那么它们之间这个切合的理论基点究竟是什么呢？

　　优秀的网站应该是用户体验好的网站，当人们使用这个网站感受爽，好评不断，那么这个网站就是一个用户体验优秀的网站，可是用户体验好的网站就是网站布局精美，图片很炫，人性化设计到位这么简单吗？这些要素都是网站使用者的感觉，可是对于网站设计和开发人员而言，再好的网站必定要解决一个根本问题，那就是网站加载的速度要快，若是网站加载速度不快，你就算把网站设计的再漂亮，估计也会搞的无人问津，说到这里，是否是有较真的朋友不信个人结论呢？我把前面引用文章里的一张图再给你们瞧瞧，以下图所示：

 

　　其实当咱们开发网站若是只考虑如何把网站作的漂亮而忽视网站的性能，咱们就会发现漂亮的网站和网站的性能实际上是矛与盾的关系，例如精美的图片每每须要高质量的图片格式，而高质量的图片格式就意味图片会变得很大，那么在图片经过网络加载时候就须要花费更多的时间，因此咱们在设计和开发优秀网站时候，漂亮和效率是须要咱们认真权衡的，认真思考的，最终要找到一个最好的方式实现两者的平衡，同时更加充分的发挥双方的潜在价值。而直观的用户体验好这其实更多的是一个设计问题，而解决用户体验好的根基：速度问题，这就是一个技术问题了。

　　要解决网站的速度和效率问题，那么咱们就得思考网站的载体计算机到底哪些因素会影响网站的速度和效率。其实计算机的本质很简单，那就是计算和存储，计算主要是CPU来完成，而计算机用于存储的介质就多了，它们主要是内存、硬盘，若是是网站应用还有个很关键的存储介质须要考虑那就是网络了。那么计算机用于计算和存储的这些介质的效率是怎样的一个状况呢？这个问题我在之前一篇文章里有过阐述，这篇文章就是《关于如何提升Web服务端并发效率的异步编程技术》

　　这篇文章的其余内容太多了，我把关键部分在本文摘抄一遍，内容以下：

对于一个网络请求的处理，是由两个不一样类型的操做共同完成，这两个操做是CPU的计算操做和IO操做，若是咱们以处理效率角度来评判这两个操做，CPU操做效率是光速的，而IO操做就不尽然了，计算机里的IO操做就是对存储数据介质的操做，计算机里有以下几个介质能够存储数据，它们分别是：CPU的一级缓存、二级缓存、内存、硬盘和网络，一级缓存存储和读取数据的能力接近光速，它比二级缓存快个5倍到6倍，可是无论是一级缓存仍是二级缓存，它们存储数据量太少了，作不了什么大事情，下面就是内存了，以一级缓存的效率作参照，一级缓存比内存速度快100多倍，到了硬盘存储和读取数据效率就更慢了，一级缓存比硬盘要快1000多万倍，到了网络就慢的更不像话了，一级缓存比网络要快一亿多倍，可见一个请求处理的效率瓶颈都是由IO引发的。

 

　　因而可知网站的速度和效率问题彷佛都是由存储即IO形成的。不过咱们不能由于感受发现问题根源在于存储，而就忽视对CPU的思考，因此我先讲讲CPU和网站性能的关系吧。CPU是计算机用于作计算的设备，如今的电脑能看电影，能听歌，能够和朋友聊天，还能用于工做，这些使人称奇的功能其实到了CPU这里也就是经过加减乘除这类基本的数学运算完成的，说到这个真是难以让人想象，读书时候学数学老是以为那么枯燥乏味，没想到如此强大的人类神器竟然就是经过数学运算得来的，难怪有国外科学家说宇宙都是经过数学运算得来的，这仍是有道理的。不过网站背后的数学运算却有着本身的特色，虽然CPU计算能力很强，可是在实际场景下不少业务的计算其实很消耗时间的，若是网站某些请求响应背后的运算是须要消耗太多的时间，那么这个时候CPU也就会成为网站性能的瓶颈所在，网站应用有个重要的特色，这个特色有个专有名词描述那就是网站的实时性，根据网站实时性的特色，那么就要求咱们网站每一个请求所包含的计算都要简单和快捷，简单快捷的计算也就让每一个请求背后所包含的业务性运算要更加简单，这也就是为何不少人会说互联网的网站和企业的web应用相比，互联网的业务逻辑比较简单的道理，可是随着网站的规模扩大，业务模式愈来愈丰富，这个时候网站在某些业务环节不可避免的变得复杂，假如这些复杂的业务又须要实时的反应给用户，那么CPU不能快速完成业务计算就是网站的效率问题的根源了，例如我在存储系列里说到的海量数据的计算操做，就是这样的场景之一，那么这个时候咱们该如何来作了？

　　碰到这个问题，咱们首先要明确一个问题，计算出现了瓶颈，那么最直接的手段就是增长计算机的计算能力，好比使用运算更快的CPU，可是更快的CPU面对快速增加的业务而言，增长的效率是很是有限的，因此在CPU这块出现了多核技术，咱们能够把一个计算任务拆分红诺干个子运算，这些子运算在不一样CPU上计算，最终把结果汇总起来，可是这个手段和用更快的CPU手段同样，面对快速增加的业务很快就会达到性能瓶颈，最终咱们发现咱们的业务计算任务其实已经超出了单机计算机的能力，如是乎分布式技术出现了，咱们这回再也不是在CPU上作文章了，而是使用多台计算机联合计算，可是分布式计算系统是须要网络进行互联的，而网络是计算和存储里最大的短板，再加以如今互联网的所使用的计算资源规模达到了超乎想象的程度，咱们发现想经过扩展计算机的计算能力来解决网站快速响应的问题基本是一件没法完成的任务，那么这个时候咱们又该怎么办呢？

　　这个时候咱们就要转化思路了，由于当网站的计算瓶颈问题已经到了这个地步了，咱们再去更加深刻挖掘计算机的计算能力这对最终的结果影响已经意义不大了，所以咱们只能从计算的相关方哪里寻找问题的解决方案。那什么是相关方呢？仔细分析计算相关方的确太多了，可是有一个最根本的相关方就是用户的实际业务需求了，用户可能认为本身的业务需求都是很明确的，例如电商里的用户想查询本身的交易数据，可是这个业务问题转移到网站的开发人员和业务人员，面对这么多用户的交易查询那就是一个超级复杂的计算问题，如是网站的业务和开发人员就会根据本身系统自己的特色和问题，进一步思考用户业务计算问题的本质，谈论业务计算本质这个问题若是展开细化是很是复杂的，由于现实的业务场景实在是太多太复杂了，可是放到网站实时计算这个角度，其实有一个很简单的解决思路，咱们回顾下咱们前面讨论的计算瓶颈问题，其实这个问题的本质不是计算可否成功完成的问题，而是计算是否能及时完成的问题，若是用户的请求计算的确是无法很快完成，那么咱们就不要让用户以为这个计算是能很快的完成，这个作法也有一个专有名词那就是异步计算，可是若是咱们把难以快速完成的计算都这么来处理，虽然让用户感受网站已经很坦诚的告诉本身能力有限啊，可是苛刻的用户可不必定会买这个帐，所以当有同类型网站使用新的技术手段解决了快速实时计算问题后，假如咱们的网站仍是驻步不前，那么后果就会很严重了，那么这个时候咱们又该如何突破了？

　　那么咱们就得进一步思考计算自己到底哪里出现了影响速度的问题，计算自己包含三个方面，首先是用于计算的计算资源，再就是作运算的工具即CPU，最后是计算的最终结果，若是业务计算慢的缘由是由于数据量太大了，CPU很难快速完成，那么这个时候咱们有一些手段能够解决这个问题，咱们能够把海量数据作一个分类，例如存储系列里说的历史交易数据和当日交易数据的分类，当日数据由于数据量有限在必定条件下能够快速计算出来，面对历史数据，若是咱们的计算结果最终是很简单的并且在必定时间范围里是不会变化的，那么咱们可不能够这么考虑，让这些结果提早计算出来，而后将结果存储在效率更高的存储设备里例如内存，当用户请求操做这个业务计算时候咱们只须要直接读取缓存里的计算结果就好了，这样就避免了计算，同时计算结果存储在效率高效的缓存里，用户得到响应的速度也会快多了，这个其实就是网站静态化技术里ESI技术背后的深意了。

　　固然当咱们要解决网站性能问题，不太可能单独从计算或者存储一个维度来思考，通常都是把双方放在一块儿思考，按照我前面提到计算和存储介质的效率问题，咱们发现存储实际上是最容易影响网站效率的痛点，实际状况也是如此，当网站发生计算瓶颈问题以前，更多的效率问题仍是由存储所致使的，并且复杂计算过程也是须要存储参入才能正常完成，例如计算过程里的中间结果当超出CPU缓存大小后咱们就不得不将中间结果放到内存里，当内存也不够的时候咱们就得放到硬盘里，因此解决计算效率问题也受到存储性能很大的影响。假如咱们仍是按照木桶理论来理解这个问题，咱们发现无论是单纯的存储问题仍是计算和存储混合的问题，最终的短板都是其中效率最差的哪一方，而计算和存储里效率最差的一方就是网络了，不过有些马虎的朋友可能说如今宽带好快了，我在网上下载一部几个G的电影也就几十秒，甚至有时比我硬盘拷贝还快，像你说网络是最大的短板其实不许确的，这位朋友的想法的确有他的道理，可是不是每一个人使用的网络都是你那么快呢，并且如今移动互联网已经普了及，移动互联网速度比普通宽带就差多了，并且你在移动设备上使用网络流量越大，成本也就越高，若是你认为我说的这些问题都不算啥，网络还和地域的距离有关，你宽带很快，你想访问大洋彼岸美国的网站（这个网站在中国没有任何缓存处理），访问速度确定仍是快不起来，并且互联网的连通路径自己也很复杂，例如你感受本身访问的是一个上海本土的网站，可是这个网站说不定好多重要服务器是放置在北京，这么复杂的网络环境，这么多不可控的因素还会影响网络的传输效率，网络谈何能说本身性能比硬盘强呢？

　　由此咱们就能够发现谷歌和雅虎总结的web前端优化技巧以及我这里谈的网站静态化技术大部分都是围绕如何解决网络传输效率来进行了，由于它是整个木桶最大的短板，咱们只有首先解决了这个短板，那么再去解决其余因素的效率问题，才能发挥其做用。这里的这个解释也能够解答前不久一个网友问我，为何我讲网站优化不多讲解如何编写高效的代码，而都是从一些和代码无关的角度来阐述的了，其实你想经过代码优化提高网站性能，你首先要解决好对网站效率影响更大更关键的要素例如网络通信问题，不然你代码优化的再好，对最终效果影响都是有限的。

　　看来本文今天写不完了，关于存储和web前端优化的内容我将在下一篇文章进一步讨论。最后祝你们晚安，生活和工做愉快。