淘宝前后端分离实践资料

1、前后端分离的思考与实践(一)作者：常胤 | 时间： 2014-04-04 17:20也谈基于 NodeJS 的全栈式开发(基于 NodeJS 的前后端分离)前言为了解决传统 Web 开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了 “前后端 ”的定义，引入前端同学都熟悉的 NodeJS ，试图探索一条全新的 前后端分离模式。随着不同终端 (Pad/Mobile/PC) 的兴起， 对开发人员的要求越来越高， 纯浏览器端的响应式已经不能满足用户体验的 高要求，我们往往需要针对不同的终端开发定制的版本。为了提升开发效率，前后端分

2、离的需求越来越被重视，后 端负责业务 /数据接口，前端负责展现 /交互逻辑，同一份数据接口，我们可以定制开发多个版本。这个话题最近被讨论得比较多，阿里有些 BU 也在进行一些尝试。讨论了很久之后，我们团队决定探索一套基于 NodeJS 的前后端分离方案，过程中有一些不断变化的认识以及思考，记录在这里，也希望看到的同学参与讨论， 帮我们完善。一、什么是前后端分离？最开始组内讨论的过程中我发现， 每个人对前后端分离的理解不一样， 为了保证能在同一个频道讨论， 先就什么是 前后端分离 ”达成一致。大家一致认同的前后端分离的例子就是 SPA(Single-page application) ，所有用到

3、的展现数据都是后端通过异步接口 (AJAX/JSONP) 的方式提供的，前端只管展现。从某种意义上来说， SPA 确实做到了前后端分离，但这种方式存在两个问题：WEB 服务中， SPA 类占的比例很少。 很多场景下还有同步 /同步 +异步混合的模式， SPA 不能作为一种通用 的解决方案。现阶段的 SPA 开发模式，接口通常是按照展现逻辑来提供的，有时候为了提高效率，后端会帮我们处理一 些展现逻辑，这就意味着后端还是涉足了 View 层的工作，不是真正的前后端分离。SPA 式的前后端分离，是从物理层做区分(认为只要是客户端的就是前端，服务器端的就是后端)，这种分法已经 无法满足我们前后端分离的

4、需求，我们认为从职责上划分才能满足目前我们的使用场景：前端：负责 View 和 Controller 层。 后端：只负责 Model 层，业务处理 /数据等。为什么去做这种职责的划分，后面会继续探讨。二、为什么要前后端分离？关于这个问题，玉伯的文章 Web 研发模式演变 中解释得非常全面，我们再大概理一下：2.1 现有开发模式的适用场景玉伯提到的几种开发模式，各有各的适用场景，没有哪一种完全取代另外一种。比如后端为主的 MVC ，做一些同步展现的业务效率很高，但是遇到同步异步结合的页面，与后端开发沟通 起来就会比较麻烦。Ajax 为主 SPA 型开发模式，比较适合开发 APP 类型的场景，但是

5、只适合做 APP ，因为 SEO 等问题不好 解决，对于很多类型的系统，这种开发方式也过重。2.2 前后端职责不清在业务逻辑复杂的系统里，我们最怕维护前后端混杂在一起的代码，因为没有约束， M-V-C 每一层都可能出现别的 层的代码，日积月累，完全没有维护性可言。虽然前后端分离没办法完全解决这种问题，但是可以大大缓解。因为从物理层次上保证了你不可能这么做。2.3 开发效率问题淘宝的 Web 基本上都是基于 MVC 框架 webx ，架构决定了前端只能依赖后端。 所以我们的开发模式依然是，前端写好静态 demo ，后端翻译成 VM 模版，这种模式的问题就不说了，被吐槽了很 久。直接基于后端环境开

6、发也很痛苦， 配置安装使用都很麻烦。 为了解决这个问题， 我们发明了各种工具， 比如 VMarket ， 但是前端还是要写 VM ，而且依赖后端数据，效率依然不高。另外，后端也没法摆脱对展现的强关注，从而专心于业务逻辑层的开发。2.4 对前端发挥的局限性能优化如果只在前端做空间非常有限，于是我们经常需要后端合作才能碰撞出火花，但由于后端框架限制，我们 很难使用 Comet 、 Bigpipe 等技术方案来优化性能。为了解决以上提到的一些问题，我们进行了很多尝试，开发了各种工具，但始终没有太多起色，主要是因为我们只 能在后端给我们划分的那一小块空间去发挥。只有真正做到前后端分离，我们才能彻底解决

