这是一个创建于 3688 天前的主题，其中的信息可能已经有所发展或是发生改变。
看过了“淘宝前后端分离实践”后，考虑在公司内部进行试验，更多的还是借鉴。
前后端分离的实现在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#/
前后端分离的实现在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#/
第 1 条附言 · 2014-11-25 22:12:10 +08:00
1.关于通信效率
用node做前端的一部分，MODEL（这里应该是伪Model了，毕竟他只是通过http之类的方式）与后端（如java的逻辑、运算服务器）的通讯效率问题。
@lygmqkl 讲了他们的实践，基本是相同的，也略有增加，但是同等的收益是在后面的，所以这个效率问题，放在整个项目的生命周期里的话，是缩短的，所以这部分，我认为效率增加了。
2.关于前后端定义
有人对于这里存在不同的理解，其实之前就说过了，这里是对也许进行了分离，将MVC中的VC部分纳入前段，M部分交过后端，也许你不认可，但是这种的分离，给了前端更大的自由度，也让后端能够更专注于业务本身，而非交互逻辑。
我们内部一致认为，所谓前端，是指一切与用户/客户端的交互相关的部分。
3.关于职责明确
前后端分离的源动力在于系统的分离，使得团队人员的职责明确，过去后端参与太多交互相关的内容，对他们来说，其实是在浪费他们的时间和精力，例如tp中（$this->display('index')）这样的东西，每次你一改动就让他们改，不觉得eggTeng？（别说什么模板之类的，同样的功能，我们有N种实现方法，我们只是在找一种更好的，更合理的对吧~）
4.关于使用与否
生命在于折腾，不是为了技术而技术，技术是在改善。
这样的讨论的目的是根据具体应用场景来定的，比如我需要一个庞大的数据运算模块，这里我也许可以用C来实现，如果为了语言统一，大可以将C写成node的组件，可当我们面对的时十台百台服务器，但并非每一台都要做运算，有必要每一台都要一个这样的node组件么？
成员职责的划分，项目模块的划分，是源动力吧~
用node做前端的一部分，MODEL（这里应该是伪Model了，毕竟他只是通过http之类的方式）与后端（如java的逻辑、运算服务器）的通讯效率问题。
@lygmqkl 讲了他们的实践，基本是相同的，也略有增加，但是同等的收益是在后面的，所以这个效率问题，放在整个项目的生命周期里的话，是缩短的，所以这部分，我认为效率增加了。
2.关于前后端定义
有人对于这里存在不同的理解，其实之前就说过了，这里是对也许进行了分离，将MVC中的VC部分纳入前段，M部分交过后端，也许你不认可，但是这种的分离，给了前端更大的自由度，也让后端能够更专注于业务本身，而非交互逻辑。
我们内部一致认为，所谓前端，是指一切与用户/客户端的交互相关的部分。
3.关于职责明确
前后端分离的源动力在于系统的分离，使得团队人员的职责明确，过去后端参与太多交互相关的内容，对他们来说，其实是在浪费他们的时间和精力，例如tp中（$this->display('index')）这样的东西，每次你一改动就让他们改，不觉得eggTeng？（别说什么模板之类的，同样的功能，我们有N种实现方法，我们只是在找一种更好的，更合理的对吧~）
4.关于使用与否
生命在于折腾，不是为了技术而技术，技术是在改善。
这样的讨论的目的是根据具体应用场景来定的，比如我需要一个庞大的数据运算模块，这里我也许可以用C来实现，如果为了语言统一，大可以将C写成node的组件，可当我们面对的时十台百台服务器，但并非每一台都要做运算，有必要每一台都要一个这样的node组件么？
成员职责的划分，项目模块的划分，是源动力吧~
 |
1
tomwan 2014-11-25 11:27:03 +08:00  1
没那么大规模的话，这样搞是在折腾
|
 |
2
ZackYang 2014-11-25 11:36:08 +08:00
折腾...让我想起我个人网站都是前后端分离...
主站zackyang.com在github page 服务端api.zackyang.com在AWS EC2 nginx反向代理的node上 正准备把照片使用的img.zackyang.com放到七牛去 |
 |
4
thonatos OP @ZackYang
放在github上的主战显然是静态站喽，然后呢， 你的这种是较为类似ng的方式（也就是ajax方式）直接请求服务端数据的， 这样的分离，很大程度上是受限于自身网络情况了。 采用顶楼的图二的方式，数据请求是放在内网或者同一服务器，数据请求的速度显然是要更高一点的吧？ 那么，问题来了： 直接展示的内容显然是通过node来render了，ajax的内容....又是受限于网络了...（eggTeng！） ..只是讨论，畅所欲言喽~ |
 |
5
liangdi 2014-11-25 12:12:16 +08:00
我们现在也是在尝试
前端完全的静态资源,通过ajax（ng） 请求数据 后端只提供api接口（包括后台管理模块也是 独立的静态前端） |
 |
