F1V3.0 F1平台2.X主要优缺点

F1平台2.x采用OSGI架构，OSGi 是由OSGi联盟发起的以java为技术平台的动态模块化规范，有其自身的优缺点。

1 OSGI优点

1.1 模块化

模块化的标准有三点：一是要保证每个模块在逻辑和功能方面都是完整独立的来增加模块的可重用性；二是要求每个模块都应该定义良好的外部接口和依赖项以便与其他模块松散耦合；三是模块应该将内部包和外部模块有效的隔离，来避免内部包的更新对外部模块的影响。普通的 jar 包只能满足模块性的第一个标准。OSGi 将应用程序划分成不同组件（称为 Bundle），把 Bundle 作为模块化单元，每个 Bundle 实际上就是一个 jar 包，jar 包中除了类和资源信息以外，还包括 OSGi 模块层运行需要的 OSGi 元数据。元数据中定义了该模块依赖于哪些外部模块中的包、以及该模块提供了哪些包可供外部模块引用，从而满足了模块化的另外两个标准。

1.2 依赖管理

传统的 Java EE 架构中，对于一个依赖于很多第三方程序库的企业应用程序，通常的做法是将应用程序需要的第三方程序库都加入到系统中。这样有产生版本冲突问题。因为应用程序内只能支持某个类的单一版本，如果多个第三方程序包依赖于不同版本的公共类库，就会出现版本冲突的问题。OSGi 通过 Bundle 存储库很好的解决掉上述问题，有了 Bundle 存储库之后，应用程序中只包含特定于应用程序的模块，所有的依赖公共类都放到 Bundle 存储库中进行统一管理。并且 Bundle 存储库可以管理多个 Bundle 的不同版本，应用程序通过在元数据中来指定依赖于 Bundle 存储库中某一 Bundle 的具体版本，从而来使用特定版本的公共类。

1.3 动态化

OSGi可以做到动态修复缺陷，不停机地增加或禁止某块功能、更新某个模块等。这一点是非常有用的，尤其是当这个应用非常大的时候。比如在 100 个节点上去更新一个 100Mb 的应用，在 J2EE 架构中所带来的时间开销是非常大的。尽管更新的只是某单一的模块，也需要花费相当于重新安装的时间。然而在 OSGi 应用中，您可以选择只更新这 100MB 应用中的某一模块，比如 10MB 的业务模块，在 100 个节点上更新某一 10MB 模块要比更新整个 100MB 应用要快得多；而且在 OSGi 架构中，更新局部模块不需要重启整个应用。这样就大大简化了运维的工作，节省时间。

2 OSGI主要问题

OSGI有很多优势，但同时也存在不少问题，以前很简单的事情现在变得复杂。

2.1 调试复杂

开发传统J2EE程序时，设置tomcat的源代码后，只需要打断点，调试工作非常愉快。而使用OSGI框架后，经常出现断点进不去的情况。

2.2 Web页面需要重新加载才能生效

Web页面也是OSGI的一个bundle，每次修改后都需要更新才能生效，这给页面调试带来了很多的麻烦，我只是修改了一个样式，一个标签也需要更新，页面开发大量的时间浪费在更新上。

2.3 单元测试很复杂

进行单元测试需要启动整个OSGI环境，导致单元测试配置复杂，测试过程漫长，本来只需要1、2秒的测试过程，由于需要启动OSGI环境，测试过程需要加长到几十秒，大量的时间浪费在OSGI环境的启动上。实际情况，自从使用OSGI框架后，单元测试就很少执行了。

2.4 动态加载看着很美

OSGI框架具有天然的动态加载特性，但理想很丰满，现实很骨感。现有的J2EE基本都会使用到Spring，而Spring的统一容器和OSGI的模块化具有很多不兼容性，如果再加上Hibernate，动态加载基本不可能。动态更新bundle，Spring和Hibernate需要重建，可能导致其他bundle更新，从而发生连锁反应，动态加载不能正常完成。根据很多项目的实际使用情况看，前端模块动态更新基本没问题，没有其他bundle依赖的后端模也基本没问题，而其他情况动态加载基本都会失败，需要重启整个环境才能更新。动态加载成为一种鸡肋，看着很好，实际很多情况都没法使用。

2.5 Jar引入复杂

以前只需要把Jar包加入到工程的classpath中就ok，现在如果需要用到OSGI存储库中不存在的第三方jar包。操作比较麻烦，常用方式有：
1）将jar转换成bundle，加入到OSGI存储库中，在bundle中import进来。
2）加入到bundle的classpath中，再import到bundle中。
两种方式都比以前复杂很多，特别对于刚上手OSGI的开发人员很容易懵。我一直都这么用的，怎么不行了？

以上提到的这些OSGI的优缺点，F1V2.X不可避免的继承下来了。除了OSGI的这些共性问题，平台还存在错误定位麻烦、服务启动慢等问题。