7、以上问题。、怎么做前后端分离？怎么做前后端分离，其实第一节中已经有了答案：前端：负责 View 和 Controller 层。 后端：负责 Model 层，业务处理 /数据等。试想一下，如果前端掌握了 Controller ，我们可以做 url design ，我们可以根据场景决定在服务端同步渲染，还是根 据 view 层数据输出 json 数据，我们还可以根据表现层需求很容易的做 Bigpipe,Comet,Socket 等等， 完全是需求决 定使用方式。3.1 基于 NodeJS“全栈 ”式开发如果想实现上图的分层，就必然需要一种 web 服务帮我们实现以前后端做的事情，于是就有了标题提到

8、的 “基于NodeJS 的全栈式开发 ”这张图看起来简单而且很好理解，但没尝试过，会有很多疑问。SPA 模式中，后端已供了所需的数据接口， view 前端已经可以控制，为什么要多加 NodeJS 这一层？ 多加一层，性能怎么样？多加一层，前端的工作量是不是增加了？ 多加一层就多一层风险，怎么破？NodeJS 什么都能做，为什么还要 JAVA ？ 这些问题要说清楚不容易，下面说下我的认识过程。3.2 为什么要增加一层 NodeJS ？现阶段我们主要以后端 MVC 的模式进行开发， 这种模式严重阻碍了前端开发效率， 也让后端不能专注于业务开发。 解决方案是让前端能控制 Controller 层，但

9、是如果在现有技术体系下很难做到，因为不可能让所有前端都学java ，安装后端的开发环境，写 VM 。NodeJS 就能很好的解决这个问题，我们无需学习一门新的语言，就能做到以前开发帮我们做的事情，一切都显得 那么自然。3.3 性能问题 分层就涉及每层之间的通讯，肯定会有一定的性能损耗。但是合理的分层能让职责清晰、也方便协作，会大大提高 开发效率。分层带来的损失，一定能在其他方面的收益弥补回来。 另外，一旦决定分层，我们可以通过优化通讯方式、通讯协议，尽可能把损耗降到最低。举个例子： 淘宝宝贝详情页静态化之后，还是有不少需要实时获取的信息，比如物流、促销等等，因为这些信息在不同业务系 统中，所以

10、需要前端发送 5， 6 个异步请求来回填这些内容。有了 NodeJS 之后，前端可以在 NodeJS 中去代理这 5 个异步请求，还能很容易的做 Bigpipe, 这块的优化能让整个 渲染效率提升很多。可能在 PC 上你觉得发 5,6 个异步请求也没什么，但是在无线端，在客户手机上建立一个 HTTP 请求开销很大，有 了这个优化，性能一下提升好几倍。淘宝详情基于 NodeJS 的优化我们正在进行中，上线之后我会分享一下优化的过程。3.4 前端的工作量是否增加了？相对于只切页面 /做 demo ，肯定是增加了一点，但是当前模式下有联调、沟通环节，这个过程非常花时间，也容易 出 bug ，还很难维

11、护。所以，虽然工作量会增加一点，但是总体开发效率会提升很多。 另外，测试成本可以节省很多。以前开发的接口都是针对表现层的，很难写测试用例。如果做了前后端分离，甚至 测试都可以分开，一拨人专门测试接口，一拨人专注测试UI（这部分工作甚至可以用工具代替）。3.5 增加 Node 层带来的风险怎么控制？随着 Node 大规模使用，系统 /运维 /安全部门的同学也一定会加入到基础建设中，他们会帮助我们去完善各个环节 可能出现的问题，保障系的稳定性。3.6 Node 什么都能做，为什么还要 JAVA ？我们的初衷是做前后端分离， 如果考虑这个问题就有点违背我们的初衷了。 即使用 Node 替代 Java

12、 ，我们也没办法 保证不出现今天遇到的种种问题， 比如职责不清。 我们的目的是分层开发， 专业的人， 专注做专业的事。 基于 JAVA 的基础架构已经非常强大而且稳定，而且更适合做现在架构的事情。四、淘宝基于 Node 的前后端分离上图是我理解的淘宝基于 Node 的前后端分离分层，以及 Node 的职责范围。简单解释下：最上端是服务端，就是我们常说的后端。后端对于我们来说，就是一个接口的集合，服务端提供各种各样 的接口供我们使用。因为有 Node 层，也不用局限是什么形式的服务。对于后端开发来说，他们只用关心业务 代码的接口实现。服务端下面是 Node 应用。Node 应用中有一层 Mode

