小剧所在的团队最近开设了对外博客，计划分享我们在 Odeon Bigdata 上的一些经验积累，也会有大数据相关的技术领域的一些见解。如果你对大数据感兴趣的话，欢迎关注我们。
这篇文章总结了下小剧自加入团队以来在前端上的一些尝试。
很幸运于今年加入科大讯飞，加入卧虎藏龙的大数据研究院。负责Odeon大数据平台前端方向的探索和研发工作。
在此之前，Odeon上线已有一年多，其间版本更新频繁。很难想象在仅有大数据开发和服务端同学的情况下，能将平台前端部分维护的相当稳定。而且还在不断快速推出新功能，确实很不容易。
接手的Odeon是什么样？
Odeon背后有着很多大数据相关的组件，以及复杂的集群部署方案。这些对于我来说是完全陌生业务方向，虽然不在我的研发范围内，但也在逐步做学习了解。
对于前端来说，最重要的当然是Odeon的WEB侧。在最早大数据项目立项时，根据当时所处的环境，很明智的采用了hue作为WEB选型。
作为一个同时集成了前端界面、后端功能以及成熟的部署方案的框架，hue为早期的项目的快速推进起到了至关重要的作用。在不足三个月时间内就完成Odeon的第一个版本的上线。
项目演进一年后，经过数次功能累加的Odeon已经逐渐在WEB侧表现出一些不足，主要有以下几点。
- 1、hue框架对前端部分的优化做的不够，未处理静态资源的模块化、打包、压缩等
- 2、前端基础框架采取的是较为老旧的knockout进行开发，虽然在前端MVC中资历很老但已略显疲态
- 3、前端组件有较多冗余，存在不少功能相似的重复性组件
- 4、前端逻辑与后端代码相互胶着，排查问题难度大，可维护性较差
上面列的几个问题，有hue框架自身的局限性，也有开发时对前端的重视度不足引起的。当然这些都可以归类到历史原因。
尝试做过哪些处理？
针对静态资源部分曾做过调研，hue是基于django框架开发，python作为底层语言。在这样的架构下借助于django-pipeline可以实现静态资源的优化。
虽然找到了能完成静态资源优化工作的工具，对比最近几年前端日新月异的工具演化，django-pipeline的API还是略显笨拙。并且此处改造强依赖于server端逻辑，实现成本较高，并且收益较小，因此不予考虑。
针对第二条，很自然想到两种办法去处理。一是直接替换前端框架，但是因为替换底层框架工作量相当大，而且测试成本极高，因而放弃。二是按模块替换，但是这会引来第三条组件冗余问题，更是得不偿失。
第三条就相对简单很多。最开始接触项目我曾统计过平台用到的前端组件，在可以相互替代的组件中选出一个供使用，其余的逐步替换直至从项目中移除。
第四条就相当难办了，在现有架构下前后端胶着的问题几乎没有任何可操作的空间。
在接手项目初期一条条处理下来，就是小打小闹并没有质的改变。
为什么选择前后端分离？
在对项目做了一些调研、处理均未获得较大收益之后，我开始尝试使用前后端分离的方式进行处理。主要基于以下几点考虑：
- Odeon作为平台性的WEB应用，无需考虑SEO、读屏等场景，天然适合前后端分离方案
- 已有开发模式，前端必需有一台完备的开发环境，前后端分离可以让前端仅仅关注前端部分的交互功能
- 通过API来约束前、后端，可以让职责更清晰，同时降低维护成本
- 对已有功能可以暂时不作处理，通过逐步重构的方式更平稳的进行各个击破
- 最重要的一点是，前端可以自主选择更为顺手的脚手架处理资源优化
虽然列了几条考虑方面，但是最核心的其实只有一个词「解耦」。一是指具体代码层面的解耦，如业务逻辑、架构、组件等；二是前后端分工层面的解耦，可以做到各司其职，相互独立开发。
解耦后最直观的影响就是提升开发效率、降低维护成本，同时解决平台面临的问题。
具体做了哪些事？
说到底前后端分离只是一个概念性的架构，具体落地有很多种实现方式。在Odeon项目的实践中主要有以下五点：
- 搭建一套前端工作流，这里选的是vue全家桶，包含了webpack、es6、element等
- 实现前端通用逻辑的开发，如登录验证、用户信息、集群切换等基础功能
- 在域名下选择一个path，供前端使用
- QA、prePub、online等环境，通过nginx配置静态资源目录，无需经过python
- 本地开发采用代理的方式，将前端代码无侵入的映射到某个物理环境
前面四条相对容易理解，对于最后一条「无侵入式」的代理可能会略显困惑。
其实很简单，比如我可以QA环境为蓝本，开发时使用的URL即为QA环境的域名，针对前端的path动态代理至本地。这样即可使用QA环境的绝大多数功能以及数据服务，而前端部分则为本地开发代码，具体逻辑可以看下图。
这样一来即可达到，并未动QA环境一行代码，又可以基于QA环境进行开发的效果。当然实际开发中更推荐使用同一需求下的后端同学的环境，这样能够更加高效快捷。
本地代理使用了基于nodeJS开发的代理工具whistle，感兴趣的话可以尝试使用。
这样就万事大吉了？
答案必然是否定的，前后端分离是根据当项目现状，以及可预见的迭代方向上作出的一个选择，能够解决眼前问题，同时适应中长期的前端项目发展要求。
但正如三国演义中第一回提到的一样「分久必合，合久必分」，如果只是一味的强调前后端分离而不知变通的话，可能在特定场合下会因为限制了技术的多样性而引起反效果。
以上就是最近Odeon在前后端分离上的一些探索，希望对你有所帮助。