关于大型网站技术演进的思考（十六）--网站静态化处理—先后端分离—下（8）

　　我第一次据说nodejs技术大概是在2009年年底，不过我真正认真在网络上进一步了解nodejs仍是在2010年年中，当时对nodejs的认识和我如今对nodejs的认识有着天壤的区别，开始想了解nodejs我只是为了感慨谷歌公司开发的V8引擎竟然如此强大，它不只仅能够做为chrome浏览器的javascript内核运行平台，竟然还能为服务端使用javascript语言做为平台，经过对nodejs的了解让我认识到chrome浏览器是如此的优秀，可是如此相对的是我并不认为javascript做为服务端语言真的会有市场。

　　为何我当时会认为javascript做为服务端语言的前景堪忧呢？我当时有以下的思考，这些思考放到时下nodejs已经很是火爆的背景下，我相信对不少朋友任然有参考意义，下面是我当时的思考，具体以下：

　　质疑nodejs思考一：2010年以前我还不是敢自称本身是一名专业web前端的工程师，所以对于javascript的认识和掌握程度也不能和如今相比，可是对于javascript的难学，难深刻倒是有着切肤之痛，所以我想javascript做为服务端语言就是让会其余服务端语言的工程师更加深刻的学习常被服务端工程师诟病的javascript，这么作的结果无异于逼迫服务端工程师转向成web前端工程师嘛，这个想一想就让人以为不现实。

　　质疑nodejs思考二：我对web应用开发的技术选型认识比较肤浅。技术的选型是个很宽泛的问题，回到我对nodejs的质疑思考主要是体如今web应用服务端语言选择上，在中国用做web服务端开发的语言很是多，可是主流的无非就是java、php、C#以及C语言系列，固然web服务端技术发展到如今Python、ruby也是有必定市场，做为一名具体干活的软件工程师对于项目选择何种技术是没啥发言权的，所以我经常以为技术选型就是项目经理或者是技术经理以及架构师的问题，而大多时候咱们去询问为何用这个服务端语言获得的答案都是非技术性的回答，例如：公司主要是使用php啊，java比较流行人好找啊，C#开发快啊能很快的完成工做，不多有人会这么告诉你咱们的项目是个什么样的项目，这个项目使用A语言比使用其余的B语言、X语言有何种好处和优点，其实中国不少软件企业作项目在技术选型这块都很粗，说的难听点其实就是不少能控制项目的人技术水平很难被恭维，固然大部分项目其实使用什么技术实现并非过重要的问题，可是这个到了技术架构异常复杂的大型网站技术选型问题就显得尤其重要，这个认识主要是来自于我阅读《淘宝技术这十年》所感觉到的，淘宝网站的技术选型随着业务的发展变化的如此之大，颠覆性如此之高，这个在我待过的不少项目组都是难以使人想象的。

　　Web应用发展这么多年，那些占据了天时、地利和人和的现有技术基本都是处于一个垄断的地位，新的同类型语言想突破重围必然有着本身独有的技术优点，这就比如在中国作互联网若是有家新型互联网公司能够突破BAT的围追堵截，那么这家公司必定是有着本身得天独厚的优点，因此nodejs必定是得到一种得天独厚的优点，那么nodejs优点在哪里了？不过在讲述nodejs的优点以前咱们先来说讲上篇文章里遗留下来的问题。

　　其实上篇里我讲到前端MVC，文章里只是着重讲到了V层即视图层和M层即模型层的问题，而惟独没有专门讲解C层即控制层的问题。在先后端分离文章第一篇里，我谈到若是把MVC框架里的C层以做为链接web前端和web服务端的角度来理解，C层主要承担了三个方面的工做，它们分别是：路由、报文格式转化和页面渲染的工做。前端MVC在处理报文格式转化和页面渲染这两个方面仍是比较容易作到，可是在作路由这块存在必定问题，前端MVC框架对于获取服务端数据这块以及异步请求处理方面其实和传统MVC框架的处理的手段本质上是相似，只是实现载体有所不一样而已，可是控制层还有一个路由功能，其中用于页面切换的路由存在必定的问题，不过这个切换也要限定一下范围，页面经过ajax技术让页面部分刷新，假如这种部分刷新让页面展现效果发生很大变化，对于用户而言也是页面发生了切换，可是这种切换是不会让地址栏的url产生任何改变，这就是问题的根本所在了，我在上篇里已经讨论过这些问题，经过这些问题咱们发现若是页面转化时候地址栏的地址随之也发生改变是会给用户体验、网站的友好度以及SEO优化带来好处的，如是乎我提供了一种手段，那就是使用锚连接来帮助咱们实现url的变化，由于锚连接只是做用于浏览器，所以这种手段是对前端MVC的C层实现页面路由功能的一种很好的支持，可是由于这种方式须要在javascript里完成，那么对于SEO优化就产生了问题，最后我提出了页面切换咱们最好使用同步请求的方式。