13、l Proxy 与服务端进行通讯。这一层主要目前是抹平我们对不同接口的调用方式， 封装一些 view 层需要的 Model 。Node 层还能轻松实现原来 vmcommon,tms （引用淘宝内容管理系统）等需求。Node 层要使用什么框架由开发者自己决定。 不过推荐使用 express+xTemplate 的组合， xTemplate 能做到 前后端公用。怎么用 Node 大家自己决定，但是令人兴奋的是，我们终于可以使用 Node 轻松实现我们想要的输出方 式 :JSON/JSONP/RESTful/HTML/BigPipe/Comet/Socket/同步、异步，想怎么整就怎么整，完全根据你

14、的场景决定。浏览器层在我们这个架构中没有变化，也不希望因为引入 Node 改变你以前在浏览器中开发的认知。 引入 Node ，只是把本该就前端控制的部分交由前端掌控。这种模式我们已经有两个项目在开发中，虽然还没上线，但是无论是在开发效率，还是在性能优化方面，我们都已 经尝到了甜头。五、我们还需要要做什么？把 Node 的开发流程集成到淘宝现有的 SCM 流程中。 基础设施建设，比如 session,logger 等通用模块。 最佳开发实践 线上成功案例大家对 Node 前后端分离概念的认识 安全 性能技术上不会有太多需要去创新和研究的，已经有非常多现成的积累。其实关键是一些流程的打通和通用解决

15、方案的 积累，相信随着更多的项目实践，这块慢慢会变成一个稳定的流程。六、“中途岛 ”虽然 “基于 NodeJS 的全栈式开发 ”模式很让人兴奋，但是把基于 Node 的全栈开发变成一个稳定，让大家都能接受 的东西还有很多路要走，我们正在进行的 “中途岛 ”项目就是为了解决这个问题。虽然我们起步不久，但是离目标已 经越来越近！标签： midway 、NodeJS 、 前后端分离前后端分离的思考与实践(二)作者： Herman | 时间： 2014-04-10 20:19基于前后端分离的模版探索前言在做前后端分离时，第一个关注到的问题就是渲染 ，也就是 View 这个层面的工作。在传统的开发模式中

16、，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地 带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。而我们选择了 NodeJS ，作为一个前后端的中间层。试图藉由 NodeJS ，来疏理 View 层面的工作。使得前后端分工更明确，让专案更好维护，达成更好的用户体验。本文渲染这块工作，对于前端开发者的日常工作来说，佔了非常大的比例，也是最容易与后端开发纠结不清的地方。回首过去前端技术发展的这几年， View 这个层面的工作，经过了许多次的变革，像是：1. Form Submit 全页刷新 = AJAX 局部刷新2. 服务端续染 + MVC = 客户端

17、渲染 + MVC3. 传统换页跳转 = 单页面应用可以观察到在这几年，大家都倾向将 渲染 这件事，从服务器端端移向了浏览器端。而服务器端则专注于 服务化 ，提供数据接口。浏览器端渲染的好处浏览器端渲染的好处，我们都很清楚，像是1. 摆脱业务逻辑与呈现逻辑在 Java 模版引擎中的耦合与混乱。2. 针对多终端应用，更容易以接口化的形式。在浏览器端搭配不同的模版，呈现不同的应用。3. 页面呈现本来就不仅是 html ，在前端的渲染可以更轻易的以组件化形式(html + js + css) 提供功能，使得前端组件不需依赖于服务端产生的 html 结构。4. 脱离对于后端开发、发佈流程的依赖。5. 方

18、便联调。浏览器端渲染造成的坏处但是在享受好处的同时，我们同样的也面临了 浏览器端渲染 所带来的坏处，像是：2.1. 模版分离在不同的库。有的模版放在服务端 (JAVA) ，而有的放在浏览器端 (JS) 。前后端模版语言不相通。 需要等待所有模版与组件在浏览器端载入完成后才能开始渲染，无法即开即看。3.首次进入会有白屏等待渲染的时间，不利于用户体验4. 开发单页面应用时，前端 Route 与服务器端 Route 不匹配，处理起来很麻烦。5. 重要内容都在前端组装，不利于 SEO反思前后端的定义其实回头想想，在我们把渲染的工作从 后端职责划分，并不是非浏览器渲染不可服务端 (Java) 抽出来到

