Odeon的前后端分离之路

很幸运于今年加入科大讯飞，加入卧虎藏龙的大数据研究院。负责Odeon大数据平台前端方向的探索和研发工作。

在此之前，Odeon上线已有一年多，其间版本更新频繁。很难想象在仅有大数据开发和服务端同学的情况下，能将平台前端部分维护的相当稳定。而且还在不断快速推出新功能，确实很不容易。

Odeon背后有着很多大数据相关的组件，以及复杂的集群部署方案。这些对于我来说是完全陌生业务方向，虽然不在我的研发范围内，但也在逐步做学习了解。

对于前端来说，最重要的当然是Odeon的WEB侧。在最早大数据项目立项时，根据当时所处的环境，很明智的采用了hue作为WEB选型。

作为一个同时集成了前端界面、后端功能以及成熟的部署方案的框架，hue为早期的项目的快速推进起到了至关重要的作用。在不足三个月时间内就完成Odeon的第一个版本的上线。

项目演进一年后，经过数次功能累加的Odeon已经逐渐在WEB侧表现出一些不足，主要有以下几点。

上面列的几个问题，有hue框架自身的局限性，也有开发时对前端的重视度不足引起的。当然这些都可以归类到历史原因。

针对静态资源部分曾做过调研，hue是基于django框架开发，python作为底层语言。在这样的架构下借助于django-pipeline可以实现静态资源的优化。

虽然找到了能完成静态资源优化工作的工具，对比最近几年前端日新月异的工具演化，django-pipeline的API还是略显笨拙。并且此处改造强依赖于server端逻辑，实现成本较高，并且收益较小，因此不予考虑。

针对第二条，很自然想到两种办法去处理。一是直接替换前端框架，但是因为替换底层框架工作量相当大，而且测试成本极高，因而放弃。二是按模块替换，但是这会引来第三条组件冗余问题，更是得不偿失。

第三条就相对简单很多。最开始接触项目我曾统计过平台用到的前端组件，在可以相互替代的组件中选出一个供使用，其余的逐步替换直至从项目中移除。

第四条就相当难办了，在现有架构下前后端胶着的问题几乎没有任何可操作的空间。

在接手项目初期一条条处理下来，就是小打小闹并没有质的改变。

在对项目做了一些调研、处理均未获得较大收益之后，我开始尝试使用前后端分离的方式进行处理。主要基于以下几点考虑：

虽然列了几条考虑方面，但是最核心的其实只有一个词「解耦」。一是指具体代码层面的解耦，如业务逻辑、架构、组件等；二是前后端分工层面的解耦，可以做到各司其职，相互独立开发。

解耦后最直观的影响就是提升开发效率、降低维护成本，同时解决平台面临的问题。

说到底前后端分离只是一个概念性的架构，具体落地有很多种实现方式。在Odeon项目的实践中主要有以下五点：

前面四条相对容易理解，对于最后一条「无侵入式」的代理可能会略显困惑。

其实很简单，比如我可以QA环境为蓝本，开发时使用的URL即为QA环境的域名，针对前端的path动态代理至本地。这样即可使用QA环境的绝大多数功能以及数据服务，而前端部分则为本地开发代码，具体逻辑可以看下图。

QA环境无侵入式开发流程.png

这样一来即可达到，并未动QA环境一行代码，又可以基于QA环境进行开发的效果。当然实际开发中更推荐使用同一需求下的后端同学的环境，这样能够更加高效快捷。

本地代理使用了基于nodeJS开发的代理工具whistle，感兴趣的话可以尝试使用。

答案必然是否定的，前后端分离是根据当项目现状，以及可预见的迭代方向上作出的一个选择，能够解决眼前问题，同时适应中长期的前端项目发展要求。

但正如三国演义中第一回提到的一样「分久必合，合久必分」，如果只是一味的强调前后端分离而不知变通的话，可能在特定场合下会因为限制了技术的多样性而引起反效果。

以上就是最近Odeon在前后端分离上的一些探索，希望对你有所帮助。