　　这个时候问题来了，若是要使用同步请求，那么这个同步操做天然是要让服务端来控制，这么作的结果就是让服务端再去回收部分控制层的功能，这样下来一个使用前端MVC架构的网站就有点不太纯粹了，具体点就不是一个单页面的网站，这里咱们的讨论又回归到了单页面的问题了，前文讲前端MVC框架不少热心网友对个人论述发表了有价值的评论，可是我发现个人想法有些朋友可能没有真正理解（这也许是个人表述的问题吧），我前端MVC讲述的一个思路是以批判前端MVC的角度进行的，我早些时候和一些网友探讨过前端MVC的设计问题，有些朋友在没有作具体web前端MVC架构前老是想实现纯粹的前端MVC框架，延着这些朋友的思路咱们就会把全部的C层和M层的东西都移到web前端，我常想若是真的这么实现了，结果天然就是单页面网站了，或者就是在前端引入了复杂的模型层设计，不过探讨毕竟是探讨真的实现时候不少朋友就会知道了难度所在了，因此说理想和现实是有差距的，这话又一次灵验了。

　　这种理想和现实的差距，其实就告诉咱们必定有个地方出问题了，那么问题在哪里了？下面我将我对这个问题的思考，总结以下：

　　问题思考一：让前端承担大部分MVC的工做，那么前端自己的技术能力是否能达到全部的要求吗？这个回答彷佛是确定的，例如单页面的出现就表明了这种可能性，javascript也是拥有强大的面向对象的编程能力，所以再写复杂的业务模型层也是没问题，可是前端这么作了之后其实并不能知足全部人的需求，例如：SEO的要求，SEO不少技术都是以同步网站请求技术为根基，这个和前端MVC框架以ajax技术为根基产生了冲突，这就让前端技术产生了局限性。使用javascript面向对象技术来实现业务模型，这个也是有问题，javascript的面向对象的学习成本和精通难度超出了传统的面向对象的语言例如像java这样的语言，并且javascript要设计和写出更加容易维护的代码是很是不容易的，这么作不符合我在存储系列里讲到的要用最简单的方式实现的原则，这其实也是说明前端技术能力不足的问题。

　　问题思考二：其实无论什么形式的先后端分离方案它最根本的思想就是让先后端进行解耦，让不一样技术语言体系下的人能作到工做的隔离，最后协同起来各自发挥出本身的最大价值，可是若是咱们只是按前端，后端的角度来作分离，是否是有点粒度过粗，考虑是否是过于片面了？特别是这个片面的问题，web应用的问题并非一个纯技术问题，而是一个技术和业务结合的问题，所以任何应用于生产的技术方案都会受到业务的影响，例如上面当咱们要考虑SEO的问题，考虑开发难度的问题，那么纯粹的前端MVC的框架就会显示出本身的局限性。前端技术没法改变浏览器地址栏的url，这个从不少角度思考是个合理的设计，可是到了前端MVC里对C层的设计而言则变成了一种技术手段的局限性了。由于这种局限性就让咱们不得不回到问题的原点状态，例如页面的同步请求，而同步请求最合理的控制地点就是服务端了。

　　问题思考三：本思考是一个延生性的思考，我从事这么多年的web开发，我其实一直困惑于web应用开发和MVC的关系，为何咱们作web应用开发时候都要那么强调和重视MVC设计思想呢？难道web应用开发的世界没有MVC就不能活了吗？回首下web应用发展的历史，在web应用开发的忙慌年代，的确是看不到MVC的影子，那个时代的确很自由，自由到许多web应用混乱不堪，质量和健壮性差的不能再差了，这个时候一个英雄出现了那就是MVC，MVC表明了一种次序，一种基本的法则，这就比如人类社会创建的根本原则同样，这些原则让人类和野兽有了区别，人类也由于这些原则而成为万物之灵长，相比之下MVC就是web开发世界里的游戏规则和行为准则，所以只有当咱们从MVC角度思考web应用的建设，才会让web应用更加的优秀，这也就是在讲述先后端分离技术时候我都是以MVC思想做为准则进行思考的。思考回到具体的场景，MVC思想的运用就是让咱们把web应用开发里能够归为一类的场景汇集在一个范畴之下，不一样范畴使用一种双发均可以接受的统一准则进行沟通，这么一来咱们就把须要解决的问题简单化了，各个独立的范畴由于减小许多没必要要的干扰，所以能让它们发挥出更大的潜力，更重要的MVC还让web应用伸缩性，健壮性，可维护性大大加强。例如在不少传统web应用开发里在控制层这块先后端的矛盾就是属于MVC规则使用不完善所致。

