我听说过很多有关 Akka 框架 (Java/Scala 服务平台) 的赞扬,但到目前为止还没有看到许多实际使用案例。所以我很想听听开发者成功使用它的事情。
只有一个限制:请不要包括编写聊天服务器的情况。(为什么?因为这已经被过度使用作为许多类似事物的示例)
我听说过很多有关 Akka 框架 (Java/Scala 服务平台) 的赞扬,但到目前为止还没有看到许多实际使用案例。所以我很想听听开发者成功使用它的事情。
只有一个限制:请不要包括编写聊天服务器的情况。(为什么?因为这已经被过度使用作为许多类似事物的示例)
我已经在两个实际项目中成功地使用了Akka。这两个项目都是关于近实时的交通信息领域(交通指高速公路上的汽车),分布在多个节点上,集成了几个参与方之间的消息,并拥有可靠的后端系统。目前我还不能透露客户的具体信息,等到获得许可后再添加为参考资料。
Akka在这些项目中发挥了很大的作用,尽管我们在0.7版本开始使用它。(顺便说一句,我们使用的是Scala)
其中一个重要优点是可以轻松地将Actor和Message组合成一个系统,几乎没有任何样板代码,它的可扩展性非常好,而且不需要手动编写复杂的线程,你甚至可以免费获得对象之间异步消息传递的能力。
它非常擅长建模任何类型的异步消息处理。我更喜欢使用这种风格编写任何类型的(网络)服务系统,而不是其他风格。(你是否曾经尝试过使用JAX-WS编写异步Web服务(服务器端)?那真的是太麻烦了)。因此,我会说任何一个不想因为某个组件出现问题而导致整个系统挂掉的系统,都可以使用Akka。它非常稳定,而且"让它崩溃+监管者解决方案"的方法可以很好地解决故障问题。一切都很容易设置编程和单元测试。
此外还有优秀的附加模块。Camel模块可以很好地与Akka结合,实现可配置终端点的异步服务的轻松开发。
我对这个框架非常满意,它正在成为我们构建连接系统的事实标准。
免责声明:我是Akka的PO
Akka除了提供更加容易理解和正确性的并发编程方案(包括Actor、Agent、Dataflow Concurrency等),同时还提供STM的并发控制。
以下是一些可能需要考虑的使用场景:
我们使用Akka异步处理REST调用 - 与基于Netty的异步Web服务器一起,与传统的每个用户请求模型相比,可以实现每个节点/服务器服务的用户数量提高10倍。
告诉你的老板,你的AWS托管账单将降低10倍,这是一个不需要思考的选择!嘘...不要告诉亚马逊... :)
我们在一项大规模电信项目中使用Akka(遗憾的是我无法透露太多细节)。Akka actors被部署并通过web应用程序远程访问。通过这种方式,我们采用基于Google protobuffer的简化RPC模型,并使用Akka Futures实现并行性。到目前为止,这个模型的表现非常出色。需要注意的一点是:我们正在使用Java API。
如果将聊天服务器抽象到更高一层,则会得到答案。
Akka 提供了一种类似于 Erlang 的 "让它崩溃" 思想的消息系统。
因此,以下是需要不同耐久性和可靠性的消息传递的示例:
Akka 的好处在于提供了多种持久化、STM 实现、REST 服务器和容错选择。
不要因为聊天服务器的例子而感到烦恼,把它看作是某个解决方案的一个示例。
尽管他们有出色的文档,但我感觉缺少的是这个确切的问题、用例和示例。请记住这些示例都是非平凡的。
(只有观看视频和使用源代码的经验,我没有使用 akka 实现过任何东西。)
我们在工作中的几个项目中都使用了Akka框架,其中最有趣的一个涉及到车辆碰撞修复。主要是在英国,但现在正在扩展到美国、亚洲、澳大利亚和欧洲。
使用Actor机制确保提供实时的碰撞修复信息,以便对车辆进行安全和成本效益的修复。
对于Akka框架,真正的问题是“你不能用Akka做什么”。它能够与强大的框架集成,具有强大的抽象能力和所有的容错特性,使其成为一个非常全面的工具包。
您可以使用Akka完成多种不同的任务。
我曾在一个网站上工作,将技术栈迁移到了Scala和Akka。我们几乎用它来处理网站上发生的所有事情。即使您可能认为聊天示例很糟糕,但它们本质上都是相同的:
特别是实时更新很容易实现,因为它们归结为聊天示例。服务部分是另一个有趣的主题,因为您可以选择使用远程actor,即使您的应用程序没有集群,也可以轻松地在不同的计算机上部署。
我还在使用Akka开发PCB自动布线应用程序,想要实现从笔记本电脑到数据中心的可扩展性。给予其更多的能量,结果会更好。如果您尝试使用常规并发,则这非常难以实现,因为Akka还提供了位置透明度。
目前,我正在构建一个仅使用actor的Web框架作为业余项目。再次强调,其优点是可以将可扩展性从单台机器扩展到整个机群。此外,使用消息驱动的方法使您的软件从一开始就面向服务。您拥有所有这些美妙的组件,彼此交谈但不必然知道彼此的存在,共存于同一台机器上,甚至不在同一个数据中心。
自Google Reader关闭以来,我开始使用Akka构建RSS阅读器。对我而言,这一切都与封装的服务有关。总之:您应该首先采用actor模型,并且Akka是一个非常可靠的框架,可以帮助您实现它并获得许多好处。
我尝试使用Akka(Java api)进行测试。我试图比较Akka的基于actor的并发模型与普通Java并发模型(java.util.concurrent类)。
用例是一个简单的规范化映射减少实现字符计数。数据集是一组随机生成的字符串(长度为400个字符),并计算其中元音字母的数量。
对于Akka,我使用了BalancedDispatcher(用于在线程之间进行负载平衡)和RoundRobinRouter(用于限制函数actors的数量)。对于Java,我使用了简单的fork join技术(没有实现任何工作窃取算法),它将分叉的map/reduce执行和join结果。中间结果保存在阻塞队列中,以使连接尽可能并行。也许,如果我没有弄错的话,这在某种程度上会模仿Akka actors的"邮箱"概念,它们接收消息。
观察: 在中等负载(~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时钟速度
请注意,用于测试的问题域可能存在争议,我尽量公平。
我们正在使用带有其camel插件的akka来分布式处理twimpact.com的分析和趋势处理。我们需要每秒处理50到1000条消息。除了使用camel进行多节点处理外,还可用于在单个处理器上将工作分配给多个工作者以实现最大性能。效果相当不错,但需要一些处理拥塞的理解。