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

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

前后端分离的实现在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#/

thonatos

2014-11-26 01:13:43 +08:00

@exodia

看到神仙打架了么这是....（玩笑）

这里开帖子就是为了探讨这个问题，打广告神马的自然是很欢迎了，有更好的解决方案自然无需造轮子了，EFE与淘宝UED的使用场景不同应该是无可非议的了。

webapp方式的解决方案，是我一开始就在用的，甚至于现在还在用（目前还没开始试验淘宝的方式），SEO方面的问题，个人认为不应该是问题，可这个显然依然是问题，至少DU厂的搜索引擎，对Ajax站的支持貌似没Google那么友好（如果有错，还望指导下DU场针对Ajax站的SEO方法）

既然有心情学前端，自然不能仅仅停留在页面仔的范畴，精通另说，最起码要有涉猎，这样的学习成本，是值得付出的，编程语言服务需求，说到底，选择什么还是为了项目本身，在这之外，能让自己能力有所提升，也是一件很开心的事情~

中间层的方案，V的职能不可否认，C的职能或者可以更进一步抽出？
或者，也许我们可以试试MVC三者的进一步分离？

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--

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 最好的那个。。

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？

soulteary

2014-11-26 02:42:41 +08:00

@thonatos SEO的话，这个要分情况讨论的，一个是蜘蛛是否支持异步渲染；google有相关规范，百度未知；针对google可以直接提供接口数据，以供抓取索引；针对百度类型的蜘蛛，可以考虑针对UA或者IP做特殊模板输出，或者服务端代理入口转向特殊url...

特殊模板这里又有一个分支，是神马格式展示，xml/html/micro data/...而这些模板由谁处理...是否要做前后端模板共用，复用...

总之，这个事情应该根据自己业务具体情况具体讨论了...v2上吐槽再多都是空的= =

thonatos

2014-11-26 03:03:35 +08:00

@soulteary

就是担心针对UA做处理，会被关小黑屋……然后就从一个技术问题转变成一个蛋疼的商讨接洽过程（实现上问题不大），不过说到底，我是倾向于中间件的做法，SPA的模式，终究还是有些小坑的，局部使用MVVM更合理一些（主要针对普通的对外项目，不专门做处理，也是解放劳动力吧，T.T）

……碎觉碎觉，迟到了要扣工资滴，可怜的实习生有木有-_-||，明天搞个demo测试一下，看看效果啦，安喽

thonatos

2014-11-26 12:48:37 +08:00

@konakona

从长远来说，这样的改动是值得的，尤其是项目建设初期就这样做，更是容易实现。

1.改动期间如何迭代原有项目的维护工作
运行时期其实是多台服务器共存的，改动时期也是如此，那么是后端优先（如现在的php重构开始，完成基本功能，接口的开发），前端完成原有模板的升级（tp的模板，和现在的其实不冲突，可以直接拿来用.T.T,修改下模板输出的边界符即可无缝转换了）。

然后通过ip在入口（nginx）设置路由规则，局部更换到新的服务器，测试运行，测试完成后，全局切换过来就好了。

2.重现原有功能
这里想采用中间件的方案的时候，纳入了java和php两种，我们原有系统本身就是接口类型的，这里在未完全搞定之前，或者说之后，除了session这一块（主要是包含认证相关的部分），需要node完成，类似于业务逻辑，大可以还放在原有的tp上，待完成后再考虑迁移（tp移除认证，服务器集群做成内网，限制外网访问，明白什么意思吧？——好开放有木有。。。什么数据都可以随便拿。。。。T.T）

这是我得想法，有好的意见分享一下喽~