6
juicy 2014-11-25 12:28:41 +08:00
@liangdi 我们公司采用这种形式快三年了，这几年最大的感受就是，前端工作量巨大，很多时候后端的一些工作都转嫁给前端。我想说这是一项造福后端的伟大创想，恩！
|
|
7
liangdi 2014-11-25 12:31:48 +08:00 via Android
@juicy 哈哈。你说的对。前端工作量变大了。但是相比以前。需要和后端或者自己处理 和后端有些打交道的view。这种方式变得更灵活了。目前我们正在往这方面重构。如遇到问题。到时候可以向你请教了
|
 |
8
caixiexin 2014-11-25 12:35:16 +08:00
手头项目已经这么干了1年，项目用java做后端，提供rest接口，Html5+css+js前端，也有php单纯做前端。说说体会：
好处就是前后端分工明确，专注自己的模块，干活效率高。单元测试，优化什么的都能分开做 ps：我已经1年没写过view了。。 缺点也很明显：当人手不足时，忽然把后端人员调到前端，完全没办法动手（当初看到backbone和bootstrap结合的前端时，差点跪了）。。反之亦然。 |
|
9
caixiexin 2014-11-25 12:39:32 +08:00
@juicy 我也觉得前端工作多了。。不过后来想想，其实是我们做后端的只考虑功能实现，偷懒不去优化接口，做详细的单元测试才这样（我经常接口写完没怎么测就丢给前端用，用出了问题再改，这样其实很不好= =）。后端要做的事其实也很多，不过用户很多反馈都是从前端得出的，所以当后端功能做完后，很少会碰到需求变更或优化。
|
|
10
thonatos OP |
 |
11
Arrowing 2014-11-25 12:42:18 +08:00
我也用这种方式做了一年
我是做前端的 前端的工作量要 X 2 不过分工确实挺明确的，后端开发API就好了。 |
|
14
liangdi 2014-11-25 12:46:43 +08:00 via Android
@thonatos 使用angular等mvvm的框架，很容易实现你想要的东西。上手后 前端开发还是比较爽的。依赖，以及模块化都可以搞
|
|
16
thonatos OP @caixiexin
不知道你们对于ng的看法，但是我非常喜欢ng的实现方式，但是ng对SEO不够友好。 现在要用这样的方式的话， 将ng的controller重新拉回到nodejs， 将ng的数据绑定回归到nodejs的模板引擎，当然，不是完全的替代； 有些地方，还是会采用mvvm模式或者数据双向绑定的方法来实现，毕竟可以降低劳动量。 我们过去的模式职责不够明确，前端对后端的依赖过大（我是指非类SPA项目），现在这样，重新定义前后端的职责和权限，前端的自由度是增加了的，可控制性也更大了；后端，也能更多的关心业务逻辑，这样更好一些吧。 |
|
20
thonatos OP |
|
21
liangdi 2014-11-25 12:54:28 +08:00 via Android
前后端分离的另外一个好处是当你要增加app客户端的时候就很轻松了
|
|
22
thonatos OP |
|
24
juicy 2014-11-25 13:05:28 +08:00
作为一个reactjs拥护者，SEO毫无压力！
|
 |
25
yakczh 2014-11-25 13:11:54 +08:00
如果是post提交有事务的操作呢,比如支付什么的
|
 |
26
learnshare 2014-11-25 13:19:51 +08:00
把之前的 CS 模式延续到 BS 上，都是重前轻后的方式，客户端/前端多一些工作量，但后端简单不少
|
 |
27
blue7wings 2014-11-25 13:47:41 +08:00
想过这个问题，想把ThinkPHP替换为Laravel。有没有这方面的书，或例子？跪求ＬＺ推荐下，想深入的学习瞎。。。
|
 |
28
yun77op 2014-11-25 14:41:38 +08:00
我们这边有个工具可以把freemarker模板结合伪数据生产html，并不需要跑整个工程（特别是前期后端都没准备好的情况下），这里就要求前端要熟悉后端的view。
|
 |
29
fundon 2014-11-25 14:44:10 +08:00
|
 |
30
dong3580 2014-11-25 14:48:13 +08:00
正如我正在做的项目：
前端 ajax 前端完全的Html5+css+js 后端 MVC 生成json的api 前后端完全分离，分别部署，安卓/水果端 也用这个api，公用一套Api，如果以后改语言，也行，前端无需变动，手机端也不需要变动，只需要重新做后端。 如果以后数据量大了卡了，只需要优化后端即可。 |
|
31
thonatos OP @yakczh
关于post什么的，其实并不影响业务系统，模块的分类并没将业务分离出去，所以，还是原来的操作。 @learnshare 嗯，平衡，更合理的职责划分，不过对前端的要求略有增加，但问题应该不大，只是VC两部分嘛 @yun77op 嗯嗯，我考虑下我们这里要不要这样做哦~ @fundon 谢谢~ |
|
32
thonatos OP @dong3580
是的，我们这么想这样做的根本目的也是为了以后不会相互影响，当业务量增大的时候，完全可以用负载均衡服务器将请求转发过去，当然，还是要做一些优化处理；最想用的地方在于，后端的服务器如果是集群了，那么语言就不限制了，甚至于说，未来根据需要，后端集群根据业务使用完全不同的语言也是可行的。 |
|
33
thonatos OP @blue7wings
其实换什么不用紧，要这么做就是为了解决后端语言的问题，使得各种语言的使用不影响前端的统一，换言之，前端只需要做一次，后端随便你怎么换，我只要知道接口就行了，其他的，前端不用再去关心了~ |
 |
