Python 框架作为"Java + OSGi"组合的替代方案

我认为OSGi提供的很多功能与Java的体系结构密切相关：它的类加载器和类型安全。实现服务注册表应该不会太难，但用OSGi的准确性来管理它几乎是不可能的。显然，OSGi提供的多命名空间功能在Python中是不起作用的，除非您将模块移动到单独的进程中，这将需要更昂贵的进程间通信来实现模块间通信。您可以从ApacheCelix开始，它是基于本机的，但我对它的实用性也有类似的怀疑，因为本机代码没有提供很多关于其依赖关系的信息。

一个更通用的解决方案是通用OSGi的最初想法。在这个模型中，您可以保持OSGi框架用于部署和管理。但是，您创建的处理程序捆绑包可以映射使用其他语言编写的捆绑包。例如，Python处理程序或C++本机。处理程序将本地服务注册表模型映射到OSGi服务注册表。这非常容易做到，因为OSGi服务注册表是正确的事件。本机处理程序将映射捆绑事件（如启动/停止），以指示操作系统启动/停止本机代码。

Peter已经提到了Apache Celix。也许值得一试。Celix的一部分是远程服务管理（RSA）实现，因此可以在分布式环境中使用它。最终，这种实现还将使与基于Java的OSGi框架进行通信成为可能，从而使Celix+RSA成为JNI的替代方案。这还有一个额外的好处，即本机代码和java代码不共享同一个过程。如果一端遇到问题，另一端仍在运行。

与Celix一致，您也可以看看Native OSGi，这是Celix和一些C++类OSGi框架（CTK插件框架和nOSGi）为实现Native类OSGi而做出的努力。这包括诸如定义良好的API、捆绑包格式、代码共享等

考虑到您的需求，我认为Celix和Native OSGi可能非常适合。