19、浏览器端 (JS) 的时候，我们的目的只是 明确的前。只是因为在传统的开发模式中，出了服务器就到了浏览器，所以前端的工作内容只能被限制在浏览器端。也因此很多人认定了 后端 = 服务端 前端 = 浏览器端 ，就像下面这张图。而在淘宝 UED 目前进行的 中途岛 Midway 项目中， 藉由在 JAVA Browser 中间搭建一个 NodeJS 中间层，试图 把这个前后端的分割线，重新针对 工作职责 去区分，而非针对硬体环境去区分(服务器 & 浏览器)。因此我们有机会做到模版与路由的共享，也是一个前后端分工中最理想的状态。淘宝中途岛 Midway在中途岛项目中，我们把前后端分界的那条线，从浏览器

20、端移回到了服务器端。藉由一个由前端 轻松掌控 且 与浏览器共通 的 Nodejs 层，可以更清晰的完成了前后端分离。也可以让前端开发针对不同的情况，自行决定 最适当的解决方案 。而不是所有事情 都在浏览器端来处理职责划分中途岛并不是前端试图抢后端饭碗的项目，目的只是把 模版 这个模糊地带切割清楚，取得更明确的职责划分。后端 (JAVA) ，专注于1. 服务层2. 数据格式、数据稳定3. 业务逻辑前端，专注于1. UI 层2. 控制逻辑、渲染逻辑3. 交互、用户体验 而不再拘泥于服务端或浏览器端的差异。模版共享在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两

21、者中间的模糊地 带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。有了 NodeJS ，后端同学可以在 JAVA 层专注于业务逻辑与数据的开发。而前端同学则专注于控制逻辑与渲染的开 发。并且自行选择这些模版是要在 服务端 (NodeJS) 或是 浏览器端 做渲染。用著一样的模版语言 XTemplate ，一样的渲染引擎 JavaScript在 不同的渲染环境 ( Server-side 、PC Browser 、 Mobile Browser 、Web View 、etc. ) 渲染出 一样的结果 。路由共享也因为有了 NodeJS 这一层，可以更细致的控制路由。假如需要在前端做浏览

22、器端路由时，可以同时配置服务器端的路由，使其在 浏览器端换页 或是 服务端换页 ，都可 以得到一致的渲染效果。同时也处理了 SEO 的问题。模版共享的实践通常我们在浏览器端渲染一份模版时，流程不外乎是1. 在浏览器端載入模版引擎 ( xtmpleate, juicer, handlerbar, etc. )2. 在浏览器端载入模版档案，方法可能有使用 . 印在页面上 使用模块载入工具，载入模版档案(KISSY, requireJS, etc. )其他3. 取得数据，使用模版引擎产生 html4. 将 html 插入到指定位置。致的模块选型 这件事。從以上的流程可以觀察到，要想要做到模版的跨端共

23、享，重点其实在市面上流行很多种模块标准，例如KMD 、AMD 、CommonJS ，只要能将 NodeJS 的模版档案透过一致模块规范输出到 NodeJS 端，就可以做基本的模版共享了。而后续的系列文章会针对 Model 的 proxy 与共享，做进一步的探讨。案例探讨因为有了中途岛这中间层，针对过往的一些问题都有了更好的解答，例如说案例一 复杂交互应用 （如购物车、下单页面）状况：全部的 HTML 都是在前端渲染完成，服务端仅提供接口。 问题：进入页面时，会有短暂白屏。解答：1. 首次进入页面，在 NodeJS 端进行 全页渲染，并在背景下载相关的模版。2. 后续交互操作，在浏览器端完成 局

24、部刷新3. 用的是 同一份模版 ， 产生 一样的结果案例二 单页面应用状况：使用 Client Side MVC 框架，在浏览器换页。 问题：渲染与换页都在浏览器端完成，直接输入网址进入或 f5 刷新时，无法直接呈现同样的内容。 解答：1. 在浏览器端与 NodeJS 端共享 同样的 Route 设定2. 浏览器端换页时，在浏览器端进行 Route 变更与 页面内容渲染3. 直接输入同样的网址时，在 NodeJS 端进行 页面框架 + 页面内容渲染4. 不管是浏览器端换页，或直接输入同样的网址，看到的内容都是 一样的 。5. 除了增加体验、减少逻辑複杂度外。更解决了 SEO 的问题案例三 纯浏

