概述

公司在16年之前，采用的技术结构都是模块化。大概在17年的时候，根据公司要求，开发新的产品，同时要使用新的框架技术。当时Spring boot 已经开始普遍开来，当然选择Spring boot 不仅仅是其发展迅速，而更重要的看重其出身，没错，程序员在选择技术的时候，也是看出身的。Spring Boot 是 Spring 团队，这个出生于名门的天之骄子。

下面先简单介绍下OSGI与使用的依赖注入（BluePrint）

OSGI 简介

OSGi是一个动态的Java模块（Module）系统，它规定了如何定义一个Module以及这些模块之间如何交互。每个OSGi的Java模块被称为一个bundle。每个bundle都有自己的类路径，可以精确规定哪些Java包和类可以被导出，需要导入哪些其它bundle的哪些类和包，并从而指明bundle之间的依赖关系。另外bundle可以被在运行时间安装，更新，卸载并且不影响整个应用。通过这种方式，分层的类加载机制变成了网状的类加载机制。在应用程序启动之前，OSGi就可以检测出来是否所有的依赖关系被满足，并在不满足时精确报出是哪些依赖关系没被满足。

OSGi 框架

OSGi框架从概念上可以分为三层：模块层、生命周期层 ，服务层 运行环境

• Module Layer：模块层主要涉及包及共享的代码；
• Lifecycle Layer：生命周期层主要涉及Bundle的运行时生命周期管理；
• Service Layer：服务层主要涉及模块之间的交互和通信。
• 运行环境

模块层

模块层是 OSGi 框架中最基础的部分。

OSGi 的模块化，是通过为 Jar 包添加metadata 来定义哪些类该暴露，哪些类该隐藏，其控制单元叫做 Bundle（jar 包）。

Bundle

首先，必须先了解一个基本概念——什么是Bundle？

什么是 Bundle ?

bundle 是以 jar 包形式存在的一个模块化物理单元，里面包含了代码，资源文件和元数据（metadata），并且jar包的物理边界也同时是运行时逻辑模块的封装边界。

生命周期层

生命周期层在OSGi框架中属于模块层上面的一层，它的运作是建立在模块层的功能之上的。

生命周期层的主要功能是控制动态安装、开启、关闭、更新和卸载的bundles。

生命周期层让你能够从外部管理应用或者建立能够自我管理的应用（或者两者的结合），并且给了应用本身很大的动态性。

前面已经了解了 Bundle 的概念和作用。但是要真正使用 Bundle，需要使用生命周期层的API，来和OSGi框架的生命周期层进行交互。

在标准的Java编程中，可以通过将jar包放到classpath中来使用它。而bundle则不是这样，Bundle只有在被安装（install）到一个OSGi框架的运行实例中才能用起来。并且OSGi框架支持对这些bundle完整的生命周期管理，并且支持这些管理操作在应用执行完成。

下图为 Bundle 生命周期的状态转移图：

服务层

服务层关注于模块，特别是模块内的组件间的交互和通信。

服务层支持和促成了一个灵活的应用编程模型。涉及面向服务的发布、查找和绑定的交互模式：服务提供者将服务发布到服务注册中心，服务客户端搜索服务注册中心，查找可供使用的服务。

其实就是面向接口编程，不同之处在于：

如何使服务的实例在程序的其他部分可用。——注册服务

如何使程序的其他部分发现这个可用的服务。——检索服务

OSGI实现机制

从本质上说，OSGi是充分使用了Java的类加载机制，对模块和应用进行了更加精细粒度的控制，然后在类域上建立一系列松耦合应用。OSGi为每一个Bundle组件定义了一些元数据信息，通过这些元数据，OSGi在运行时为每一个Bundle构建了一个独立的类域（即类空间）。

OSGI可以使项目完全松偶合，一种很好的架构，以framework为核心，可挂接很多bundle，bundle间还能共享资源，这样项目不管在开发，调试，找错，架构上来说都相当的清晰.

OSGI中bunlder间的通信方式