34
chx007 2014-11-25 15:28:56 +08:00
我们之前的前后端分离，模板渲染全部在前端完成，后端提供RESTful接口让前端用XHR来加载。这会导致`空白首屏`等待问题。
为解决这个问题，我们现在尝试在前后端之间加一个以node开发的中间层，用来渲染首屏输出，而后续的界面上数据刷新，还是由前端XHR后端数据后在浏览中进行模板渲染输出。这里面有个问题是首屏输出与后续界面上数据刷新，在代码逻辑上其实是一致的。所以就设想尽可能让每个功能组件在Node和浏览器端都能运行。找来找去还是觉得React更适合做这样的事情，而跟后端RESTful打交道，可以用superagent，因为它将XHR和node上的http.ClientRequest封装成统一的接口。 |
|
35
learnshare 2014-11-25 16:09:25 +08:00
@chx007 首页白屏的问题，加一个 loading 动画就好了...
或者首屏的资源尽量压缩减少，最好首屏的资源 HTML/JS/CSS 各有一个，HTML 资源附加一些内容进去。当然，大规模的应用资源加载量不容易控制。 昨天看到朵唯新机的页面，200 多张图，18M 多资源，加载了三分半。 |
 |
36
lygmqkl 2014-11-25 16:53:30 +08:00
其实前后端分离设计的关键在于架构，并不在代码层面上， 国内的伪RESTful 架构太多，如果有一个牛B的架构师，团队最少可以减肥30%，想想少了30%的人员和沟通，开发效率要多高？ 成本要节约多少？
但是很不幸国内架构师好像不是那么热。 PS: 最近在给一个知名xx做一套架构，用的就是RESTful 的api，我都是采用非常简单的逻辑，但是目前来看，代码实现的难度 和 大家开发的效率都得到了有效的保证，当然运行效率也是很高的，毕竟RESTful 天生的statelessness 就已经足够优秀了。 |
 |
37
tojoevan 2014-11-25 16:59:33 +08:00
不错哦，支持哦
|
|
39
thonatos OP |
 |
40
boom11235 2014-11-25 17:59:15 +08:00
我聊聊我的想法：（仅作为一个小小前端工程师）
1）不应该因为技术而技术，采用某种技术方案一定是在它可以帮助你解决一些需求的前提下，看清楚前后端分离给现有团队带来的好处和麻烦是很重要的。 2）作为前端工程师来说，node层的加入，提高了自由度，可以更多方面地handle交互相关的东西，但是需要知识层次需要比原有的前端知识更深入到http，网络等。 3）实践的方式，会因实际业务和团队而千差万别，SPA如果适合业务和团队的话个人感觉是较好的实践，前端承载的相对会少也会舒服一些。其次，选择中间node的一层，那么前端需要承载起后端开发的一些东西，或者需要node工程师（如果是web，实际上我不支持node工程师，而是更加优秀的前端，除非是专业性的一些东西，如游戏后端引擎等，因为node工程师即加多了一层，沟通成本，人员成本都大了），现有的node已经可以较好支撑起这一块了。再其次，工具，我认为前后端分离更多着重在职责分离，以及降低沟通成本，提高独立开发可行性，虚拟后端mock以及服务的工具，可以让前后端都独立开发，沟通好交叉部分的数据结构即可，同时也方便做相关测试。 |
|
43
thonatos OP @boom11235
非常赞同你的看法，职责的分离以及前端自由度的提升是试验的动力之一（二），同时我也不认为让前端熟悉一部分后端的内容是压力，相反，更该是能力的提升，所谓全栈的说法不是很认同，做前端，又同时能对其他内容有所涉猎的能更好的发挥自己的价值，仅仅做demo，很好，但不是最好。 |
|
44
thonatos OP @ZackYang
进入白屏这个问题，是我太偏激（见谅），这个，准确来说，应该是无解的……（试着将网速限制到足够低，必然还是会出现），即使采用Bigpipe的方式，也依然是不能解决的，这个话题略过吧，sorry |
|
45
lygmqkl 2014-11-25 19:19:57 +08:00
@thonatos 不知道你说的通讯效率是什么？ 我用的是php脚本来搭建后台，一次请求包含所有的信息，对应服务器返回需要的json 数据，不觉得效率上会有什么问题啊
PS: 服务器组成是 6台 web + 2 db |
|
46
thonatos OP |
|
47
lygmqkl 2014-11-25 20:07:15 +08:00
@thonatos 耗时 如果条件相同的情况下，应该是不相上下，甚至可能会多损耗5%在传输上，因为对比传统的session结构，request header里要包含的东西显然多了很多，但是这个损耗还回来的是，你可以同时有10台web服务器响应，100个用户的请求，每台服务器处理10个，而且随机选择服务器就可以，因为每一台服务器对相同的request header 返回是一样的。
稳定性应该是提升了的，当然是在请求量巨大的场景下。 请特别注意，在RESTful架构下，缓存更多的是做在客户端，即js代码里，一旦缓存了，请求都不会发送，只要设计的足够好，还是很强悍的。 |
 |
