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

　　先后端分离的主题虽然讲完了，可是先后端分离的内容并无结束，本篇将继续先后端分离的问题，只不过此次先后端分离的讲述将会围绕着本系列的主题网站静态化进行。在讲本篇主题以前，我须要纠正一下先后端分离主题讲述中会让朋友们产生误导的地方，这种误导就是对时下流行的一些先后端分离方案（没有使用nodejs的先后端分离方案）的评价问题，其实本人任然以为无论什么样的先后端分离方案只要成功被实施，而且产生了良好的效果，那么它就是一个成功的先后端分离方案，前面我以一种批判的角度讲述这些先后端分离方案，并非想在否认它们，而是出于一种鸡蛋里挑骨头的较真态度想从新审视这些方案，但愿这种审视能让咱们的设计方案变得更加优秀，同时本身也在这个较劲的过程里获得自身技术能力的提高。其实那些被我批判的技术方案也许在某些特定场景下它就会变的更加优秀，我推崇的技术方案在某些场景下可能就变的苍白而无力，这种状况颇有可能发生，不说别的，我之因此批评前端MVC，其私心就是由于它不符合网站静态化的处理，若是把前端MVC内容放置在网站静态化的主题下谈论，被批的命运那是必然的。

　　网站静态化技术相对于先后端分离技术的关注度要低的多，若是业界的一些公司由于看了本人的文章能对网站静态化技术有一种新的认识，从而考虑在本身网站上使用网站静态化技术，同时也想实现先后端分离技术，那么新的问题出现了，这两种技术同时使用会发生矛盾吗？若是有矛盾，咱们到底将如何解决这些矛盾？解决这些矛盾的时候咱们是否是能够作好二者的兼顾，而不会发生其中一方妥协于另外一方，最终致使其中一方没有充分的发挥本身的能力。要解答上面的一系列问题，我首先要探求的就是网站静态化技术和先后端分离方案里那些方面会产生矛盾。

　　从我前面对网站静态化技术的阐述，咱们知道网站静态化的技术最佳做用位置应该是服务端而非是浏览器端，之因此会这样是由于网站静态化技术的技术基础是动静分离和缓存，这两个方面若是落到浏览器端会碰到不少难以解决的问题，那么咱们要分析下这些难以解决的问题，具体以下：

　　浏览器之缓存问题：浏览器也有缓存，不过浏览器端的缓存那就不是指内存里的缓存，而是持久化的缓存，实际上浏览器端的缓存很是不可靠，会被不少非技术的因素所限制，例如咱们手动删除缓存或者使用无痕模式上网，那么这些持久化的缓存就会失效，用户再度访问网站时候都将是第一次访问这个网站，这就使得不少优秀的缓存策略方案在浏览器端实施效果大打折扣。

　　浏览器之动静分离问题：网站静态化技术里一个重要的手段就是如何设计动静分离策略，纯粹的静态内容这个没啥好说的，可是动态的内容在必定的条件（例如：时间，一些业务属性例如商户属性）下是能够转化为静态内容，这些内容若是能被有效缓存，对网站性能提高是不可估量的，并且这种动静转化的策略也能够减小业务服务器上处理没必要要的请求，从而减轻业务服务器的压力，达到提高后台核心业务服务端的负载压力。可是若是咱们使用前端MVC框架，一股脑子把不少服务端功能往前端迁移，那么这种动静处理手段就很难作，并且不少场景基本上是没法应用了。

　　所以我认为先后端分离方案使用nodejs价值更高，由于使用nodejs咱们就能够根据网站静态化技术将须要保留在服务端的功能能够继续保留在服务端，这样就能达到两者兼顾的目的。可是若是咱们认为把nodejs引入后，nodejs的目的就是用来作网站总体MVC架构下的C层即控制层，这个思路到底合理不合理呢？这个问题仍是很值得玩味的，所以咱们须要分析下网站总体MVC架构下的C层即控制层的做用。

