对于前后端分离技术的理解和实现

2017-11-02 09:54:00
admin
转贴
901
摘要:前后端人员双方约定好接口的数据格式,比如:前端需要调用一个用户信息的接口,数据格式为{name:”,gender:”},那么,后端人员只需要告诉他一个接口url(如:http://192.168.1.2:8080/pro/userInfo),并且将这个接口返回前端想要的数据即可,至于后端人员怎么实现这个接口,前端人员并不关心! 前端页面用ajax解析url,获取数据进行页面端的处理,然后再按照上述地址返回给后端,就想APP和后台接口对接是一个道理。 至于前端人员要用这个接口来做什么,后端人员同样不需要关心!双方都只专注于自己需要实现的业务逻辑。

前端静态化

前端有且仅有静态内容,再明确些,只有HTML/CSS/JS. 其内容来自于完全静态的资源而不需要任何后台技术进行动态化组装.前端内容的运行环境和引擎完全基于浏览器本身.

后端数据化

后端可以用任何语言,技术和平台实现,但它们必须遵循一个原则:只提供数据,不提供任何和界面表现有关的内容.换言之,他们提供的数据可以用于任何其他客户端(如本地化程序,移动端程序).

平台无关化

前端3大技术本身就是平台无关的,而后台连接部分的本质是实现合适的RESTful接口和交互Json数据,就这2者而言,任何技术和平台都可以实现.

构架分离化

前端架构完全基于HTML/CSS的发展和JS框架的演变,与我们耳熟能详的后台语言(如C#, Java, NodeJs等)完全无关. 由于前台是纯静态内容,大型构架方面可以考虑向CDN方向发展.

后端构架几乎可以基于任何语言和平台的任何解决方案,大型构架方面, RESTful Api可以考虑负载均衡;而数据,业务实现等可以考虑数据库优化和分布式,这些领域园内大牛如云,就不再班门弄斧了.

但总而言之,前后端的分离也实现了前后端构架的分离.

分离模式的优势 
1、前后端流量大幅减少

我们知道,前后端流量的大头是HTML/JS/IMG资源,而数据仅仅是小头,资源占到100K以上的页面不算大,但数据充其量10K左右,比如一个1万条记录的数据经过压缩也仅仅在100K左右,而一个稍大的JS库或图片就不止这些.

流量的减少在于”前端静态化”这个规则,在第一次获取以后静态资源会被浏览器缓存,即使浏览器继续轮询,服务端也会返回一个非常小Not Modified响应,流量几乎可以忽略不计.

举例说明,在一个页面为100K,数据为10K的页面中,100次请求的流量是100K+10X100 = 1.1M. 显而易见,其流量是大幅低于每次获取完整HTML的情况的.

2、表现性能的提高

也有人质疑这种模式的页面性能问题,其实情况没有那么悲观: 第一次获取的确会有些许损失,但我认为,损失微乎其微,一个HTML页面的加载,同时加载10多个几十K的JS, Image的情况非常常见,再多1-2个10K的Json也并非沉重负担.

但后续使用这个页面,性能优势就完全体现了,页面的绝大部分内容都是本地缓存直接加载,远程获取的仅仅是1-2个10K的内容,其加载时间百毫秒内,这和本地页面几无区别,其前端加载和响应速度得到非常大的提高是显而易见的.

3、前后端平台无关和技术无关

前端是纯HTML技术,前端人员只需要记事本就可以开发并非一句”戏言”,而后端能够实现RESTful的框架和平台比比皆是, 完全可以选择更适合团队,人员和公司的技术路线而不在纠结于平台和技术的选择.

4、安全性方面的集中优化

前端静态化以后,前端页面攻击几无可能,一些注入式攻击在分离模式下被很好的规避; 而后端安全问题集中化了,仅仅只处理一个RESEful接口的安全考虑,安全架设和集中优化变得更明确和便利.

5、开发的分离和构架的分离

也许很多团队还是1个开发人员全包前后端的模式,但我也提到了,前端的要求越来越高,前后端人员的需求分化日益明显,一旦系统上级别上档次,其分离的需求必将出现.

前后端人员的完全分离可以使得他们在各自领域进一步求深求专,成为更加专业的高手;另外,前后端的构架也可以分开考虑和架设,前端构架就能集中考虑性能和优化,而业务,安全和存储等问题就能集中到后端考虑.

可以说受益匪浅,而针对他们提出一些的问题,也尝试在自己的构想下进行寻求解决方案:

页面逻辑和呈现效果: 还是刚刚的一句话,JS已经无所不能,依托于目前的各种JS函数库和框架,在获取到合理的数据以后,几乎没有做不出来的逻辑和效果. 我本身偏向于前端实现,对这点有疑问的朋友我们可以深入交流. 至于有些园友提出的数据校验,页面白屏,路由控制,代码复用等等问题,前端技术已经完全可以解决.

6、服务器性能和优化: 由于前端内容是完全的静态内容,在初次获取以后的大部分时间内,浏览器使用的就是本地缓存,也就是说,服务器的压力主要来自于承载数据的Restful Api调用,压力的大幅降低不言而喻.加上对交互数据的合理设计,可以说对客户端-服务端的交互量控制已经接近极限.

7、安全性: 由于前端静态内容仅仅只能获取,而后端只能接受Json,应该说,屏蔽了大量可能发生的注入型问题,而一些其他问题,比如非法对象,数据加密,DDOS等问题,这些本身就是后端人员无法回避的责任,在任何模式下都必须考虑.

跨平台,跨技术: 正如刚刚所所说, 前端技术本身无平台限制,而后端几乎任何平台都能实现.


实现

前后端人员双方约定好接口的数据格式,比如:前端需要调用一个用户信息的接口,数据格式为{name:”,gender:”},那么,后端人员只需要告诉他一个接口url(如: http://192.168.1.2:8080/pro/userInfo),并且将这个接口返回前端想要的数据即可,至于后端人员怎么实现这个接口,前端人员并不关心! 
前端页面用ajax解析url,获取数据进行页面端的处理,然后再按照上述地址返回给后端,就想APP和后台接口对接是一个道理。 
至于前端人员要用这个接口来做什么,后端人员同样不需要关心!双方都只专注于自己需要实现的业务逻辑。


顺便说一下AMS7.0预计年内发布,AMS主程序全部用C++开发,AMS通过REST API提供所有接口,并提供Web容器,AMS7将 采用JS + CSS +HTML提供一套全新的基于前后端分离技术的Web页面,基于复杂直播、点播、转码、设备管理,用户管理,系统功能等功能皆可完美呈现。

发表评论
评论通过审核后显示。
文章分类
联系我们
联系人: 北极星通公司
电话: 010-56545416
传真: 010-82896426
Email: support@bjsin.cn
QQ: 35338585
微信: Aoku2017 | QQ群:241759321
地址: 北京市中关村生命科学园创意园3-3-103