25、览型页面状况：页面仅提供资讯，较少或没有交互问题： html 在服务端产生， css 与 js 放在另外一个位置，彼此间有依赖。 解答：1. 透过 NodeJS ，统一管理 html + css + js2. 日后若需要扩展成复杂应用或是单页面应用，也可以轻易转移。案例四跨终端页面状况：同样的应用要在不同端点呈现不同的介面与交互问题： html 管理不易，常常会在服务端产生不一样的html ，浏览器端又要做不一样的处理解答：1.跨终端的页面是渲染的问题，统一由前端来处理。2. 透过 NodeJS 层与后端服务化，可以针对这类型复杂应用，设计最佳的解决方案。总结过去的 AJAX 、 Client

26、-side MVC 、 SPA 、 Two-way Data Binding 等技术的出现，都是试图要解决当时的前端开发 遇到的瓶颈。而 NodeJS 中间层的出现，也是在试图解决现今前端被侷限在浏览器端的一个限制。这边文章专注于前后端模版共享，也希望能抛砖引玉，与大家一起讨论如何在 NodeJS 中间层这个架构下，我们可 以怎样的改善我们的工作流程，怎样的跟 后端 配合，来把 前端 这个工作做得更好。前后端分离的思考与实践（三）作者：善繁 | 时间： 2014-04-13 20:01Midway-ModelProxy架轻量级的接口配置建模框前言使用 Node 做前后端分离的开发模式带来了一些

27、性能及开发流程上的优势（见前后端分离的思考与实践一 ）, 但同时也面临不少挑战。在淘宝复杂的业务及技术架构下，后端必须依赖 Java 搭建基础架构，同时提供相关业务接 口供前端使用。 Node 在整个环境中最重要的工作之一就是代理这些业务接口，以方便前端 （Node 端和浏览器端 ）整 合数据做页面渲染。如何做好代理工作，使得前后端开发分离之后，仍然可以在流程上无缝衔接，是我们需要考虑 的问题。本文将就该问题做相关探讨，并提出解决方案。由于 后端提供的接口方式可能多种多样， 同时开发人员在编写 Node 端代码访问这些接口的方式也有可能多种多 样。如果我们在接口访问方式及使用上不做统一架构处理

28、，则会带来以下一些问题：1. 每一个开发人员使用各自的代码风格编写接口访问代码，造成工程目录及编码风格混乱，维护相对困难。2. 每一个开发人员编写自己的 mock 数据方式，开发完毕之后，需要手工修改代码移除 mock 。3. 每一个开发人员为了实现接口的不同环境切换（日常，预发，线上 ），可能各自维护了一些配置文件。4. 数据接口调用方式无法被各个业务 model 非常方便地复用。5. 对于数据接口的描述约定散落在代码的各个角落，有可能跟后端人员约定的接口文档不一致。6. 整个项目分离开发之后，对于接口的联调或者测试回归成本依然很高，需要涉及到每一个接口提供者和使用者。 于是我们希望有这样一

29、个框架，通过该框架提供的机制去描述工程项目中依赖的所有外部接口，对他们进行统一管 理，同时提供灵活的接口建模及调用方式， 并且提供便捷的线上环境和生产环境切换方法， 使前后端开发无缝结合。 ModelProxy 就是满足这样要求的轻量级框架，它是 Midway Framework 核心构件之一，也可以单独使用。使用 ModelProxy 可以带来如下优点：1. 不同的开发者对于接口访问代码编写方式统一，含义清晰，降低维护难度。2. 框架内部采用工厂 + 单例模式， 实现接口一次配置多次复用。 并且开发者可以随意定制组装自己的业务Model（ 依赖注入 ）。3. 可以非常方便地实现线上，日常，预

30、发环境的切换。4. 内置 river-mock 和 mockjs 等 mock 引擎，提供 mock 数据非常方便。5. 使用接口配置文件，对接口的依赖描述做统一的管理，避免散落在各个代码之中。6. 支持浏览器端共享 Model ，浏览器端可以使用它做前端数据渲染。整个代理过程对浏览器透明。7. 接口配置文件本身是结构化的描述文档，可以使用 river 工具集合，自动生成文档。也可使用它做相关自动化接 口测试，使整个开发过程形成一个闭环。ModelProxy 工作原理图及相关开发过程图览在上图中，开发者首先需要将工程项目中所有依赖的后端接口描述，按照指定的 json 格式，写入 interfa

