继续我的相当不合逻辑的问题,要求使用OSGi 或 Akka,我被告知两者可以一起使用,并且它们各自解决了不同的问题.我可以使用OSGi来提供模块化和可更新性,而Akka则可以提供可扩展性和性能.由于没有很多尝试组合OSGi和Akka,我仍然有几个问题.
OSGi和Akka如何一起使用并互相受益？这个结构如何？你的所有演员都驻留在一个OSGi包中,他们每个人都得到一个单独的包,是否有一个混合解决方案或者不是真的有"正确"的方法吗？
我会将不同OSGi包中的大组件分开.每个包都存在不同的Akka演员.然后,每个束可以根据该束上的负载彼此分开地缩放.在每个捆绑中,透明负载平衡可用于将负载分散到不同的角色上.这是一个正确和现实的方法吗？
编辑
实施后的想法:它们明显相得益彰!我将我的应用程序划分为大块,然后使用Spring将其注入应用程序的各个部分.在大块里面,我只使用了Akka.块的门是Typed Actors.为了使我的系统完全异步,我必须实现一些额外的功能.因此,所有接口方法都不应该返回void类型.找不到任何其他方式.然后,您可以通过接口传递消息作为在请求的整个过程中被携带的属性,该消息在请求开始时被注册到"响应者"中.最后,成功返回DeferredResult对象或返回错误/超时.
以下是我如何将两者结合使用。
这样想吧...
面向对象编程引入了新的封装层。在对象级别（具有私有成员）。OSGi 只是启用 JAR 级别的封装。如果没有 OSGi，一旦编译完成，一切都会融为一锅。OSGi 在 JAR 级别强制执行接口。正因为如此，您拥有更清晰的模块化和更好的代码（出于同样的原因，任何类型的封装都是好的）。
我只使用OSGi来做JAR级别的封装。任何重叠的功能，例如根据使用情况扩展某些模块，我在 Akka 中这样做，因为 API 级别更高，因此更容易执行和维护。
但是，关于它们的许多事情并不重叠，因此您应该能够根据经验法则轻松地了解哪些内容会发生在哪里。
OSGi 对我来说对于强制执行良好的设计非常有用，因为它有关于如何使用服务的规则...在 JAR 级别强制执行接口。
我想说你的最后一段解释得很好。就像对任何大型软件一样将其模块化。但现在它们是 OSGi 捆绑包。
如果您有后续问题，请发表评论。我可以编辑说更多。我已经将两者一起使用有一段时间了。
编辑：回复评论
看了你的问题，看来你可能知道一些我不知道的事情。我不能确定这一点，所以如果这篇文章没有达到目的，请告诉我。我是一个 Akka 人，后来做了一些 OSGi，如果你反过来做，你可能会知道我不知道的选项。
共享 Actor 系统很简单。OSGi 包不会像框架那样导致控制反转。您只需像任何其他库代码一样调用它即可。
无论您在何处创建 actor，都使用 system.actorOf 调用另一个包中的 actor 的类，仅此而已。你的问题似乎暗示你对其他 OSGi 选项了解更多，或者可能认为 OSGi 会进行控制反转，因此每个包都会被其自己的参与者系统所困扰。
如果仍然不清楚，我会推荐一个快速原型。只需通过使用该设计的第一个端到端测试，然后在 OSGi 中添加重构即可。