在 OSGi 中，服务是实现 bundle 间交互和应用灵活性的基石。借助于服务，我们能够降低 bundle 之间的耦合，更加有利于软件的重用，通过强调面向接口编程，可以提高软件的灵活性与设计水平。

传统方式下，我们注册服务都是在 bundle 的激活器（Activator）中使用 BundleContext.registerService() 方法完成的。而服务的获取需要通过 BundleContext.getServiceReference() 获取 ServiceReference 实例，进而使用 BundleContext.getService() 得到真正的服务实例。这种方式虽然能够完成服务的发布与使用，但是有一定的不足，具体来讲：

• 产生较多的样板式代码。OSGi 的 bundle 是动态化的，伴随着 bundle 的安装和卸载，它所发布的服务也会动态地处于可用或不可用的状态，因此每次使用服务的时候，我们都需要借助 BundleContext 对象去服务注册中心查找，而不能通过一次查找，一劳永逸地持有服务对象的引用。尽管有 ServiceListener 和 ServiceTracker 帮助我们监听和跟踪服务的状态，但是总体而言这种方式较为繁琐且容易出错。
• 影响启动时间，服务在激活器中注册时，需要实例化所有要发布的服务对象，因为激活器的 start() 方法是同步调用的，所以会影响到整个应用的启动时间。
• 加大内存的占用，在激活器中注册服务时，我们需要实例化所有的服务对象，但是这些服务在应用运行期间，并不一定会用到，这在无形中加大了内存的占用。
• API 依赖引起的平台侵入性。使用传统方式注册和使用服务，会用到大量的 OSGi API，从而产生与 OSGi 平台的耦合，如果要将代码复用到非 OSGi 场景之中，需要较多的重构工作。

OSGi 通过声明式服务（Declarative Service）以及 Blueprint 规范来解决这些问题。声明式服务基于组件模型理论，最早出现在 R4 compendium 规范之中，而 Blueprint 规范来源于 Spring Dynamic Modules 项目，最早出现于 R4.2 企业规范之中。

最开始的时候，我们采用的是声明式服务，后来切换到BluePrint。

Blueprint简介

相信很多java开发人员都会接触过Spring，作为一个成功的依赖注入（DI）实现框架，Spring被十分广泛地应用在很多java项目中。为了适应OSGI的动态环境，spring发展出spring dynamic modules（SpringDM）,Blueprint的规范则是来源于SpringDM的进一步发展。

目前，Blueprint规范主要有两个实现：Aries blueprint和Gemini blueprint，它们分别来自Apache和Eclipse两个开源组织。我们后续的课程主要基于Aries Blueprint的实现。Blueprint可以象Spring那样，通过XML的方式构建应用，当然也可以通过Blueprint annotation的方式实现同样的目的。由于XML可以和bundle分离，单独部署到servicemix上，所以比annotation的方式更具灵活性，所以我们推荐使用XML的方式。由于Blueprint和spring的渊源，两者在语法方面十分相似，有spring应用经验开发人员会十分轻松地掌握Blueprint。

更加简单的说明下，就是BluePrint就是把OSGI bundle间的调用，改成Spring 的依赖注入方式。

Karaf简介

Karaf是基于OSGI之上建立的应用容器，能方便部署各种选定的组件，简化打包和安装应用的操作难度。Open DayLight项目发布之初，后台框架仅采用OSG技术，但自从第三版氦He版本至今， Open Daylight项目就采用了Kaaf作为后台的框架，明显提升了项目的可用性和灵活性。

Karaf是一个 Apache软件基金会项目，具有 Apache v2许可证。是一个基于实时运行的轻量级的基于OSGI的容器，各种组件和应用都能部署到这个容器中。

Karaf 架构图

总结

在早期的架构使用的OSGI模块化，BulePrint可以简单理解为是对OSGI的一种实现方式，Kafka 是运行服务器。现在使用这种架构的公司应该佷少了，尤其是现在java 9已经推出了 模块化。

但每种架构都有其辉煌历史，只不过是现在随着微服务化的发展对模块化冲击，确实挺大，而且Spring boot 更加适应当下的开发节奏。

好了早期的框架结构，就分享到这里。下面将会整理，Spring boot 使用过程。