48
otakustay 2014-11-25 20:54:44 +08:00
1. 阿里的前后端分离有它特殊的时代背景，比如前端想要的接口和后端想提供的对不上之类的
2. 你的第2张图里的后端是啥语言，如果不是NodeJS的话，左边那个NodeJS也没必要吧，和后端语言保持一致不是挺好的吗？这个NodeJS放在这的意义是啥 3. NodeJS不能算在前端里吧，这里的分界线很不明确？ |
 |
49
hitsmaxft 2014-11-25 21:04:17 +08:00
前后端分离的最大驱动力是团队拆分.. 这不是笑话. 业务团队和ued团队不在一个队伍里, 带来的协作问题不是一点两点能讲完的..
前后端分离倒不是最核心的目的, 而是要分清楚 模型, 业务, 和模板的开发归属. 真正原因, 是在现有的协作分工模式下, 最大限度地解放生产力... |
 |
50
crossmaya 2014-11-25 21:16:38 +08:00
我不知道你这个php和java在这里做什么用，分离不就是统一业务系统吗，后端nginx已经把事情做完了，你这php和java在这里的意思是提供动态内容输出？还是只作为一个入口。。
|
|
52
thonatos OP @otakustay
1.应用分具体场景而定，阿里的模式也不全是因为“对不上”吧 2.这里主张的前后端分离，换言之是重新定义了前后端的范畴，和传统的前端定义有区别，显然也就需要其他来做后端了，语言一致只是相对而言，并非全部一致，比如多台服务器的时候，你也许能理解这样的好处。 3.仔细看图2，你应该大体能理解这里——前后端的概念。 @crossmaya 你不知道的原因在于你对这里所说的前后端理解上的偏差，前端不只是页面（css/html/js），前端应该是与用户交互的部分，换言之，ios/android的客户端（app），也可以理解为前端；后端是指逻辑和业务系统，比如说进行数据运算，比如说是持续的数据处理什么的。 仔细看图，应该能明白我这里的java和php只是泛指，也可以是c，也可以是go，或者python等等，他是指的整个项目的一个部分，显然动态内容的输出了，内容的输出交给nodejs来做的，可以是静态，也可以是动态，甚至说，可以是cdn。 |
|
53
thonatos OP @hitsmaxft
嗯，团队合作的时候，分离的确很便利，比如说我当前的开发往往需要后端支持： 我们后端使用了redis，而我本地是不具有redis的，另外一些具体的配置，也不可能完全复制到本地，每次测试，往往需要我push，后端pull，测试反馈bug，重复上述步骤，很麻烦。 如果分离了，那么我负责页面（包含controller，view），model那边利用接口，可以轻松的实现现有的模式，只要后端保证model层的稳定即可，当然了，有人可能会说我们可以修改现在的模式，让我本地可以访问redis之类的，但那终归不是最好的解决方法，对吧？ 扩展下，我的本地环境，其实就是充当了负载均衡控制的web服务器之一（web服务器是多台，例如5），同时业务服务器有2台，那么，web是独立的，他可以自主部署自主测试，业务那么不需要重复做”无用功“了。 这样才是真正的解放生产力么(⊙_⊙)？，前端学点简单的VC算什么难度~~~~对吧~ |
 |
54
maxiujun 2014-11-25 22:09:41 +08:00 via iPad
我在一家专门提供外汇交易平台解决方案的公司，最近一年都在用ember.js做类似的工作，效果不错，我觉得对于页面上复杂逻辑的实现，ember,angular 帮助非常大。同时后台用spring mvc 的rest借口也同样有我一个人完成，这样就可以平衡前和后端了。
|
|
55
thonatos OP @maxiujun
嗯嗯，一个人做的话...确实是完全自主发挥了，我的主管大人直接发话了： “统计哪里，就当你的试验田，随便你怎么搞~” 这样的分离也没有要完全放弃ember，angular的说法了，主要是如我附言那边写到的原因喽~ |
|
56
maxiujun 2014-11-25 22:23:49 +08:00 via iPad
其实关键的问题就是前端和后端的界限在哪里，我们这的界限就在java的接口上，所以我们这么做也就好理解了。
另外，做了这么多实践，感觉，只要把前端的工具链（Grunt,bower 等）弄熟练，主题里面提到的“分离”就水到渠成了。 |
|
57
thonatos OP @maxiujun
讨论再多，也只是为了提高生产力嘛~ 最后做的东西即使一样多，但是中间环节的减少，在团队协作中，确实是巨大的提升。 （对于个人开发者来说...基本可以认为是一样的，至少过去我做东西，从来都不会考虑这个.） 前端和后端的界限，我认为是职能，或者说职责，减少无用功，这样定下的界限，更好一些。 |
 |
