[架构设计] 前后端分离开发部署模式 | IT知识库
-& 正文阅读
[架构设计]前后端分离开发部署模式
前后端分离开发部署模式
这周着手开始重新构建官网，OTA1.3V继续推进，目前分为了企业版，与国外版，老官网那套架构的代码经过几千人手的改动，于是索性干掉，采用新的架构模式(前后端分离开发部署模式)，找到下面这篇文章我觉得说的挺好，在开始讨论这个话题之前我们先来认识一下传统的开发模式。一、传统开发模式相信很多做过Web开发童鞋应该都会经历这样一种开发模式，利用后端语言提供的模版引擎编写HTML／XML页面，比如：PHP 开发有 Smarty模板引擎Java web工程有jsp页面Python 各个Web框架都有各自的模板引擎NodeJS 的express你懂得都有一个共同的特点，服务器端后台语言生成解析后的HTML/XML格式返回给客户端，例如浏览器端访问直接返回解析好的HTML，浏览器直接就解释执行。二、Ajax过渡Ajax是把前后端分离部署的推进者，当时网页局部更新就是未来前后端分离的开端。那什么是前后端分离开发呢？简单来说就是前端开发不需要部署后台语言那堆垃圾环境，后端开发也不需要前端写好的任何程序，后台只管暴露各种API接口提供前端进行数据的增删改查，不负责生成HTML页面前端请求到数据后再动态声称dom节点。三、前端构建相对于后台来说，前端构建是重点，因为前后端分离开发后侧重点在于前端，后端就是一个数据提供，权限控制api。后端项目通常都带自己的Server，除了PHP以外，所以后端做PHP开发的还需要一个WebServer，Apache就是经典配合，最近被抛弃换做Nginx了，所以后台环境本来就是伪生产环境。前端项目还是要搭建一个Server，然后把项目丢里边才能跑起来调试开发，最笨的直接整一个Apache或者Nginx也可以，但这样开发还是很痛苦。可以利用Node工具集即可，Node工具集非常多，比如我非常喜欢用的BrowserSync。四、解决请求问题前后端分离后，我们只需要Server端告诉我们Api URL即可，那么这会产生一个问题：Ajax跨域。这里就不能使用一般的跨域解决方法去解决，比如jsonp,iframe信使等等，因为我们还有POST请求。于是Http Proxy类工具就有用了，比如我就会在BrowserSync加入中间件判断每一个请求，如果是/api前缀就会代理到API Server端，API Server端收到数据后再返回给BrowserSync，BrowserSync再返回给浏览器端。这样就解决跨域请求的问题生产环境有两种部署，一种是放到后台项目里，这就没啥说的，另外一种就是前后端分开部署，那就在前端WebServer处理端写点转发规则就好，如Nginx，Apache都支持。五、静态资源路径问题如果你的项目有上传资源功能，那自然就会产生用户资源，那前后端分离后，如何来处理这个问题呢？得先看模式。资源与后台项目放一起，后台处理完后需要返回前台一个相对路径，如果资源时一台单独的服务器，那就需要返回资源的绝对URL即可。六、会话Web项目最头疼的就是无状态导致会话问题，传统的Web项目都使用Session/Cookie，但在前后端分离，集群部署模式下这Session明显缺陷太多。token方式已经是当前Web端解决会话的主流，并且有很多开源好用的token生成管理程序，基本上拿来就能用。最后前后端分离的弱点，无非有两点1、前端负载增多，如请求到列表后，前端需要自己遍历数据集声称DOM节点 （目前绝大多数用户的电脑配置都不差，而且浏览器内核已经不在是满身缺陷的IE浏览器了）2、不利于蜘蛛（其实现在的部分蜘蛛已经很厉害了，能够支持H5 C3效果）强点，1、Web端就像手机端的App一样，不需要Cookie/Session，与Server完全分离，易于维护、扩展。一个Server API可以随意服务多个Web App2、AngularJS用过了以后，你应该会感觉未来的Web开发模式，AngularJS在几乎是前后端分离的领航者3、前端静态资源与后台API分流，互不影响，甚至不会存在IO问题4、开发上与后台几乎同步，互相不影响，特别是基于RESTFul API风格，更是减少了沟通的成本5、方便各自debug，JAVA开发人员不需要跑到前端开发人员机器上看tomcat控制台的报错，前端开发人员也不需要跑到后端开发人员的机器上看浏览器报错调试开发阶段目前需要考虑到的问题:1前端负载的问题2前端跨域调用问题3安全性考虑(可能遭遇到相关的刷接口，xss攻击等)4用token传递表示状态，token的安全性问题
获取【下载地址】&&
加: 01:06:49&
更: 01:07:03&
&&网站联系: qq: email:&基于 Node.js 实现前后端分离
作者：亚里士朱德
字体：[ ] 类型：转载 时间：
为了解决传统Web开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的NodeJS，试图探索一条全新的前后端分离模式。
首先从一个重要的概念“模板”说起。 广义上来说，web中的模板就是填充数据后可以生成文件的页面。 严格意义上来说，应该是模板引擎利用特定格式的文件和所提供的数据编译生成页面。模板大致分为前端模板（如ejs）和后端模板（如freemarker）分别在浏览器端和服务器端编译。
由于当场有一部分同学对node.js并不是很了解，这里补充一下node.js的相关知识。官网上的给他的定义事件驱动、异步什么的就不说了。这里借用朴灵书上的一张图来解释一下node.js这个玩意的结构。如果懂java的同学可以将其理解为js版本的jvm。 浏览器一般包括渲染器和js脚本引擎，以chrome浏览器为例，用的webkit内核的渲染器，V8的脚本引擎，而node.js用到了v8引擎。总而言之它就是一个js的运行环境，就好比浏览器的F12调试工具，只不过node.js没有DOM和BOM。
这张图描述的是node.js周边的一些信息，比如npm这个出色的包管理器和cnode社区以及github，都在一定程度上促进了node.js的繁荣，提供了技术保障。
大公司通常都是技术的风向标，例如google的angular、facebook的react现在都很火。这里只列了3个大公司当作例子。淘宝的中途岛架构就不用说了，国内node.js的先行者朴灵就来自淘宝。去哪儿也出了个应该叫做“QTX”的技术框架。360月影带领的75团队出了个基于ES6/ES7的web服务器框架——thinkjs，当时我们技术总监很看好，但是由于鄙人没有时间学习ES6再加上插件不够丰富，所以还是选用了较为成熟的Express。
言归正传，这个表格列出了我所接触过的3种前后端分离的开发方式。 第一种是最常见的使用java之类的后端语言模板，SEO友好，缓存利用率和减轻浏览器渲染负担方面都比较好，最大的问题就是模板文件的耦合度太高，出了问题谁都不想来解决，前端人员看不到数据，后端人员不懂页面，模板文件就像是一个烫手的山芋。 第二种是目前我们项目移动端的实现方案，利用angular这种框架（angular的指令可以看成是前端模板）和nginx这种反向代理服务器，让前后端彻底解耦，只通过ajax交互数据。这种方案和前一种的优缺点刚好相反。前端模板的性能始终是个问题，尤其是在移动端，更尤其是在低端的移动设备上。 最后一种是新项目使用的用node.js做前端服务器，将前端的职责从浏览器划分到了模板这一层，解决了以上所有的问题，不过确实也有新的问题，这种问题稍后再分析。
当然全栈开发在小型项目中也是非常适合的。对于传统的jsp/php开发来说，全栈开发的沟通成本更低，开发人员能更容易理解整个功能模块，从而更好的还原产品的设计。尤其现在出现的以js语言为基础的全栈开发：meteor和MEAN技术，更是使得前后端开发用一种语言直接搞定，再配上Mongodb，数据从浏览器到数据库都无需转义直接使用，还不用写sql，开发成本又大大降低。
这次搭建node.js服务器用到的一些插件。 鼎鼎大名的express不用多介绍了，轻量级web服务器框架。 用handlebars模板引擎也属巧合，因为express4默认就是它，handlebars不愧为“弱逻辑”的模板引擎，主张的是减少模板逻辑，尽量只用变量和分页，基于它的设计理念，我只扩充了两个helper。具体文章：superagent的使用还是因为express4，因为它的测试代码用的是supertest，supertest是基于superagent，所以用了superagent来转发和发起请求。superagent还是太弱了，长连接都无法建立，还是推荐request插件。 restfuleAPI就没什么好介绍了，前端服务器与浏览器，前端服务器与后端服务器都是用的这一套规范，基本上就是url指向资源，增删改查又具体的请求方法表示，状态码表示结果等~ gulp打包工具，webpack研究了很久，发现每增加一个页面都要修改配置文件，这个太蛋疼，遂放弃。
如果这次分享主要是讲怎样将node.js做为前端服务器来实现前后端分离的话那也没什么好讲的，看看淘宝UED的文章就好了。前后端分离其实最大的问题是带来沟通成本的上升，具体来说就是接口的定义和调试。在上图的传统开发流程中，接口的定义会放在接口服务器中，然后前后端各自根据接口文档造假数据进行本地调试，之后进行联调。这个环节就是前后端开始撕逼的时候了，这个参数不对，那个返回值不对，总之很浪费时间。接下来看这个问题在我们项目中是怎么解决的~
前后端因为接口撕逼的问题一直存在，作为保守主义的我相信迭代开发，所以第一步做的只是增加了一个mock服务器。这个服务器的神奇之处就是根据接口文档自动生成假数据，实现了接口即API，前端同学再也不用把数据写死进行测试了。没办法，谁叫我是前端开发，首先想到自己人，嘿嘿~当然这个只在一定程度上有利于前端开发，后端的接口和文档不一致联调时也会出现问题。怎么办？
偶然在破浪大神的博客上看到老马的一篇专门讲前后端分离的文章，其中一个重要的概念就是契约测试也叫双边测试吧。核心概念就是为了解决远程联调的问题。对前后端的参数都进行校验，要求大家按照接口文档进行开发。受其启发，加入json-schema规则，实现了对http请求的参数校验，谁不按规矩来谁改。
这个redmine是我们最早的接口文档管理器，除了记录和查看功能再无其他作用。
swagger号称世界最流行的接口文档服务器，界面美观，插件也还比较多，可以针对后端语言直接生成测试代码。不过部署的时候始终没玩懂，而且yaml格式不如json习惯，放弃了它。
这就是现在我们项目上用的文档服务器和mock服务器，基于MEAN技术实现的服务器，基本功能：
利用mockjs插件，可以动态生成随机数据基于json-schema对接口参数实行校验和接口测试，并保存测试状态和接口响应时间。简单的json编辑器带有登陆校验功能，可登陆后进行接口调试mock服务器按照api服务器来响应请求，接口更新时自动更新
node.js是前端工程师的翅膀，而插上翅膀是变成天使还是变成恶魔？这个要看能不能解决的使用它时带来的问题了。
首先前端的工作量毫无疑问地会增加，但沟通成本会降低。node.js单线程的服务器稳定性确实不够好，不过代码的健壮性和完善的日志可以有效的规避。回调。这个问题解决方法就太多了，node.js的q/async模块以及ES6/ES7。node.js调试。虽然我一直排斥IDE，但不得不承认webstorm在调试上确实很方便。我用的node-inspector也还凑合，界面类似chrome开发者工具，看上去挺熟悉的。
如果对于后端程序员，更加应该拥簇node.js了。接口整合的工作交给了前端服务器进行处理，同时和前端耦合度大大降低，工作量和工作效率都减少了。
心得体会有两点
node.js的使用虽然有一定的学习成本，但对于前端开发人员还是很友好的。而且前端使用node.js的话，无论是技术含量还是工作量都会有所提升，从而提升了岗位的重要性。当前端开发人员能创造更多价值的时候才有资格要求更高的薪水~工作中建议少提建议多给可行性方案，同时进行技术预研而不是写个简单的helloworld。
可能有人说你介绍的这一套东西这么复杂，用起来太麻烦了，还不如面对面沟通。&对于这样的质疑我只能用腾讯高级UI工程师余果在《web全栈工程师的自我修养》中讲到的一个例子。有一次他电面一家小公司的前端负责人问他怎么管理代码时，对方说直接用ftp上传，同时抱怨手下人老是更新错代码，又问他为什么不用svn或git，他说还不如手动更新方便。 这个故事的道理就是我面对质疑的回答~
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具中国领先的IT技术网站
51CTO旗下网站
系统架构：Web应用架构的新趋势 前后端分离的想法
Web前端现在是一个独立的技术工种，这个工种的产生主要是针对互联网行业的需求，我在以前的文章里曾经讲到过，一个大型互联网网站，例如想淘宝网，它绝对不是一个Web项目，而是一群web项目的集合，那么如果不在前端进行整合，这么多web项目前端开发一定存在大量重复劳动，并且运维时候也存在难以统一管理的问题。本文假想一个面对需要前端资源整合的组织，如何做到前后端分离的解决思路。
作者：夏天的森林来源：博客园| 17:40
最近研究servlet，看书时候书里讲到了c/s架构到b/s架构的演变，讲servlet的书都很老了，现在的b/s架构已经不是几年前的b/s架构，其实b/s架构就是web应用开发，对于这样的架构我们现在应该考虑的是前端和后端的分离（注意：这里的后端是指服务端）。
Web前端现在是一个独立的技术工种，这个工种的产生主要是针对互联网行业的需求，我在以前的文章里曾经讲到过，一个大型互联网网站，例如想淘宝网，它绝对不是一个Web项目，而是一群web项目的集合，那么如果不在前端进行整合，这么多web项目前端开发一定存在大量重复劳动，并且运维时候也存在难以统一管理的问题。本文假想一个面对需要前端资源整合的组织，如何做到前后端分离的解决思路。本文详情如下：
(一) 前后端分离的目的和作用
做Web开发也可以说是B/S架构开发，B端和S端从技术体系角度而言异构性很大，换而言之就是B端使用的技术和S端使用的技术不适于同一个体系，这样的结果导致实际开发中，很难做到专业分工，如果项目开发过程中管控不到位，这样的问题可能会影响到整个项目的开发质量，因此前后端分离的目的之一就是要做到专业化分工，提高项目的质量和开发效率。
随着技术的发展，当下的Web开发形势已经和以前有了很大的不同，早期的Web项目是一个封闭的项目，用户从浏览器里看到的页面直到后台数据库都是在一个项目里集成的，而现在Web系统的规模越来越大，中大型的Web系统是一个开放式的系统，开放型的系统用户在浏览器发起的请求可能会转发到外部的系统里进行处理，或者是本地的系统和外部系统一起完成请求的处理，此外有的请求可能不会直接请求数据库，而是请求缓存服务器，这些变化几乎都是发生在Web系统的服务端，前后端耦合度很高的Web系统服务端的复杂度提升必然带来了Web前端的复杂度的提升。因此Web前端从系统架构的角度也需要更加专业的管控，管控的作用之一就是前后端进行分离，降低前端对服务端的依耐性。
富客户端应用的普及导致Web前端技术开发更加专业化，Web前端工程师成为一个独立的技术岗位，Web前端开发技术的难度也越来越高，前后端的分离就是为Web前端开发营造一个良好的开发环境，不要让前端工程师被一些不可控的外在因素所影响（例如：前后端的耦合性），最后导致前端不能专心致志做出更加好的作品。所以，前后端分离是让前后端更加专业化，在技术和管理上将前端角色更加明确，更深入的挖掘前端开发的价值。
(二) 现有系统架构给前后端带来的问题以及解决方法
上图是目前大部分系统的架构图，虽然有些系统采用分布式架构，层与层之间使用了远程调用框架，但是本质上都逃不开上面这个架构设计。这张图是一张比较合理的图，在实际开发里最常发生的事情就是控制层（Control）越过服务层（Service）直接处理下面的资源。
前后端耦合的问题主要发生在控制层（Control），控制层是前端和服务端交互的边界，但是在开发过程中控制层（Control）和服务层（Service）常常混淆不清，这就是前后端耦合度高的重要原因。
因此要前后端解耦，就是要划清控制层的边界，控制层到底该属于前端还是服务端，在MVC模式里控制层作用是调度，控制层不是写业务逻辑的地方，因此将大量业务逻辑写到控制层其实是违背了MVC模式的思想，同时控制层是前端和服务端通讯的桥梁，其实控制层是参入了前端的工作任务，既然控制层要剥离业务操作同时控制层也要参入前端应用的开发，那么将控制层归为前端的一部分是完全合情合理合规的。
把控制层剥离了业务逻辑处理可能会让人不知道如何开发了，我觉得有这种想法的人是开发时候没有理解透MVC模式思想，编程随意性大养成了坏习惯，这个就需要这些人一点点去适应技术新趋势的发展。
前后端分离的终极目标应该是前端和服务端是完全独立的项目，前端项目包含上图里的浏览器和控制层，服务端项目包括服务层、DAO层等等，前端项目和服务端项目以高效的远程调用框架做通讯介质，项目开发时候前端项目做前端的事情，服务项目做服务端的事情，这样就让服务端开发的人员没有机会在控制层乱写代码了，保证了Web前端环境的纯粹性，最后生产发布也要独立部署，这样就达到了前后端真正解耦，但是前后端的沟通机制也是不可或缺的，我觉得它们之间的沟通使用高性能的远程调用框架，前后端相互约定通讯报文格式。.
其实不管服务端还是前端宏观流程无非是输入数据&数据处理&输出数据，但是服务端要把心思花在数据处理上，前端要更多关心的是输入输出数据时候的用户体验操作，服务端开发最大的问题就是违背MVC原则，代码编写的随意性，而前端不管出于安全还是性能考虑，最好是尽量少牵涉业务。前端和后端通讯层的独立，会将前后端进行真正的解耦，前面我讲到前后真正问题就是前端和后端技术路线不一致，但是传统Web开发里前后端又要融为一体，这就导致前后端很难做到专业化分工，对于前端应该尽量弱化通讯级别的开发工作，前端通讯编程只要知道调用哪个接口，传什么参数，怎么处理响应信息就行了。这样就能让前端和后端实现真正的专业化。
做到了这些，就不会发生开发时候前后端边界不清的问题了。
(三) 前后端分离的一些想法
本文主题应该是前后端分离，我上面的建议是个彻底方案，要革以前系统的命，对存量系统那该如何处理，答案还是重构代码，想方设法逐步减少已经发现的前后端耦合度高的问题，这个跟我之前的建议就是小重构和大重构的区别，如果有人觉得我上面建议合适，前端组应该马上提供一套这样的框架出来，这样后面的新系统就不会在循环前面的错误了。我觉得搭建这样的框架不会太复杂的。
我上面的前后端分离的目的就是将前端资源整合为一个整体，理清前后端的边界，这些做完后，前端组里该如何提升自己的能力了？
这时候要让前端的东西项目化，工程化，前端技术不能再当做开发者的玩具，它也是需要大量的系统架构，开发规范，自动化压缩混淆，自动化发布，前端监控和分析，前端优化等等。
上面这些问题都很重要，也很专业，如果我有机会能参入这样的事情，我还有个特别的建议，具体如下：
在一个企业内部，Web前端的组件，不管这个组件是UI层级，还是javascript开发层级，都脱离不了该企业业务产品的模式，其实看看像网易，新浪这样的门户网站的前端应用组件，它们用于做门户很合适，但是用它来做企业应用软件可能就不是太好使用，因此对于组件要有一个清晰的认识，我觉得可以把组件按业务场景分类，这里我可以举个例子，如果这个企业有给门户使用的组件，而这个组件很适合门户，应该把它归为门户组件，如果某些组件适合做网站后台管理的，那么就列为后台管理组件，如果某些组件能跨多了业务场景则标记为通用组件。
做分类的原因是为了理清组件的应用边界，这样我们可以有针对性的积累和完善这些组件，有意识的开发相关的组件，最终形成一个针对某个业务组件的组件仓库，这样等新需求过来，Web前端的项目经理或Web前端的技术经理可以通过场景分析该需求需要使用那些现有的技术，需求里的那些场景是要进行开发，新场景里有没有新开发的代码能生成新的组件，这就可以做到有计划有次序的积累。
Web前端的核心人员应该花更多精力去设计、积累、整理各种组件，通过实际业务需求去完善和丰富这些组件，最终达到组件可以覆盖到全公司绝大多数场景，最终通过组件积累形成完善的Web前端开发规范，这样的规范覆盖面广更加易于操作，对于企业而言Web前端开发流程就可以做到标准化，从而达到简单培训一些技术能力不高的开发人员就能完成相关的开发任务，同时也让Web前端核心人员也能很好的把控项目的质量和进度。
以上就是我的一些前后端分离的想法，它是一个很宏观的想法，没有太多技术实现细节，如果这个想法如果针对存量系统，的确是一个颠覆性的方案，如果Web前端允许一切重头来做，我个人觉得这还是很好的一个思路。前后端分离是Web前端专业化的万里长征第一步，如果这一步做好，前端就有一套专属自己的优质环境，那时候Web前端就会有更大的余力做更优秀的工作，这就是我的愿景。
当然我的构想也许并不太正确，如果有大牛看了本人文章还请多多指教。
原文链接：
【编辑推荐】
【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条外电外电头条
24H热文一周话题本月最赞
讲师：1人学习过
讲师：33人学习过
讲师：0人学习过
精选博文论坛热帖下载排行
本书第1版曾被KDnuggets的读者评选为最受欢迎的数据挖掘专著，是一本可读性极佳的教材。它从数据库角度全面系统地介绍了数据挖掘的基本概念...
订阅51CTO邮刊& & 前言& & 在做前后端分离时，第一个关注到的问题就是渲染，也就是View这个层面的工作。& & 在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的……
声明：该文章系网友上传分享，此内容仅代表网友个人经验或观点，不代表本网站立场和观点；若未进行原创声明，则表明该文章系转载自互联网；若该文章内容涉嫌侵权，请及时向
论文写作技巧
上一篇：下一篇：
相关经验教程