31、ce.json 配 置文件。必要时，需要对每个接口编写一个规则文件，也即图中interface rules 部分。该规则文件用于在开发阶段mock 数据或者在联调阶段使用 River 工具集去验证接口。规则文件的内容取决于采用哪一种 mock 引擎（比如 mockjs, river-mock 等等）。配置完成之后，即可在代码中按照自己的需求创建自己的业务model 。下面是一个简单的例子：【例一】第一步 在工程目录中创建接口配置文件 interface.json, 并在其中添加主搜接口 json 定义title: pad 淘宝项目数据接口集合定义 ,version: 1.0.0,engine:

32、 mockjs,rulebase: ./interfaceRules/,status: online,interfaces: name: 主搜索接口 ,id: Search.getItems,urls: online: 第二步 在代码中创建并使用 model/ 引入模块var ModelProxy = require( modelproxy );/ 全局初始化引入接口配置文件 (注意：初始化工作有且只有一次)ModelProxy.init( ./interface.json );/ 创建 model 更多创建模式请参后文var searchModel = new ModelProxy( sea

33、rchItems: Search.getItems / 自定义方法名 : 配置文件中的定义的接口 ID );/ 使用 model, 注意 : 调用方法所需要的参数即为实际接口所需要的参数。searchModel.searchItems( q: iphone6 )/ ! 注意 必须调用 done 方法指定回调函数，来取得上面异步调用 searchItems 获得的数据 !.done( function( data ) console.log( data );.error( function( err ) console.log( err ); );ModelProxy 的功能丰富性在于它支持各种

34、形式的 profile 以创建需要业务 model ：使用接口 ID 创建生成的对象会取 ID 最后号.后面的单词作为方法名 ModelProxy.create( Search.getItem );使用键值 JSON 对象 自定义方法名 : 接口 IDModelProxy.create( getName: Session.getUserName,getMyCarts: Cart.getCarts );使用数组形式 取最后 . 号后面的单词作为方法名 下例中生成的方法调用名依次为 : Cart_getItem, getItem, suggest, getName ModelProxy.creat

35、e( Cart.getItem, Search.getItem, Search.suggest, Session.User.getName );前缀形式 所有满足前缀的接口 ID 会被引入对象，并取其后半部分作为方法名 ModelProxy.create( Search.* );同时，使用这些 Model ，你可以很轻易地实现合并请求或者依赖请求，并做相关模板渲染 【例二】 合并请求var model = new ModelProxy( Search.* );/ 合并请求 ( 下面调用的 model 方法除 done 之外，皆为配置接口 id 时指定 ) model.suggest( q: 女

36、 ).list( keyword: iphone6 ).getNav( key: 流行服装 ).done( function( data1, data2, data3 ) / 参数顺序与方法调用顺序一致console.log( data1, data2, data3 ); );【例三】 依赖请求var model = new ModelProxy( getUser: Session.getUser,getMyOrderList: Order.getOrder );/ 先获得用户 id ，然后再根据 id 号获得订单列表model.getUser( sid: fdkaldjfgsakls0322

37、yf8 ).done( function( data ) var uid = data.uid;/ 二次数据请求依赖第一次取得的 id 号this.getMyOrderList( id: uid ).done( function( data ) console.log( data ); ); );此外 ModelProxy 不仅在 Node 端可以使用，也可以在浏览器端使用。只需要在页面中引入官方包提供的 modelproxy-client.js 即可。【例四】浏览器端使用 ModelProxyKISSY.use( modelproxy, function( S, ModelProxy ) /

38、 !配置基础路径，该路径与第二步中配置的拦截路径一致 !/ 且全局配置有且只有一次！ModelProxy.configBase( /model/ );/ 创建 modelvar searchModel = ModelProxy.create( Search.* );searchModel.list( q: ihpone6 ).list( q: 冲锋衣 ).suggest( q: i ).getNav( q: 滑板 ).done( function( data1, data2, data3, data4 ) console.log( list_ihpone6: data1,list_冲锋衣 :

39、data2,suggest_i: data3,getNav_ 滑板 : data4 ); ); );同时， ModelProxy 可以配合 Midway 另一核心组件 Midway-XTPL 一起使用， 实现数据和模板以及相关渲染过程在 浏览器端和服务器端的全共享。关于 ModelProxy 的详细教程及文档请移步 总结ModelProxy 以一种配置化的轻量级框架存在，提供友好的接口 model 组装及使用方式，同时很好的解决前后端开 发模式分离中的接口使用规范问题。在整个项目开发过程中，接口始终只需要定义描述一次，前端开发人员即可引 用，同时使用 River 工具自动生成文档，形成与后端开

40、发人员的契约，并做相关自动化测试，极大地优化了整个软 件工程开发过程。注】 River 是阿里集团研发的前后端统一接口规范及相关工具集合的统称前后端分离的思考与实践(四)作者： lorrylockie | 时间： 2014-05-09 17:42前后端分离模式下的安全解决方案前言在前后端分离的开发模式中， 从开发的角色和职能上来讲， 一个最明显的变化就是： 以往传统中，只负责浏览器环境中开发的前端同学，需要涉猎到服务端层面，编写 服务端代码。而摆在面前的一个基础性问题就是如何保障 Web 安全？ 本文就在前后端分离模式的架构下，针对前端在 Web 开发中，所遇到的安全问题以及应对措施和注意事项

41、，并提 出解决方案。跨站脚本攻击 (XSS) 的防御问题及解决思路跨站脚本攻击( XSS ， Cross-site scripting )是最常见和基本的攻击 Web 网站的方法。攻击者可以在网页上发布包 含攻击性代码的数据，当浏览者看到此网页时，特定的脚本就会以浏览者用户的身份和权限来执行。通过 XSS 可 以比较容易地修改用户数据、窃取用户信息以及造成其它类型的攻击，例如： CSRF 攻击。预防 XSS 攻击的基本方法是： 确保任何被输出到 HTML 页面中的数据以 HTML 的方式进行转义 (HTML escape )。 例如下面的模板代码：1. $description这段代码中的 $

42、description 为模板的变量(不同模板中定义的变量语法不同，这里只是示意一下)，由用户提 交的数据，那么攻击者可以输入一段包含 ”JavaScript 的”代码，使得上述模板语句的结果变成如下的结果：1. 2. alert(hello)3. 上述代码，在浏览器中渲染，将会执行 JavaScript 代码并在屏幕上 alert hello 。当然这个代码是无害的，但攻击者 完全可以创建一个 JavaScript 来修改用户资料或者窃取 cookie 数据。解决方法很简单，就是将 $description 的值进行 html escape ，转义后的输出代码如下1. 2. </tex

43、tarea><script>alert("hello!")</script>3.以上经过转义后的 HTML 代码是没有任何危害的。Midway 的解决方案转义页面中所有用户输出的数据对数据进行转义有以下几种情况和方法：1. 使用模板内部提供的机制进行转义中途岛内部使用 KISSY xtemplate 作为模板语言。在 xtemplate 实现中，语法上使用两个中括号( val )解析模板数据， ，默认既是对数据进行 HTML 转义 的，所以开发者可以这样写模板：1. description在 xtemplate 中，如果不希望输出的数据被转义，需

44、要使用三个中括号( val )。2. 在 Midway 中明确的调用转义函数开发者可以在 Node.js 程序或者模板中， 直接调用 Midway 提供的 HTML 转义方法， 显示的对数据进行转义， 如下：方法 1 ：在 Node.js 程序中对数据进行 HTML 转义1. var Security= require(midway-security);2. /data from server， eg html:，other:3. data.html =Security.escapeHtml(data.html);4. xtpl = xtpl.render(data);方法 2 ：在模板中对

45、HTML 数据进行 HTML 转义1. Security.escapeHtml(description)注意： 只有当模板内部没有对数据进行转义的时候才使用Security.escapeHtml 进行转义。 否则， 模板内部和程序会两次转义叠加，导致不符合预期的输出。推荐：如果使用 xtemplate ，建议直接使用模板内置的 进行转义； 如果使用其他模板，建议使用 Security.escapeHtml 进行转义。过滤页面中用户输出的富文本你可能会想到： “其实我就是想输出富文本，比如一些留言板、论坛给用户提供一些简单的字体大小、颜色、背景等 功能，那么我该如何处理这样的富文本来防止 XSS

46、 呢？ ”1. 使用 Midway 中 Security 提供的 richText 函数Midway 中提供了 richText 方法，专门用来过滤富文本，防止 XSS 、钓鱼、 cookie 窃取等漏洞。有一个留言板，模板代码可能如下：1. 2. message3. 因为 message 是用户的输入数据，其留言板的内容，包含了富文本信息，所以这里在 xtemplate 中，使用了三个 大括号，默认不进行 HTML 转义；那么用户输入的数据假如如下：1. 我在留言中 上述的富文本数据如果直接输出到页面中，必然会导致 站点的 js 注入到当前页面中，造成了 XSS 攻击。为了防止这个漏洞，我们

47、只要在模板或者程序中，调用Security.richText 方法，处理用户输入的富文本。调用方法与 escapeHtml 类似，有如下两种方式方法 1: 直接在 Node.js 程序中调用1. message =Security.richText(message);2. var html = xtpl.render(message)方法 2 ： 在模板中调用1. 2. Security.richText(message)3. 通过调用 Security 的 richText 方法后，最终的输出如下：1. 2. 我在留言中 3. 可以看出，首先：会造成 XSS 攻击的 script 标签被直接

48、过滤掉； 同时 style 标签中 CSS 属性 position:fixed; 样式也被过滤了。最终输出了 无害 的 HTML 富文本了解其他可能导致 XSS 攻击的途径除了在页面的模板中可能存在 XSS 攻击之外，在 Web 应用中还有其他几个途径也可能会有风险。1. 出错页面的漏洞一个页面如果找不到，系统可能会报一个404 Not Found 的错误，例如： http:/localhost/page/not/found1. 404 NotFound2. Page /page/not/found does not exsit 很显然：攻击者可以利用这个页面，构造一个类似这样的连接， htt

49、p:/localhost/%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E ，并引诱受害 者点击 ；假如出错页面未对输出变量进行转义的话，那么连接中隐藏的 alert(hello) 将会被执行。在 express 中，发送一个 404 页面的方法如下1.res.send(404 ， Sorry ，we dont find that!)这里就需要开发者注意错误页面 实更准确的讲，是用户输入信息(404 或者其他错误状态 )的处理方式。如果错误信息的返回内容带有路径信息(其 ) ，就一定要进行 escapeHtml 了。后续，错误处理的安全机制，会

50、在Midway 框架层面中完成。Midway 解决方案的补充说明其他模板引擎Midway 默认支持 xtemplate 模板，但将来也有可能支持其他模板：如jade 、 mustache 、 ejs 等。目前在主流模板中，都提供了默认转义和不转义的输出变量写法，需要开发者特别留意其安全性。关于 escape 的其他支持 除了对页面中输出的普通数据和富文本数据，一些场景中也还包含其他可能需要转义的情况， Midway 提供了如下 几个常用的转义方法，供开发者使用：escapeHtml 过滤指定的 HTML 中的字符，防 XSS 漏洞jsEncode 对输入的 String 进行 JavaScri

51、pt 转义 对中文进行 unicode 转义，单引号，双引号转义 escapeJson 不破坏 JSON 结构的 escape 函数，只对 json 结构中 name 和 vaule 做 escapeHtml 处理 escapeJsonForJsVar 可以理解就是 jsEncode+escapeJson例子如下1. var jsonText =:;2. console.log(SecurityUtil.escapeJson(jsonText);/ <script>:<script>3.4. var jsonText =你好 :;5. console.log(Secur

52、ityUtil.escapeJsonForJsVar(jsonText);/u4f60u59 7d:<script>6.7. var str =alert(你好 );8. console.log(SecurityUtil.jsEncode(str);/ alert(u4f60u597d)跨站请求伪造攻击 (CSRF) 的预防问题及解决思路名词解释： 表单：泛指浏览器端用于客户端提交数据的形式；包括a标签、 ajax 提交数据、 form 表单提交数据等，而非对等于 HTML 中的 form 标签。跨站请求伪造( CSRF ， Cross-site request forgery )

53、是另一种常见的攻击。攻击者通过各种方法伪造一个请求，模 仿用户提交表单的行为，从而达到修改用户的数据或执行特定任务的目的。为了假冒用户的身份， CSRF 攻击常常和 XSS 攻击配合起来做，但也可以通过其它手段：例如诱使用户点击一个 包含攻击的链接。解决 CSRF 攻击的思路分如下两个步骤1. 增加攻击的难度。 GET 请求是很容易创建的，用户点击一个链接就可以发起 GET 类型的请求，而 POST 请求相对比较难， 攻击者往往需要借助 JavaScript 才能实现；因此，确保 form 表单或者服务端接口只接受 POST 类型的提交请求，可以增加系统的安全性。2. 对请求进行认证，确保该请求确实是用户本人填写表单或者发起请求并提交的，而不是第三者伪造的。 一个正常用户修改网站信息的过程如下用户请求修改信息 (1) - 网站显示用户修改信息的表单 (2) - 用户修改信息并提交 (3) - 网站接受用户修 改的数据并保存 (4)而一个