58
exodia 2014-11-25 23:24:58 +08:00 3
好无聊，过来练习下写作和表达能力。
首先，我觉得不要扯性能方面的问题，性能对于绝大多数非首页场景都不会是瓶颈。真要追求极致性能，就像淘宝首页一样，写成静态 html好了。 解决前后端分离的问题，目前大概有以下几种方案： 1. 前端写后端模板 1）前端和后端的模板是不一致的，比如前端可能用 Hanldebars，后端 java 经常用velocity，php 用 smarty，都由前端一起维护。比较恶心的问题在于，公司大了，部门多了，业务线多起来了，可能技术选型都不一样，比如有的业务线用 php，有的用 java，还有的用 python，他们的模板引擎可能都不一致，一是碎片语言实在太多了，更严重的是阻碍组件的复用，比如淘宝的通用吊顶和吊尾以及登录框是可以全站复用的，但之前用 java 写的，如果有的业务线用 php 咋办？于是他们对这些组件进行前端组件的静态化处理，即这些组件变成了 html+css+js的片段给其他业务线去用，数据请求通过 ajax 去做；但这些组件的一个特点是，依赖后端的动态数据较少，比如吊顶只是简单的一个登录信息请求即可，不适合需要大规模的后端查询页面。 因为1）的问题，于是有了下面的 2） 2.1） 前后端统一模板，模板语言嘛，用不同的语言都写个引擎就好了嘛，比如后端 nodejs 用 jade，咱前端也用 jade，嫌慢，咱先编译好。这个我还没找到比较大型的案例，我自己做着玩玩的时候用过。 2.2）有人觉得每个语言都要为一个模板语法写一个引擎，维护成本也大，模板语法一更新，所有引擎都要更新，真是去你大爷的- -！ 于是呢，linkedin的做法是前后端统一模板为dust（你猜对了，js的模板引擎）, 后端在渲染模板的阶段，起个线程跑v8引擎，去做模板渲染。于是成功解决了web组件（前后端都有）复用的问题。 1方案的普及需要有好用的工具提供给前端做开发调试mock等，比如淘宝曾经出了个 vmarket，据说难用所以没然后了。然后，fis 也有针对这个专门做了工具，具体去 fis 主页看好了，最近我在试用他的 java 解决方案，感觉还是比较容易上手的。 2. 前端 mvc（webapp） 感觉不用太多介绍吧，这几年比较火的架构，模板在浏览器渲染（尼玛，你说后端返回渲染好的 html 字符串，艹，这还能叫前后端分离- -！！！！）。 很多人这个方案问题在于seo 和性能。就 seo 来说不是太大问题，比如我从组里同学那获知的用个 phantomjs 渲染出页面丢给 robot 就好了，以及 google 是有针对 ajax 页面做索引的。 再说说性能，linkein 不用前端 mvc 的一个很重要原因就是性能，不过人家是因为页面要兼容到 ie7，ie7没有原生的 JSON 提供，解析起来确实是巨慢无比，所以放弃了。我觉得吧，如果你的项目仅需要支持ie9+等现代浏览器，基本可以考虑采用这个方案试试，当然 seo 这块我也没涉及到，不好扯淡，有朋友去试了可以教教我~ 2方案对前端的要求会比1更高些，大规模项目的路由设置，模块切分，mvc 的职责，代码规范，目录结构的组织，都需要有一定功底，否则会玩脱。 这个玩法比较多，框架也很多，angularjs，ext，然后是我们这的一系列组合： https://github.com/ecomfe/er https://github.com/ecomfe/esui https://github.com/ecomfe/oo https://github.com/ecomfe/uioc 打广告就是爽，呵呵呵呵。 3. 加一层中间层 比较火的，淘宝中途岛，比较低调的， fis 的 yogurt。 线上案例，百度音乐移动版，淘宝的对外项目不是太清楚，麻烦知道的同学告知下，内部项目主要是之前的数据平台部门的一些产品:在云端等。 我曾经是这个方案的拥护者，在经历了北京velocity大会的 fis 和淘宝的前后端分离实践分享，前不久d2的支付宝前后端分离实践分享，以及最近自己在搞一个业务线前后端分离的实践后，我现在成为这个方案的反对者。至少我觉得这个方案不适合大多数场景。 我们看看这个方案想要解决的问题： 1) 前端依赖服务端开发环境 2）在服务端View层高度耦合 3）沟通成本高 4）职责不清晰 对于1），可以通过开发优秀的工具去解决，至少 fis 的 jello 还不错。 对于2），不明白这耦合在哪里？ 对于3），阿里的场景是前端写html Demo，再丢给后端套，敢问有几个公司这样做？ 对于4），我觉得和2）一样，说的太虚了。你要说职责清晰，学学腾讯把 html css 也分出去得了 - -。。 关于 ppt 中说前端 mvc的问题，限于篇幅和精力，我懒得吐槽- -！，@otakustay 可以来试试- -！ 再看看这个方案会遇到的问题： 1）学习成本实质是最高的。 天真的以为仅仅是语言没有学习成本？ 后端的各种技术，安全，日志，监控，并发，事务，分布式 session，数据库读写分离，确定一般的前端能搞定？阿里经历了多少年，java 发展了多少年才成就了现有这么成熟的体系。 bat 或许能用 nodejs 去玩玩，因为技术的服务化和平台化比较成熟，都会提供服务化的api来用， 比如分布式的 session 访问，你只需要去调接口，不用自己去用 nodejs 实现一套了，再说用户信息，订单信息也是提供接口给你，至于他们怎么做性能调优，安全处理，数据库设计你都不用管。 但是一般的公司能做到这么高度的服务化么？ 2）现阶段绝大多数前端水平还跟不上 即便很多前端号称自己会 node，也只是停留在写工具层面。 在 velocity 上，淘宝的分享者（p7）说，他们请了后端的同学帮他们实现 nodejs 的 session 读取框架，我就跪了好嘛，整个淘宝 ued 都找不出一个前端能写这个，你确定有几个前端有这个技术能力去 hold 这种技术？ 在阿里也就那些数据平台部的人在这方面比较牛逼了，但是别人一直都是以后端为主，前端为顺手写，起点和一般前端完全不同，现在最多就是挂个前端的 title 在上面。 3）想要解决的问题都可以有更快捷简单的方式去解决 对大多数场景来说，我更推荐1的解决方案，简单快捷，没有太多成本。比较成熟的公司想要做组件化的复用可以参考 linkedin 的方案。 中间层可能只是一个舍近求远的方案。 最后，中间层这个方案给我感觉最多会成为一个，由 nodejs 渲染的模板引擎方案。 当然，我个人倒是蛮希望这个方案能够将前端的总体水平提高一个档次，能够将前端工程师变为工程师。 |
 |