　　单页面的应用存在不少问题，所以须要同步请求的介入，这就致使了服务端再度回收了失去的控制层的功能，这么作也无可厚非，可是我很担忧这个改进的引入会不会致使传统MVC框架里控制层的混乱问题，根据个人经验，这种混乱的程度已经下降了不少不少，基本咱们能够忽视原来C层的问题了。

　　不过不少有追求的web前端工程师对于这种不纯粹的前端MVC的异议仍是不少的，大部分异议仍是源自浏览器能力的局限性，当服务端不少方面被弱化后，也许能够解决咱们之前在前端被服务端束缚的不少问题，可是同时又产生了新的问题，这些新问题我总结以下：

　　新问题一：在传统的网站动静划分里，咱们常把浏览器端的技术html、css和javascript归结于静态技术的范畴，若是网站使用Web前端MVC那么前端就会接过不少动态网站的功能，这个时候传统的静态技术就被人为的演变为动态技术。回顾网站的发展历程，基本是从静态到动态的转变，这个结论用在时下其实已经有点不太对了，随着网站愈来愈庞大愈来愈复杂，网站技术发展逐渐开始逆向进行了，网站从动态化向静态化转变的需求变得愈来愈强烈了，这也是时下前沿的前端技术正在解决的问题，例如本系列的主题网站静态化技术就是顺应这个发展趋势而来的，因此前端MVC框架在这点上有点逆历史潮流的问题了。

　　新问题二：前端MVC让web前端的技术难度和架构难度成指数级上升，而javascript语言天生有着本身设计的缺陷，这个缺陷在写大规模复杂应用时候就显得尤其突出，例如：javascript没有模块化管理，javascript面向对象的实现难度，因此前端MVC的应用可能会变相的提高企业的技术成本和开发成本，固然不少新的技术手段能解决javascript固有的缺陷，对这些新技术有个更大的问题就是“你会吗“，不会的话首先要解决会的问题，这也是个成本问题。

　　新问题三：当前端真的愈来愈独立于服务端后，这会致使服务端一些能够优化web前端的重要技术就很难实现了，例如网站静态化系列里讲到了缓存运用，CDN的运用就很难达到预期效果，或者根本无法使用，由于这些技术的根基都是认为网站动态性是由服务端发生的，而客户端霸占了动态性，那么这些技术的做用就被限制住了。

　　由此我能够下个结论：若是先后端分离方案是以浏览器和服务器角度来划分并非最好的前端分离方案，那么先后端分离方案还有没有新的解决思路了？这个真的有，那就是nodejs参入的先后端分离方案。

　　其实先后端分离的驱动永远都是前端强于服务端，而先后端分离的重要目的也是要给web前端创造一个更加干净的开发环境，那么写的代码是不是在浏览器上跑仍是在服务端上跑这个并非过重要，因此引入nodejs，就是让服务端也能跑javascript代码并不会是让人没法接受的事情，回到先后端分离方案里以服务端驱动的先后端分离方案，我曾说过这个方案能得到服务端开发人员更多的掌声，我相信这个掌声不会是服务端为前端的喝彩，而是服务端终于从web前端解脱出来了，这样服务端运用更加高级的SOA技术就成为了可能，那么咱们把web前端的控制层使用nodejs替代，这么一来咱们既能够继承全部传统MVC框架的优势，同时也达到之前后端分离的根本的问题就是为web前端创造一个很干净的开发环境问题，那么咱们在前端MVC框架使用时候遇到的问题都会很好的被解决。

　　Nodejs的运用让动态网站的动态性再度停留在了服务端，那么我前面讲的那么多网站静态化技术就能够和先后端分离方案很好的融合了，所以本篇先不具体讨论nodejs作先后端分离的实现手段了，在下篇讲从网站静态化角度从新审视先后端分离方案时候一块儿讲解，这么作会更加符合本系列的主题。

　　如今咱们能够解答为何nodejs技术能够突破传统服务端技术的包围，由于nodejs可让先后端达到更高程度的分离，从而让先后端各自发挥本身的优点，颇有意思的是，虽然nodejs技术属于服务端范畴，可是它倒是前端工程师驱动来普及的，这绝对是web前端逆袭啊。

　　好了，本文就讲到这里，最后祝你们工做和生活都愉快。