我店里有人想出了一个巧妙的方法来使用 spring 框架实现多租户。他们基本上使用常用服务创建了一个主要的父应用程序上下文,然后为每个新租户创建了一个带有特定于租户 bean 的子上下文。它运作良好,我们可以即时启动新租户。
现在我们对使用 OSGI 有硬性要求,而这种模式正在崩溃。我们尝试了几种不同的方法,要么它们不起作用,要么我们需要关闭 VM 以添加新租户以添加新声明的服务。
我店里有人想出了一个巧妙的方法来使用 spring 框架实现多租户。他们基本上使用常用服务创建了一个主要的父应用程序上下文,然后为每个新租户创建了一个带有特定于租户 bean 的子上下文。它运作良好,我们可以即时启动新租户。
现在我们对使用 OSGI 有硬性要求,而这种模式正在崩溃。我们尝试了几种不同的方法,要么它们不起作用,要么我们需要关闭 VM 以添加新租户以添加新声明的服务。
创建一个父 OSGi 框架,然后为每个租户创建一个单独的 OSGi 框架。使用系统捆绑包将共享服务从父框架导出到租户框架。
您可以使用 OSGi 蓝图很容易地做到这一点。
您可能知道 Blueprint 是 Spring Dynamic Modules 的继承者......所以,很明显,Blueprint 上下文和 Spring 上下文之间有很多相似之处。
这是 OSGi 蓝图的指南:
http://www.javabeat.net/2011/11/blueprint-and-service-dynamism-in-osgi/
我建议您创建一个代表您的父 Spring 上下文的“父”包,然后为每个租户安装一个新包,该包使用父包导出的 OSGi 服务。
由于捆绑包可以随时动态安装和卸载,因此您应该能够获得比单独使用 Spring 更好的动态性。
祝你好运。
不幸的是,没有标准的方法来做到这一点。
多框架方法(也必须自己实现)的替代方法是引入一个“上下文”对象(如 Spring 应用程序上下文),该对象实现了getService
一种基于某些租户特定过滤器配置获取适当 OSGi 服务的方法。
我们在 Gyrex 中做了类似的事情。但同样,它是一个自定义解决方案(尽管是开源的),而不是 OSGi 标准。