59
HaEx 2014-11-26 00:20:24 +08:00
@exodia 就事实而言，最后的描述的三个问题中，有一个里面没一句话是对的，当然我也不知道您是从哪里打听到的；至于其它的，就不吐槽了...
|
|
60
exodia 2014-11-26 00:29:19 +08:00
@HaEx 我比较喜欢直接吐槽，这样我可以认识到我的问题，至于你说最后的三个问题，有一个不对，那么我猜你说的是第二个，这个我没有打听，因为这个是我在 velocity 上直接问的清羽，是他说的，至于他说的是不是事实，我只是转发。 数据平台部门在 node 牛逼，这句话我确信没啥问题，当然，可能现在没这个部门了就是，呵呵
|
|
61
thonatos OP @exodia
看到神仙打架了么这是....（玩笑） 这里开帖子就是为了探讨这个问题，打广告神马的自然是很欢迎了，有更好的解决方案自然无需造轮子了，EFE与淘宝UED的使用场景不同应该是无可非议的了。 webapp方式的解决方案，是我一开始就在用的，甚至于现在还在用（目前还没开始试验淘宝的方式），SEO方面的问题，个人认为不应该是问题，可这个显然依然是问题，至少DU厂的搜索引擎，对Ajax站的支持貌似没Google那么友好（如果有错，还望指导下DU场针对Ajax站的SEO方法） 既然有心情学前端，自然不能仅仅停留在页面仔的范畴，精通另说，最起码要有涉猎，这样的学习成本，是值得付出的，编程语言服务需求，说到底，选择什么还是为了项目本身，在这之外，能让自己能力有所提升，也是一件很开心的事情~ 中间层的方案，V的职能不可否认，C的职能或者可以更进一步抽出？ 或者，也许我们可以试试MVC三者的进一步分离？ |
 |
