我听说过很多关于Akka框架(Java / Scala服务平台)的赞誉,但是到目前为止,还没有看到很多对用例有用的实际用例。因此,我想听听有关开发人员成功使用它的知识。
仅一个限制:请不要包括编写聊天服务器的情况。(为什么?因为这已被过度用作许多类似事物的示例)
我听说过很多关于Akka框架(Java / Scala服务平台)的赞誉,但是到目前为止,还没有看到很多对用例有用的实际用例。因此,我想听听有关开发人员成功使用它的知识。
仅一个限制:请不要包括编写聊天服务器的情况。(为什么?因为这已被过度用作许多类似事物的示例)
Answers:
到目前为止,我已经非常成功地在两个实际项目中使用了它。两者都位于接近实时的交通信息领域(交通流量就像高速公路上的汽车一样),分布在多个节点上,整合了多方之间的消息以及可靠的后端系统。我还没有随意提供有关客户端的详细信息,当我确定时,也许可以将其添加为参考。
Akka确实完成了这些项目,即使我们是从0.7版本开始的。(我们正在使用scala)
最大的优势之一是,您可以轻松地由参与者和消息组成几乎没有重复电镀的系统,它的伸缩性非常好,而无需手动卷入线程的所有复杂性,并且几乎可以免费在对象之间传递异步消息。
在对任何类型的异步消息处理进行建模方面非常好。与任何其他样式相比,我更喜欢以这种样式编写任何类型的(网络)服务系统。(您是否曾经尝试使用JAX-WS编写异步Web服务(服务器端)?这有很多问题)。因此,我想说任何不想挂在其组件之一上的系统,因为所有组件都使用同步方法隐式调用,并且该组件正在锁定某个对象。它非常稳定,让故障崩溃+主管解决故障的方法确实有效。一切都很容易通过编程进行设置,并且很难进行单元测试。
然后是出色的附加模块。Camel模块确实可以很好地插入Akka中,并可以轻松地开发具有可配置端点的异步服务。
我对该框架感到非常满意,它已成为我们构建的连接系统的事实上的标准。
免责声明:我是Akka的PO
除了提供并发smorgasbord之外,它更易于推理和获取正确的内容(参与者,代理,数据流并发),并且采用STM形式的并发控制。
您可能会考虑以下一些用例:
例如,在借记卡/信用卡交易的优先级队列中,我们将如何使用它。我们有数百万种这样的工具,而工作量取决于输入字符串的类型。如果交易的类型为CHECK,我们的处理量很少,但是如果是销售点,则有很多工作要做,例如与元数据合并(类别,标签,标签等)并提供服务(电子邮件/短信提醒,欺诈检测,资金余额不足等)。根据输入类型,我们组成处理工作然后执行工作所需的各种特征(称为混合)类。来自不同金融机构的所有这些工作都以实时模式进入同一队列。清除数据后,会将其发送到其他数据存储以进行持久性,分析,将其推送到套接字连接或提升到彗星演员。工作参与者不断地自我平衡工作负载,以便我们能够尽快处理数据。我们还可以加入其他服务,持久性模型和stm 对于关键的决策点。
在JVM上传递的Erlang OTP样式消息是在现有库和应用程序服务器的肩膀上开发实时系统的绝佳系统。
Akka允许您像传统方式一样进行消息传递 esb但是速度!它还为您提供了框架中的工具,以管理解决方案所需的大量参与者池,远程节点和容错能力。
我们使用Akka异步处理REST调用-与异步Web服务器(基于Netty)一起使用,与每个用户请求模型的传统线程相比,我们可以将每个节点/服务器服务的用户数量提高10倍。
告诉老板,您的AWS托管账单将减少10倍,这很容易!嘘...虽然没有告诉亚马逊... :)
我们在大型电信项目中使用Akka(不幸的是,我无法透露很多细节)。Akka actor由Web应用程序远程部署和访问。这样,我们就有了一个基于Google protobuffer的简化的RPC模型,并使用Akka Futures实现了并行性。到目前为止,该模型运行良好。注意事项:我们正在使用Java API。
如果您将聊天服务器抽象为一个级别,那么您将得到答案。
Akka提供的消息传递系统类似于Erlang的“让它崩溃”的思想。
因此,有些例子需要改变消息传递的持久性和可靠性:
关于Akka的好处是它为持久性提供了选择,它是STM实现,REST服务器和容错能力。
不要被聊天服务器的例子所困扰,可以将其视为某种解决方案的例子。
有了他们所有出色的文档,我觉得这个确切的问题,用例和示例是一个空白。请记住,这些示例是不平凡的。
(仅凭观看视频和播放源的经验写的,我使用akka并没有实现任何东西。)
我们在工作中的多个项目中使用了Akka,其中最有趣的是与车辆碰撞修复有关。主要在英国,但现在扩展到美国,亚洲,大洋洲和欧洲。我们使用参与者来确保实时提供碰撞修复信息,从而能够安全,经济地修复车辆。
Akka的问题实际上更多是“您不能使用Akka做些什么”。它具有与强大的框架集成,强大的抽象以及所有容错方面的能力,使其成为非常全面的工具包。
您可以将Akka用于多种不同的事物。
我当时在一个网站上工作,在那里我将技术堆栈迁移到了Scala和Akka。我们几乎将它用于网站上发生的所有事情。即使您可能认为聊天示例很糟糕,但基本上都是相同的:
尤其是实时更新很容易,因为它们可以归结为一个聊天示例专家。服务部分是另一个有趣的话题,因为您可以选择使用远程参与者,即使您的应用程序未集群,也可以轻松地将其部署到其他计算机上。
我还将Akka用于PCB自动路由器应用程序,其想法是能够从笔记本电脑扩展到数据中心。您提供的功率越多,结果将越好。如果您尝试使用通常的并发性,那么这将很难实现,因为Akka还为您提供了位置透明性。
目前,作为一个空闲时间项目,我正在仅使用参与者来构建Web框架。同样,好处是从单个计算机到整个计算机集群的可伸缩性。此外,使用消息驱动的方法可使您从一开始就面向软件服务。您拥有所有这些不错的组件,彼此交谈,但不一定彼此了解,它们位于同一台计算机上,甚至不在同一数据中心中。
自从Google Reader关闭以来,我首先使用了Akka,从RSS阅读器开始。对我而言,这一切都与封装服务有关。结论:角色模型本身是您首先应该采用的,而Akka是一个非常可靠的框架,可以帮助您实施该模型,并从中获得很多好处。
我们正在使用带有其骆驼插件的akka为twimpact.com分发我们的分析和趋势处理。我们必须每秒处理50到1000条消息。除了使用骆驼进行多节点处理外,它还用于将单个处理器上的工作分配给多个工作人员,以实现最佳性能。效果很好,但是需要对如何处理拥塞有所了解。
我正在尝试使用Akka(Java api)。我试图将Akka基于参与者的并发模型与普通Java并发模型(java.util.concurrent类)进行比较。
用例是一个简单的规范映射,减少了字符计数的实现。数据集是随机生成的字符串(长度为400个字符)的集合,并计算其中的元音数量。
对于Akka,我使用了BalancedDispatcher(用于线程之间的负载平衡)和RoundRobinRouter(以限制我的函数参与者)。对于Java,我使用了简单的fork联接技术(无需任何工作窃取算法即可实现),该技术将fork映射/减少执行并联接结果。中间结果保存在阻塞队列中,以使加入尽可能平行。如果我没有记错的话,那可能会模仿Akka演员的“邮箱”概念,他们会在此接收消息。
观察:直到中等负荷(〜50000弦输入),结果是可比较的,在不同的迭代中略有不同。但是,当我将负载增加到〜100000时,它将挂起Java解决方案。在这种情况下,我为Java解决方案配置了20-30个线程,但在所有迭代中均失败了。
将负载增加到1000000,对于Akka也是致命的。我可以与有兴趣进行交叉检查的任何人共享代码。
因此对我来说,Akka似乎比传统的Java多线程解决方案更好地扩展。可能的原因是Scala的内幕魔术。
如果我可以将问题域建模为传递事件的消息,那么我认为Akka是JVM的不错选择。
执行测试:Java版本:1.6 IDE:Eclipse 3.7 Windows Vista 32位。3GB内存。Intel Core i5处理器,时钟频率为2.5 GHz
请注意,用于测试的问题域可能会引起争议,并且我尝试尽可能公平地对待我的Java知识:-)
我们在口语对话系统(Primetalk中使用Akka)中。内部和外部都可以。为了在单个群集节点上同时运行许多电话通道,显然必须具有一些多线程框架。Akka的作品非常完美。我们以前对Java-concurrency感到恶梦。与Akka一样,它就像秋千一样-确实有效。坚固可靠。24 * 7,不间断。
在通道内部,我们具有并行处理的实时事件流。特别是:-冗长的自动语音识别-由演员完成;-混合少数音频源(包括合成语音)的音频输出产生器;-文本到语音的转换是通道之间共享的一组独立角色;-语义和知识处理。
为了使复杂的信号处理相互连接,我们使用SynapseGrid。它具有在复杂参与者系统中对DataFlow进行编译时检查的优势。
我最近在Akka中实现了规范的map-reduce示例:字数统计。因此,这是Akka的一个用例:更好的性能。比起其他任何事情,它更像是JRuby和Akka参与者的实验,但它也表明Akka不仅是Scala或Java,它还可以在JVM之上的所有语言上运行。