为什么要前后端分离
前后端分离本质上是工作职责的细化。这两年前后端分离的呼声越发高涨，最重要的原因在于后端工程师不能简单的完成前端方面的工作。前端这段时间以来新的技术层出不穷，这种情况下后端无法简单的掌握前端技术，即使对前端来说也有一定的负担。
前端的门槛越来越高，一个人无法将所有的事情都做完，也是前后端分离的一方面因素。
典型的业务场景
前后端分离其实也并非万能良药，对应不同的业务场景情况会有所不同。同样的应用场景也有所不同，前端传统的应用场景有PC端、移动端，另外还App hybrid、小程序等。针对不同的应用场景所使用的技术都会有所不同，应用场景众多让架构复杂度变的更高。
技术挑战
我们在前端方面遇到了很多的技术挑战，其中最重要的就是在大流量下要求高可用。对于访问量较小的网站，测试量并不是很大，只有在极少数情况下用户才能感知到BUG。但是大流量下感知人数会明显增多，所遇到的各方面问题也会增多，比如网络、接口缓慢的问题。针对大流量前端可以采用CDN方式抗住，这时后端的压力会比较大。当后端扛不住的时候，就需要前端来分担一部分压力，不能让用户感知到网页出现的问题，这种情况下高可用的要求会非常的高。
第二点是所有的前端工程师都非常讨厌的问题，浏览器的兼容性要求高。相信没有人会喜欢兼容IE7的需求，但是用户量多的情况下总有用会使用IE7的，为了避免用户投诉这一需求就必须得到满足。
前后端常用技术利弊
技术方案
目前使用的技术方案有四种：前端模板（Ajax + 字符串模板）、MVVM（Vue、React）、Node模板（Express + ejs）、SSR（Node + Vue SSR）。这其中最古老的方案就是Ajax + 字符串模板，它本质上是拼接字符串。
-
浏览器兼容
image
无论是服务器渲染还是平常的渲染方式都支持IE6+，使用SSR或Node做渲染在浏览器兼容方面则会比较弱。基于现代MVVM框架的技术方案，同样也处于劣势，在浏览器兼容要求较高的场合中，无法使用。
- SEO支持
对于SEO有要求的网页来说，使用web模板和Vue方案，不太合适。相对来说web模板要好一点，可以在页面未渲染之前添加一些介绍之类。Node和SSR在SEO方面问题不大，它们都是服务端渲染，首屏都包含足够多的数据。
- 首屏渲染耗时
现在的各种技术方案中对于首屏渲染耗时，显然使用Node是最快的。毕竟它是服务端渲染，数据是由Node服务端向服务提供方获取的。SSR渲染的花费时间相对于Node会多30%-50%。Web模板和Vue都是读取数据然后加载，其中Vue的渲染耗时会更久一些。总体来看在首屏渲染耗时方面MVVM框架是最慢的。
- 异步接口速度
在首屏加载完成后，很多页面都会有懒加载，需要向服务端请求相应的数据接口。这方面MVVM框架和web模板是直连后端的，而Node和SSR的方案都使用Nodejs做中间层转发一次，消耗掉一部分的网络连接，多出来的是Node服务器到服务提供方的服务。
- 高可用
Web模板毫无疑问在高可用方面是做的最好的，只要后台服务提供方没有挂，一般来说Web模板不会出太多问题。MVVM情况会复杂一些，在浏览器兼容上要求更高，测验量也会更多，但总归有些地方会测试不到。
Node作为中间平台，不仅要关心前端CDN还要注意Node服务器会不会出现问题，这样每多一个环节在高可用方面的就会差上一些。而SSR不仅要在Node上有高可用的要求，如果还引入了前后端代码同构，同构代码就有可能会在Node上出现各种问题。基于这种情况我们认为SSR在高可用方面是最差的。
技术门槛
技术的选择上首先要考虑是否合适当前团队，不同的团队情况都会有所不同。技术门槛方面就拿校招来说一般在web模板上都不会有太大问题，Vue这样的MVVM框架可能会了解一种，但是比较熟悉的就相对少一些。Web模板和Vue至少还是在前端方面，而Node情况就有些不同，它的知识点对前端来说复杂了很多。SSR情况则更糟糕，不仅仅需要知道Node方面的知识，还需要知道同样一套代码在Node上如何运行，以及SSR框架的运行情况，这样的话门槛就会更高。
前后端分离度
使用web模板或MVVM框架至少还需要和运维等人员配合找台服务器放置页面，多少还会和后端方面有些联系。而使用Node中间件则可以独立解决所有的问题。
第一个问题就是你的项目是否需要SEO。如果需要那么Node.js就是不二选择，但是也要面对Node.js的风险，目前Node.js极度缺少企业级工具，错误调试困难，资料也少于主流语言。
第二个问题是项目是否需要兼容IE，目前很多的前端工程师都喜欢使用前端框架。但是如果当前项目需要兼容IE，那么就可以和这些框架说再见了。
第三个问题就是是否有足够多的前端工程师。前后端分离的越彻底，前端工作量越多。如果没有足够的前端工程师，就会面临各种各样的招聘风险，即很难招到有经验的前端工程师，现阶段只能靠加班。
渐进式前后端分离
在前后端分离方面整体上都是转向Node.js中间件，我们有一个人数不多的架构团队，主要负责生产各种工具和中间件为Node.js服务。
对于浏览器兼容要求、可用性要求、页面性能要求都极高的页面不使用前后端分离配合少量web模板。
对于浏览器兼容要求较高的活动展示页，逐渐从web模板过渡为Node模板。 核心应用型web页，可用性要求占主导的页面，过渡为Node + Vue.js方案。某些以前用Vue编写的页面现在要想兼容SEO且对性能要求高，可以渐进过渡到SSR方案。
前后端分离在团队推进中，根据团队实际情况，也应该是渐进的。架构师要严格评估风险边界，保持业务的稳定。业务开发中，多选择新业务推进高级分离方案。对于老业务改造，应该循序渐进，选择新需求。
前后端分离的优势
前端静态化
前端有且仅有静态内容,再明确些,只有HTML/CSS/js. 其内容来自于完全静态的资源而不需要任何后台技术进行动态化组装.前端内容的运行环境和引擎完全基于浏览器本身后端数据化
后端可以用任何语言,技术和平台实现,但它们必须遵循一个原则:只提供数据,不提供任何和界面表现有关的内容.换言之,他们提供的数据可以用于任何其他客户端(如本地化程序,移动端程序)平台无关化
前端3大技术本身就是平台无关的,而后台连接部分的本质是实现合适的RESTful接口和交互Json数据,就这2者而言,任何技术和平台都可以实现构架分离化
前端架构完全基于HTML/CSS的发展和JS框架的演变,与我们耳熟能详的后台语言(如C#, Java, NodeJs等)完全无关. 由于前台是纯静态内容,大型构架方面可以考虑向CDN方向发展.
后端构架几乎可以基于任何语言和平台的任何解决方案,大型构架方面, RESTful Api可以考虑负载均衡;而数据,业务实现等可以考虑数据库优化和分布式,但总而言之,前后端的分离也实现了前后端构架的分离
前后端流量大幅减少
我们知道,前后端流量的大头是HTML/JS/IMG资源,而数据仅仅是小头,资源占到100K以上的页面不算大,但数据充其量10K左右,比如一个1万条记录的数据经过压缩也仅仅在100K左右,而一个稍大的JS库或图片就不止这些.流量的减少在于”前端静态化”这个规则,在第一次获取以后静态资源会被浏览器缓存,即使浏览器继续轮询,服务端也会返回一个非常小Not Modified响应,流量几乎可以忽略不计.举例说明,在一个页面为100K,数据为10K的页面中,100次请求的流量是100K+10X100 = 1.1M. 显而易见,其流量是大幅低于每次获取完整HTML的情况的表现性能的提高
有人质疑这种模式的页面性能问题,其实情况没有那么悲观: 第一次获取的确会有些许损失,但我认为,损失微乎其微,一个HTML页面的加载,同时加载10多个几十K的JS, Image的情况非常常见,再多1-2个10K的Json也并非沉重负担.但后续使用这个页面,性能优势就完全体现了,页面的绝大部分内容都是本地缓存直接加载,远程获取的仅仅是1-2个10K的内容,其加载时间百毫秒内,这和本地页面几无区别,其前端加载和响应速度得到非常大的提高是显而易见的.前后端平台无关和技术无关
前端是纯HTML技术,前端人员只需要记事本就可以开发并非一句”戏言”,而后端能够实现RESTful的框架和平台比比皆是, 完全可以选择更适合团队,人员和公司的技术路线而不在纠结于平台和技术的选择安全性方面的集中优化
前端静态化以后,前端页面攻击几无可能,一些注入式攻击在分离模式下被很好的规避; 而后端安全问题集中化了,仅仅只处理一个RESEful接口的安全考虑,安全架设和集中优化变得更明确和便利开发的分离和构架的分离
也许很多团队还是1个开发人员全包前后端的模式,但前端的要求越来越高,前后端人员的需求分化日益明显,一旦系统上级别上档次,其分离的需求必将出现.
前后端人员的完全分离可以使得他们在各自领域进一步求深求专,成为更加专业的高手;另外,前后端的构架也可以分开考虑和架设,前端构架就能集中考虑性能和优化,而业务,安全和存储等问题就能集中到后端考虑.