62
soulteary 2014-11-26 01:24:37 +08:00
@exodia 这几个问题如果想知道答案，不如发简历来，如果ok，我们还能对半分入职的奖励，2333
如果不发简历的话，那就无责任吐槽加回复一些我所知道无伤大雅的东西吧。 有的业务和实现还是蛮复杂的（历史原因，发展原因，各种其他原因），即使接口化程度好一点，如果你也有做的话，应该明白这点，session这个我刚刚顺手看了一眼代码，似乎苏千大神12年就写了，不过14年又更新了一部分，或许我们说的不是一个事吧... 如果抛开公司业务，我觉得不管是用redis/mysql还是写文件方式来写一个node版本的session rest接口也不用多久，何况团队里好多技术碾压我的前辈... 弱弱吐个槽，朴神很强力吧，但是职级是P6，诶，是不是说明层级不能完全作为你的论点的数据参考了呢..（朴神，我不是故意黑你的...） 第二段同意部分语句，作为团队拖后腿的渣渣从来没敢说自己会node，或许是团队大神封装中间件略赞，或许是小伙伴强力，不管是安全过滤/路由定义/日志调试/数据代理(尤其)都是用的爽的不要不要的，自己专注业务逻辑就可以了，或许你会觉得业务模型简单，但是其实承载的内容真的不少，还有巨量的流量每天帮你跑各种分支（233）... 总之，很多事情不能用简单一概而论，自从用了中间件，大概出活更快了（即使需求和要做的事情更多了），和后面数据接口那边的童鞋只需要约定数据格式就行了（其实还可以更狠点，直接捞数据，不过这样就不是各司其职了），有的时候做事情，互相旺旺贴下接口定义，大家就心照了，多愉快。 对了，好像还有说性能来着，只能说双十一毫无压力，等着看双十二性能图表中~ 比起三天两头开个会，各种约定，最后接口变了，前端模板逻辑甚至业务逻辑要重写代价小的多吧，即使数据源那边变了，我们的改动也不过是nodejs接口层修修改改，做做测试就完事了，不过这样也有个坏处，就是可能前端比后端完成事情的时间点早太多，去投入别的事情了，过段时间要返回来和后端联调（同时其他事情来了，会爽的不要不要的...） 以上，感觉自己title只是前端，连工程师都不是的渣渣吐槽完毕。 --EOF-- |
|
63
thonatos OP |
|
64
exodia 2014-11-26 01:48:42 +08:00
@thonatos seo这块，百度做的确实不够好，该黑的还是要黑，就事论事，解决方案文中提到过一个，针对 robot 使用 phantomjs 渲染页面丢过去，我没试过，但理论看着可行，所以我也希望有人尝试一下论证。 另外，也没啥打架不打架，我只是想明白中途岛方案和其他方案相比，到底优势在哪？仅仅是想探讨技术而已，请尽可能的，也尽情的在技术上扇我耳光。。。。所以如果有支持中途岛的同学，我仅仅是想和你们交流下技术方案而已，不要想太多了。
@soulteary 既然你们是中途岛的拥护者，不好好的推广，说说你们的方案对比其他方案的优势，掩着藏着是为何？ 既然你们提倡这种模式，又出来做分享，解决别人的困惑，说服别人用你们的东西应该是很乐意才对。 关于你说朴灵强不强，我先放着。。。。我也不是要从层级去论能力，但很多时候，层级确实是和能力挂钩。 你说的什么中间件用起来爽，完全没有去回答我提出的疑问，java 不能有中间件？相信阿里的 java 中间件用起来更爽。 再说你的约定数据格式的问题，前端写后端模板，后端一样可以做到只准备数据。难道其他前后端分离方案就不能愉快了？ 说性能，你觉得双十一性能稳定是因为你们用了 node？。。。 最后你的接口变了的问题，其他方案的改动会比你的改动代价大？没记错的话，你们是 java 和 node 在同一台机器部署，如果 node 要重新部署了，java 会需要一起部署不？ 你说到了苏千，我和你观点一致，他确实是大牛，但是，他确实是搞后端的啊，呵呵，当然现在转到支付宝做个挂个前端 title，做架构的事嘛。包括大部分好用的 node 中间件，你能给我说说这些作者有几个是前端出身？ 而阿里一开始就搞前端的，有几个写出了好用的中间件？ 另外，我也是经历了写 html demo，到写前端 mvc，再到现在体验前端维护后端模板的方案，才会有了此次的回帖。我想要的方案很明显是ROI 最好的那个。。 |
|
65
soulteary 2014-11-26 02:19:11 +08:00
@exodia v2没有打呵欠的emoji很是忧伤。
1.不应该把每个人都看成方案的推销者，我只是愉快使用的用户而已，（这个们字哪来的，别是突然又给我扣个帽子，让我去代表其他人吧，我只能代表自己，以用户身份，233333...） 2.掩藏？哪里来的神理解，来吐个槽而已，本来就没计划说服谁，神马很乐意是你按照自己的情况推理出来的么...另外，业务数据邮件是三令五申提醒过的，如果你不懂的话，请参考自己公司的商业规范和保密协议，如果没有的话，那么这位老板请无视我的这条回复。 3.帖子里说能力层级相关的，和技术方案选型又没啥关系，各种因素混合在一起的结果，纠缠起来没啥营养滴...2333 4.中间件多了去了，不知道为啥前端来个解放生产力的工具就大惊小怪的...你觉得啥爽用啥就好，不用告诉我... 5.你动力和愿景这么大，把简历发来，咱俩对半分奖励不是挺好的么...（该解释的之前吐槽不是说了么，自己不看背景乱嚷嚷，有意思么，你觉得有意思，我也没辙..） 6.性能，好吧，我严谨点，我接触的业务毫无压力...童鞋你神经别蹦的这么紧，太困就睡觉吧... 7.你还真是替这个方案操心，你猜猜？ 8.po主分享的ppt的作者不就是纯fe么，不过你纠结大家是做什么的有啥意义，这个争论点可以带来技术的提升还是帮助你快速完成需求？ps：自己cat node_modules/package.json看作者不行么...233 --- @thonatos 下次D2？ |
|
66
thonatos OP |
|
67
thonatos OP |
|
68
soulteary 2014-11-26 02:42:41 +08:00
@thonatos SEO的话，这个要分情况讨论的，一个是蜘蛛是否支持异步渲染；google有相关规范，百度未知；针对google可以直接提供接口数据，以供抓取索引；针对百度类型的蜘蛛，可以考虑针对UA或者IP做特殊模板输出，或者服务端代理入口转向特殊url...
特殊模板这里又有一个分支，是神马格式展示，xml/html/micro data/...而这些模板由谁处理...是否要做前后端模板共用，复用... 总之，这个事情应该根据自己业务具体情况具体讨论了...v2上吐槽再多都是空的= = |
|
69
thonatos OP @soulteary
就是担心针对UA做处理，会被关小黑屋……然后就从一个技术问题转变成一个蛋疼的商讨接洽过程（实现上问题不大），不过说到底，我是倾向于中间件的做法，SPA的模式，终究还是有些小坑的，局部使用MVVM更合理一些（主要针对普通的对外项目，不专门做处理，也是解放劳动力吧，T.T） ……碎觉碎觉，迟到了要扣工资滴，可怜的实习生有木有-_-||，明天搞个demo测试一下，看看效果啦，安喽 |
 |
