OSGi和Akka如何相互受益?这是如何组织的? [英] How can OSGi and Akka benefit from each other? How is this structured?

问题描述

跟进我的不合逻辑的问题要求使用OSGi 或 Akka，我被告知可以将两者一起使用，并且它们各自解决了不同的问题.我可以使用OSGi提供模块化和可扩展性，并使用Akka提供可扩展性和性能.由于没有太多结合OSGi和Akka进行试验的尝试，所以我仍然有几个问题.

如何将OSGi和Akka一起使用并从中受益?这是如何组织的?您所有的演员是否都驻留在一个OSGi捆绑软件中，是否每个人都得到一个单独的捆绑软件，是否有混合解决方案，或者不是真的有正确"的方式来做到这一点?

我会将大型组件划分为不同的OSGi捆绑包.每个捆绑包都存在不同的Akka演员.然后，可以根据该束上的负载来分别缩放每个束.在每个捆绑包中，透明的负载平衡可用于将负载分散到不同的参与者上. 这是这样做的正确和现实的方法吗?

编辑

实施后的想法: 他们显然是相辅相成的！我将应用程序划分为大块，然后使用Spring将其注入到应用程序的各个部分.在大块内部，我仅使用Akka.块的门是类型演员.为了使我的系统完全异步，我必须实现一些额外的功能.因此，没有阻塞调用保留，所有接口方法都应返回void类型.找不到其他方法.然后，您可以将消息作为属性传递给接口，该属性在请求的整个过程中都随身携带，并在请求开始时注册到响应者"中.最后，成功返回DeferredResult对象，或者返回错误/超时.

解决方案

这是我将两者结合使用的方式.

这样想吧...

面向对象程序设计引入了新的封装层.在对象级别(带有私有成员). OSGi仅启用JAR级封装.如果没有OSGi，则在编译后将其全部融为一体. OSGi在JAR级别强制执行该接口.因此，您将拥有更干净的模块化和更好的代码(出于同样的原因，任何类型的封装都很好).

我仅使用OSGi进行JAR级别的封装.我会在Akka中做任何重叠的功能，例如根据使用情况扩展某些模块，因为API是更高级别的，因此更易于实现和维护.

但是，关于它们的许多事情并没有重叠，因此您应该能够牢记这一经验法则，轻松地了解行进路线.

对我来说，OSGi对于强制执行良好的设计非常有用，因为它具有有关如何使用服务的规则...在JAR级别强制执行接口.

我想说您的最后一段很好地解释了这一点.就像对任何大型软件一样，只需对其进行模块化即可.但是现在它们是OSGi捆绑包.

如果您有后续问题，请发表评论.我可以编辑说更多.我已经在一起使用了一段时间了.

评论回复

阅读您的问题，似乎您可能知道一些我不知道的事情.我不确定，因此请告诉我这篇帖子是否错过了它的标记.我是一个Akka家伙，后来又做了一些OSGi，如果您反过来做了，您可能会意识到我没有的选择.

共享参与者系统是微不足道的. OSGi捆绑包不会像框架那样引起控制权的倒置.您只需像其他任何库代码一样调用它即可.

无论您在哪里创建actor，都使用system.actorOf在另一个包中调用actor的类，仅此而已.您的问题似乎意味着您对其他OSGi选项了解更多，或者可能是在考虑OSGi会进行控制反转，因此每个捆绑软件都将卡在其自己的actor系统上.

如果仍然不清楚，我建议您使用一个快速原型.只要通过使用该设计的第一个端到端测试，然后重构OSGi中的添加即可.

Following up my rather illogical question, asking to use OSGi or Akka, I was advised that the two can be used together, and that they each solve a different problem. I could use OSGi to provide modularity and updatability, and Akka to provide scalability and performance. As there hasn't been a lot of experimenting with combining OSGi and Akka, I still have a couple of questions.

How can OSGi and Akka be used together and benefit from each other? How is this structured? Do all your actors reside in one OSGi bundle, do they each get a separate bundle, is there a hybrid solution or isn't there really a 'right' way to do it?

I would divide the big components in different OSGi bundles. Each bundle exists of different Akka actors. Each bundle can then be scaled separately from each other in function of the load on that bundle. In each bundle transparent load balancing can be used to spread the load over different actors. Would this be a correct and realistic way of doing this?

EDIT

Thoughts after implementation: They clearly complement each other! I divided my application into big blocks, which I then injected into parts of the application using Spring. Inside the big blocks I solely used Akka. The gates to the blocks are Typed Actors. To make my system completely asynchronous I had to implement some extra functionality. So no blocking calls remain all interface methods should return the void type. Couldn't find any other way. You can then pass a message through the interface as an attribute that gets carried around for the whole journey of the request, which gets registered into a "Responder" at the beginning of the request. At the end a DeferredResult object gets successfully returned or an error/timeout is returned.

解决方案

Here's how I use the two together.

Think of it like this...

Object-Oriented Programming introduced new layers of encapsulation. At the object level (with private members). OSGi just enables JAR-level encapsulation. Without OSGi, as soon as its compiled, it all melts into one pot. OSGi enforces the interface at the JAR level. And because of that, you have cleaner modularity and better code (for the same reasons any type of encapsulation is good).

I only use OSGi to do the JAR-level encapsulation. Any features that overlap such as scaling up certain modules based on usage, I do in Akka, because the API is higher-level and so easier to do and maintain.

But, many things about them don't overlap, so you should be able to see what goes where pretty easily with that rule of thumb in mind.

OSGi is to me just very useful for enforcing a good design, because it has rules for how I can consume a service... enforcing an interface at the JAR-level.

I'd say your last paragraph explains it well. Just modularize it like you would for any large-scale software. But now they are OSGi bundles instead.

If you have follow-up questions, please do comment. I can edit to say more. I've been using the two together for a while now.

Edit: Response to comments

Reading your question, it seems you may know some things I don't. Which I can't be sure of, so let me know if this post misses its mark. I'm an Akka guy who later did some OSGi, if you did that the other way around, you may be aware of options that I am not.

sharing the actor system is trivial. OSGi bundles don't cause inversion of control like a framework. You just call it like any other library code.

Wherever you are creating the actor uses system.actorOf calling the class of an actor in another bundle, and that's it. Your question seems to imply you know more about other OSGi options or perhaps are thinking that OSGi will do inversion of control and so each bundle would be stuck with its own actor system.

If it's still unclear, I'd recommend a quick prototype. Just pass the first end-to-end test that uses the design and then refactor adding in OSGi.

这篇关于OSGi和Akka如何相互受益?这是如何组织的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！