基于组件中间件的前端架构

在现在的软件设计上，基本上采用的都是分布式系统，前端尤其突出，回忆一下，我们将CSS、JS独立到不同的CDN或独立静态池上，我 们将图片放到专属的图片服务器上，这都是分布式系统的体现。我们的交互界面，我们的后端程序乃至数据库都存储在各个不同的服务器上，最终，通过计算机网络 将它们连接起来。

 

因为采用了分布式系统，前端开发中也遇到了分布式系统本身的问题，比如说分布式系统节点的广泛带来了复杂的部署环境，比如分布系统组件的协同工作会因延迟、过载、甚至失效而带来的不稳定性。

 

以往，我们在前端开发过程中，为了避免这些分布式系统所带来的问题，采用了各种方法，比如下图中，某网站采用将js直接写入页面中的方式避免上述问题。（当然我也可以认为这段代码是开发人员偷懒直接复制进去的， XD）

 

view-source:http://news.sina.com.cn/c/2010-11-15/191121475156.shtml

 

让我们试想一下，某天下图中的接口地址变更，开发人员需要更新数万页面以保证页面工作正常，即便是拥有了各种分发机制，甚至使用重写或者301转向，也是一种维护成本高的工作方式。

 

为了解决分布式系统所带来的问题，各公司都引入了不同的解决方案，最典型的解决方案就是中间件 。

 

在国内的各大主流网站中，我们不难发现类似下面的代码，从而从不同的网络节点中获取到对应的组件

 

上述代码是一种直接写入N个SCRIPT标签的变体，他的本质是通过getFileVesion()获取参数数组中的路径，循环建立SCRIPT/LINK对象后再插入到页面中，我们称呼这种中间件为对象计算中间件 ，它给我们的开发过程带来很多便利，前端工程师采用面向对象的方式编写各种组件来降低整个开发流程的复杂度，并且可以灵活有效的进行分发以提供可重用 的功能。

 

虽然分布式对象计算中间件成熟稳定，但它也存在着一些不足，例如，当我某一个对象/组件依赖于其它对象/组件时，这两个对象需要明确对方已经载入， 因此开发人员需要设计代码来实现这种对象与对象，组件与组件之间的关联，开发人员需要判断这些组件是否已经loadReady，或者组件内部需要判断他需 要的对象是否已经加载。

 

与此同时，分布式计算中间件没有提供给我们一个标准化的方式去启用不同的组件，当我们需要停用旧的组件、增加新的组件时，修改原有组件就需要手动的 去维护要增加的内容。例如，上图中，当我需要增加一个获取cookie的方法时，也许我就要增加xxxx/js/getCookie.js，甚至，我还要 给他提供一个版本号来标识版本以及清除分布式系统的缓存。

 

那么为了解决计算中间件的上的缺陷，设计人员开发出一种称为组件中间件 的技术，组件中间件通过一个组件对象来实现不同组件的调用以及管理。

 

组件中间件中，组件是功能实现的实体，他提供了一套方法以及连接点，以便不同的组件之间互相协助。方法可以是require也可以是add，甚至是 when i needed … download，连接点就是需要载入组件的路径，在这种组件架构中，定义良好的关联关系存在于组件中间件与需要载入的对象中间，因为这种关系的存在，所 以，我们可以通过组件定义、构造、加载、剔除所需要的对象，而对象也可以被要求预载入，触发事件时载入 等等。

 

同时，组件中间件提供了对接入点的预定义，我们可以通过配置组件来达到加载不同服务节点，不同版本的对象。

 

虽然中间件拥有很多益处，但对于分布式系统而言，中间件也有不可靠的地方，当系统宕机时，当网络缓慢甚至断开时，中间件就无法保证所需要的对象被加载，因此在中间件的设计上也需要考虑各种可能出现的错误，并做好容错机制保证前端的页面的呈现。