70
konakona 2014-11-26 05:10:10 +08:00
我觉得这样的架构设计有点意思。
不过你们之前的项目是PHP开发，以ThinkPHP为框架。 现在要改为Nodejs，是不是未免变动太大？这样改动期间如何迭代原有项目的维护工作？如何合理重现原有功能结构等等？ |
|
71
exodia 2014-11-26 09:06:15 +08:00
@soulteary 能解决我的疑问才是真的，逃避技术点疑问，没有重点的回答也没啥必要继续了。我目前对淘宝ued一点兴趣都没，不用啥简历简历的，要解决问题，和要不要去ued 那一点关系都没；我从那出来1年多，在现在这个地方无比爽，就这样，，
|
 |
72
clino 2014-11-26 09:13:53 +08:00
自从用avalonjs以后,已经自然而然这么做了,后端基本上只用提供api,其实这样感觉挺棒的,就是需要用对搜索引擎友好的时候还是用后端模板吧
|
|
74
hitsmaxft 2014-11-26 10:15:02 +08:00
在淘宝/百度下就不是谈技术问题了, 而是怎么推动百人/千人团队的技术更迭和方案更新了, 而且产品都是千万到亿级别的访问量.
这时候只有技术因素是不够的. 所以不知道上面的有啥好吵的. |
 |
75
mengzhuo 2014-11-26 10:51:36 +08:00 via iPhone
也有为了手机客户端和页面共用一套API而进行前后端分离的
|
|
76
soulteary 2014-11-26 11:09:20 +08:00
|
 |
77
NearTan 2014-11-26 12:43:51 +08:00
学校项目，也是前后端分离，然后前端跟不上，苦恼中
|
|
78
thonatos OP @konakona
从长远来说，这样的改动是值得的，尤其是项目建设初期就这样做，更是容易实现。 1.改动期间如何迭代原有项目的维护工作 运行时期其实是多台服务器共存的，改动时期也是如此，那么是后端优先（如现在的php重构开始，完成基本功能，接口的开发），前端完成原有模板的升级（tp的模板，和现在的其实不冲突，可以直接拿来用.T.T,修改下模板输出的边界符即可无缝转换了）。 然后通过ip在入口（nginx）设置路由规则，局部更换到新的服务器，测试运行，测试完成后，全局切换过来就好了。 2.重现原有功能 这里想采用中间件的方案的时候，纳入了java和php两种，我们原有系统本身就是接口类型的，这里在未完全搞定之前，或者说之后，除了session这一块（主要是包含认证相关的部分），需要node完成，类似于业务逻辑，大可以还放在原有的tp上，待完成后再考虑迁移（tp移除认证，服务器集群做成内网，限制外网访问，明白什么意思吧？——好开放有木有。。。什么数据都可以随便拿。。。。T.T） 这是我得想法，有好的意见分享一下喽~ |
 |
79
yolio2003 2014-11-26 18:47:33 +08:00
看完发现结论是：没人分离的聊前后端，哈哈哈
|
 |
83
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和带宽方面的要求。 |
|
84
thonatos OP @JamesRuan
时间也不早了，略困，-_-|| 最近睡眠严重不足，老板看到了请自觉涨工资啊！ （╮(╯▽╰)╭，要真看到估计要扣……） 如果只是讨论分离，最简单省事的估计也就MVVM的方式了，不过，技术啊方案什么的，最终还是要服务于实际项目。 目前已经测试的是中间件的方式，大概一小时之前测试了一下从阿里云拿数据，效果还不错（打错字母那件事……先不讨论了，-_-||）。 时间上几乎没什么区别，毕竟还是类似的方法，不过是从浏览器转到nodejs。 类似职能分离这话就不吧啦吧啦废话了。 现实点的情况是这样，从前接口未变，后端没帮忙部署，我这里很轻松的完成了页面到测试数据到真实数据的全过程，各种参数随意打，想要什么要什么，不要太自由有木有？ -_-||，眼镜睁不开了，先睡了，目测要猝死，哎，享年22，大学未毕业，卒。 |
 |
85
HerrDu 2016-03-24 08:49:31 +08:00
最近也在考虑前后端分离的问题，也看了淘宝的中途岛的思路。还是想问一下，把 python 代替 node 做中间层是不是也能达到同样的效果？
还有就是 调用 restful 接口的时候，是怎么解决跨域问题的？ 用的是 httpclient 吗？ |
Select Language