再来讨论前后端分离的实践。

看过了“淘宝前后端分离实践”后，考虑在公司内部进行试验，更多的还是借鉴。

前后端分离的实现在SPA（Single-Page App）中应用较为广泛，如AngularJS，React 使用Ajax技术与后端通过RESTFul方式进行数据的请求与发送，

如我们的数据统计就是通过ng（AngularJS）的SPA项目，但它并不适用于我们主要项目（如SEO体验较差）。

考虑到之前曾讨论的未来可能会换到JAVA的后端服务的可能性，重新看了一遍淘宝UED的”淘宝前后端分离的思考与实践“的文章，下面两张图是我对他们结构的理解。

一）结构

1.经典的结构

2.前后端分离的结构

二）优势

1.后端实现业务逻辑和数据的查询计算，独立部署后端服务。（例如后端服务部署在8080端口）

2.前端路由，MVC，实现相对于后端的独立，自主控制视图层。（同样实现独立部署如部署在80端口）
# 这里的Model如上图所示，是与8080端口的后端进行交互

3.通过Server（Nginx模块）判断客户端请求类型，自助引导至不同的模块，仅需要一次判断，后续无需重复判断。

4.前端通过步骤3的预处理，可以在页面渲染前对例如css/images/js资源进行压缩处理，如置换渲染所需资源到所需的CDN（如icon/icon-mobile/icon@1x/icon@2x）

5.传统的SPA通常由于资源的处理时间问题（网络环境影响），在完成前可能出现”空白页“（等待阶段），这里可以参考BigPipe方式，持续输出。
# 虽然可以通过一些手段实现渲染完成前的一些预处理，但采用这里说到的方法，实现上更加优雅。

6.相对于传统，这样的分离更加明确各自的职责，后端职责更加明确，前端自由度更高，耦合度却有所降低。

三)疑问

看到知乎上关于这个问题的讨论，大体上阿里系的后端意见都挺大的样子，于此同时，很多人也在说增加了前后端的压力，尤其是要发展出一批nodejs工程师神马的；不过中肯的看法是要根据具体的情况来定，个人感觉在小型系统上，这样的模式是有优势的，实践起来也不是很困难，尤其是对内部的系统而言，问题不大，但是想到未来可能会放到对外的项目上，就产生很多疑问了，各位怎么看？

——————————（我是牛逼的分割线。）
参考：淘宝UED
地址： http://2014.jsconf.cn/slides/herman-taobaoweb/index.html#/

JamesRuan

2014-11-27 21:22:43 +08:00

说一下我们这边的想法。

首先，这是一个学校项目，而且目前还找不到足够有能力+有兴趣的小伙伴来完成，基本上就我和另一大牛YY中。

传统些，而且成熟些的分离方式是前端写后端模板，后端填数据，浏览器还是取页面。这种方式对一个比较成熟的团队来说更加问题，改造代价小；而优势也是显而易见的。

激进些，就是前端完成渲染，后端传数据，而模板和渲染代码都是静态的，由Web服务器搞定，大量的缓存可以推向前端。这样需要前后端之间定一个API。后端实现这个API，前端使用这个API。这样进一步带来了灵活性：后端可以是不同的平台，很容易扩展到多服务器；前端也可以是多平台。我们的应用有考虑到移动端的支持，默认还是开发一个适配移动端显示的HTML，但是由于API开放，相信以后会有其他的小伙伴有兴趣完成移动端的原生App。

然而这一激进的方案也有比较大的问题：目前API设计（我的主要工作）就是难点，由于业务逻辑有些复杂，单纯使用REST会使得有些业务需要多个API调用才能完成，从而产生原子性问题，需要引入状态，这又与REST的stateless设计冲突。另外，渲染代码和业务逻辑代码都由前端完成，使得前端的要求过高，学生中恐怕会难以找到hold的住的人（现在就是找不到人的状态啊！）

所以，有了第三套方案，即基于node或类似比较“轻”的技术来实现中间层，中间层负责业务逻辑，把多个RESTful的内部API调用转换成单一API的外部API调用，从而减轻传统前端的压力。这样，前中后端分别负责交互、业务、数据，缓存更加推向前端，缓存级别增加，同时系统解耦增加，代码逻辑更加清晰，维护性增加，扩展性大大增强。

但是，这第三套方案需要有两套API，精确定义两套API的转换方式（等于手写一遍业务逻辑），且可能设计过于复杂，具体实现时的编码、调试工作都会增加，我们本来就没几个人，怕是折腾不起这样一个系统。

另外，由于是学校内部项目，没有SEO和带宽方面的要求。

thonatos

2014-11-28 02:59:46 +08:00

@JamesRuan

时间也不早了，略困，-_-||
最近睡眠严重不足，老板看到了请自觉涨工资啊！
（╮(╯▽╰)╭，要真看到估计要扣……）

如果只是讨论分离，最简单省事的估计也就MVVM的方式了，不过，技术啊方案什么的，最终还是要服务于实际项目。

目前已经测试的是中间件的方式，大概一小时之前测试了一下从阿里云拿数据，效果还不错（打错字母那件事……先不讨论了，-_-||）。

时间上几乎没什么区别，毕竟还是类似的方法，不过是从浏览器转到nodejs。

类似职能分离这话就不吧啦吧啦废话了。

现实点的情况是这样，从前接口未变，后端没帮忙部署，我这里很轻松的完成了页面到测试数据到真实数据的全过程，各种参数随意打，想要什么要什么，不要太自由有木有？

-_-||，眼镜睁不开了，先睡了，目测要猝死，哎，享年22，大学未毕业，卒。