　　在前面文章里我曾总结过C层即控制层在MVC框架里的做用，这个做用分别是：路由、报文格式转化以及页面渲染，可是这个做用的总结我是有个前提条件的，那就是以C层即控制层做为先后端沟通介质的前提下。若是先后端分离方案引入后把控制层归为前端的组成部分，那么控制层跟前端的结合问题都是人民内部的矛盾，都是比较好解决，可是控制层就仅仅是用来链接先后端一个做用吗？对于网站架构里的控制层，有一个不可避免的功能那就是做为后端服务端的安全入口的做用，也就是说控制层是作请求安全检查和安全监控的地方，并且不少安全校验还会和业务相关，例如检查报文是否被篡改啊，防钓鱼的功能，若是这些功能被前端来承担，首先不谈前端技术人员会不会作这些，可是至少一点问题是会发生的，前端工程师在关心页面开始同时还要写服务端的业务逻辑了，无论怎么说，这些功能迁移到前端总不是太合适。当网站演变为超大型网站后，大型网站每每是不少小中型网站项目的集合体，为了减小网站总体的异构性，咱们经常把不一样的模块网站的入口整合在一个大型控制层项目下面，这个大型控制层项目通常称为网关项目，它的做用和网络里的网关很是类似。除此以外，还有些网站的控制层很是特别，例如一些作第三方支付的网站，那么这样网站项目自己就是个大网关，并且这个网关很特别，它后台的服务就是其余银行的系统，它的路由工做就会变得异常复杂，例如：根据用户使用银行的不一样，控制层要组装不一样的报文信息，而这些功能都是属于控制层，这样的场景无疑大幅度提高了控制层再和模型层对接的技术难度，而增长的难度问题又和模型层耦合度很高，因而可知，web应用总体的MVC的控制层比咱们想象中要复杂的多。

　　回到用nodejs替代控制层这个主题，咱们来看看实际的场景吧，假如咱们的网站控制层相对比较简单，好了，这时候咱们跟领导或老板说“如今很流行先后端分离，咱们项目也使用下先后端分离技术”，领导或老板一听可能会为之一振，那么就会问你”那么该怎么作了”，你这时对他说“首先把控制层用nodejs重写下”，领导或老板听到这个回答他会赞成你这么干吗？一个不会给网站增长任何新功能，同时不能很直接有效的提高网站的性能，并且执行它还会有很大风险的方案，头儿们会赞成吗？好了，假如你终于找到合理理由说服头儿们，那么若是咱们的网站规模已经很大，控制层已经演变成了网关项目，控制层自己已经巨复杂了，你敢用nodejs重写一遍网关项目吗？因此说吧nodejs直接当作控制层，其实实践起来困难重重，并且nodejs彻底承担控制层，它的性能，它可否很好的运用于集群开发这都是很难把控的问题。分析到这里，咱们彷佛又进入了死胡同了，那如何来破这个局呢？

　　上面的问题只是反映出整个网站MVC里的控制层其实还有部分功能是和服务端的模型层紧耦合的，所以要解决这个问题就是把传统的控制层再细分一下，属于前端的部分划分给web前端做为web前端的控制层，属于服务端的部分任然留给服务端，这么拆分后，当咱们引入了以nodejs为基础的先后端分离方案，服务端的控制层改造无非就是去掉页面路由，页面渲染，再修改下返回数据格式便可，由于不用修改服务端的业务代码，其代价是很低的，头儿们也很容易接受这样的方案，并支持咱们大胆去尝试新技术。

　　服务端网站静态化技术SSI和ESI，主要是根据动静分离策略把网页不会常常变化的模板进行缓存，而后在静态资源服务器位置整合动静资源，若是咱们使用nodejs只是简单替换原来的控制层，那么这些策略其实仍是有问题的，那么怎样作可让nodejs兼容SSI和ESI了？这里我列举个实际的案例，nodejs有一个模板语言叫作jade，nodejs里还有个技术叫作handlebarsjs，其中handlebarsjs和struts的标签相似，它能够处理一些简单的业务逻辑，咱们开发时候使用jade编写页面的模板，使用handlebarsjs让动态数据和模板进行整合，项目发布时候，使用像grunt这样的项目管理工具编译项目，jade文件变成html文件，而handlebarsjs则会转化为javascript代码，这样咱们就能够把生成的html文件在服务端进行有效缓存，而handlebars生成的javascript文件负责整合动静数据，这样nodejs就能够达到兼容SSI和ESI的做用了。

　　不过引入nodejs会让网站处理请求的过程里增长一个环节，这样可能会致使部分性能的损失，可是我上面的实例却能有另外的方式规避这个问题，由于nodejs的代码是用javascript语言编写的，那么这个代码是能够运行在浏览器上的，那么这就会产生了一个处理手法，那就是咱们在生产部署时候其实不须要部署nodejs的，咱们把静态模板就缓存在服务端或者推送到CDN上，而后handlebarsjs生成的js代码就让它传送到浏览器端，由于这个js代码生成后基本不会变化，浏览器能够缓存它，固然CDN或静态资源服务器也能够缓存它，其实它在浏览器运行时候变化无非就是获取一次服务端数据而已。这么一来，生产上的web前端又转变成了前端MVC的形式，还把动静整合的事情交由了浏览器来完成，这不只是兼顾的网站静态化要求，还让动静整合推到了更加靠前的浏览器端，这不是达到了一个共赢的效果了嘛。

　　好了，本篇就写到这里，最后祝你们晚安，生活愉快