619

我听说过很多关于Akka框架（Java/Scala 服务平台）的评论，但到目前为止还没有看到很多实际的用例示例。所以我很想听听开发人员成功使用它的事情。

只有一个限制：请不要包括编写聊天服务器的情况。（为什么？因为这已被过度用作许多类似事物的示例）

4

12 回答 12

329

到目前为止，我已经在两个实际项目中非常成功地使用了它。两者都在近乎实时的交通信息领域（交通如高速公路上的汽车），分布在多个节点上，集成多方之间的消息，可靠的后端系统。我还不能自由地提供客户的具体细节，当我得到确定时，也许可以将其添加为参考。

Akka 确实在这些项目上取得了成功，即使我们从 0.7 版开始。（顺便说一下，我们正在使用 scala）

最大的优势之一是您可以轻松地用几乎没有样板的演员和消息组成一个系统，它的扩展性非常好，没有手动线程的所有复杂性，并且您几乎可以免费获得对象之间的异步消息传递。

它非常适合对任何类型的异步消息处理进行建模。我更愿意以这种风格编写任何类型的（Web）服务系统，而不是任何其他风格。（您是否曾经尝试过使用 JAX-WS 编写异步 Web 服务（服务器端）？这需要大量的工作）。所以我会说任何不想挂在其组件之一上的系统，因为一切都是使用同步方法隐式调用的，并且一个组件正在锁定某些东西。它非常稳定，让它崩溃 + 主管的失败解决方案真的很有效。一切都很容易以编程方式设置，并且不难进行单元测试。

然后是优秀的附加模块。Camel 模块确实很好地插入了 Akka，并且可以轻松开发具有可配置端点的异步服务。

我对该框架非常满意，它正在成为我们构建的连接系统的事实标准。

于 2010-12-20T22:17:33.810 回答
225

免责声明：我是 Akka 的 PO

除了提供一个更容易推理和正确的并发大杂烩（参与者、代理、数据流并发）以及 STM 形式的并发控制。

以下是您可能会考虑的一些用例：

  1. 交易处理（在线游戏、金融、统计、博彩、社交媒体、电信……）
    • 纵向扩展、横向扩展、容错/HA
  2. 服务后端（任何行业，任何应用程序）
    • 服务 REST、SOAP、cometd 等
    • 充当消息中心/集成层
    • 纵向扩展、横向扩展、容错/HA
  3. 管理单元并发/并行（任何应用程序）
    • 正确的
    • 易于使用和理解
    • 只需将 jars 添加到您现有的 JVM 项目（使用 Scala、Java、Groovy 或 JRuby）
  4. 批处理（任何行业）
    • Camel 集成以连接批处理数据源
    • Actor 分而治之的批处理工作负载
  5. 通讯枢纽（电信、网络媒体、移动媒体）
    • 纵向扩展、横向扩展、容错/HA
  6. 游戏服务器（网络游戏、博彩）
    • 纵向扩展、横向扩展、容错/HA
  7. BI/数据挖掘/通用运算
    • 纵向扩展、横向扩展、容错/HA
  8. 在此处插入其他不错的用例
于 2010-12-20T22:27:47.377 回答
80

我们如何使用它的一个例子是借记卡/信用卡交易的优先队列。我们有数百万个这样的工作，工作量取决于输入字符串类型。如果交易是 CHECK 类型，我们几乎不需要处理，但如果它是销售点，那么还有很多事情要做，例如与元数据（类别、标签、标签等）合并并提供服务（电子邮件/短信警报、欺诈检测、资金余额不足等）。基于输入类型，我们组成处理工作所需的各种特征（称为混合）类，然后执行工作。所有这些工作都以实时模式从不同的金融机构进入同一个队列。一旦数据被清理，它就会被发送到不同的数据存储以进行持久化、分析，或者推送到套接字连接或 Lift comet 演员。工作参与者不断地对工作进行自我负载平衡，以便我们可以尽可能快地处理数据。我们还可以嵌入额外的服务、持久性模型和用于关键决策点。

在 JVM 上传递的 Erlang OTP 风格的消息为在现有库和应用程序服务器的肩膀上开发实时系统提供了一个很好的系统。

Akka 允许您像在传统中一样快速地进行消息传递！它还为您提供框架中的工具来管理解决方案所需的大量参与者池、远程节点和容错。

于 2010-12-20T22:16:26.000 回答
47

我们使用 Akka 异步处理 REST 调用 - 与异步 Web 服务器（基于 Netty）一起，与传统的每个用户请求线程模型相比，我们可以将每个节点/服务器服务的用户数量提高 10 倍。

告诉你的老板，你的 AWS 托管费用将下降 10 倍，这很容易！嘘......虽然不要告诉亚马逊...... :)

于 2012-11-17T15:10:51.110 回答
39

我们在一个大型电信项目中使用 Akka（很遗憾我不能透露很多细节）。Akka actor 由 Web 应用程序远程部署和访问。这样，我们就有了一个基于 Google protobuffer 的简化 RPC 模型，并使用 Akka Futures 实现了并行性。到目前为止，该模型运行良好。注意：我们使用的是 Java API。

于 2010-12-21T12:34:13.890 回答
38

如果您将聊天服务器抽象到一个级别，那么您就会得到答案。

Akka 提供了一个类似于 Erlang 的“让它崩溃”心态的消息系统。

因此，示例是需要不同级别的消息传递的持久性和可靠性的事物：

  • 聊天服务器
  • MMO 的网络层
  • 金融数据泵
  • iPhone/手机/任何应用程序的通知系统
  • REST 服务器
  • 也许类似于 WebMachine 的东西（猜测）

Akka 的优点在于它为持久性、STM 实现、REST 服务器和容错提供了多种选择。

不要对聊天服务器的示例感到恼火，将其视为某类解决方案的示例。

凭借他们所有出色的文档，我觉得这个确切的问题、用例和示例之间存在差距。请记住，这些示例并非微不足道。

（写的只有看视频和玩源码的经验，我没有用akka实现过。）

于 2010-12-20T21:54:08.840 回答
25

您可以将 Akka 用于多种不同的事情。

我在一个网站上工作，在那里我将技术堆栈迁移到了 Scala 和 Akka。我们几乎将它用于网站上发生的所有事情。即使您可能认为 Chat 示例不好，但基本上都是一样的：

  • 网站上的实时更新（例如浏览量、喜欢的...）
  • 显示实时用户评论
  • 通知服务
  • 搜索和所有其他类型的服务

尤其是实时更新很容易，因为它们归结为聊天示例。服务部分是另一个有趣的话题，因为您可以简单地选择使用远程参与者，即使您的应用程序没有集群，您也可以轻松地将其部署到不同的机器上。

我还将 Akka 用于 PCB 自动布线器应用程序，其想法是能够从笔记本电脑扩展到数据中心。你给它的权力越大，结果就会越好。如果您尝试使用通常的并发性，这将非常难以实现，因为 Akka 还为您提供了位置透明性。

目前作为一个空闲时间项目，我正在构建一个仅使用演员的 Web 框架。同样的好处是从单台机器到整个机器集群的可扩展性。此外，使用消息驱动的方法使您的软件从一开始就面向服务。您拥有所有这些不错的组件，彼此交谈但不一定彼此了解，生活在同一台机器上，甚至不在同一个数据中心。

自从 Google Reader 关闭后，我开始使用 RSS 阅读器，当然是使用 Akka。对我来说，这都是关于封装服务的。结论：actor 模型本身是您应该首先采用的，Akka 是一个非常可靠的框架，可以帮助您实现它，并在此过程中获得很多好处。

于 2013-08-09T12:00:32.807 回答
25

我们在工作中的几个项目中使用 Akka，其中最有趣的是与车辆碰撞修复有关。主要在英国，但现在扩展到美国、亚洲、大洋洲和欧洲。我们使用参与者来确保实时提供碰撞修复信息，以实现安全且具有成本效益的车辆维修。

Akka 的问题实际上更多是“你不能用 Akka 做什么”。它与强大的框架集成的能力、强大的抽象和所有容错方面使其成为一个非常全面的工具包。

于 2010-12-21T15:55:13.013 回答
18

We are using akka with its camel plugin to distribute our analysis and trending processing for twimpact.com. We have to process between 50 and 1000 messages per second. In addition to multi-node processing with camel it is also used to distribute work on a single processor to multiple workers for maximum performance. Works quite well, but requires some understanding of how to handle congestions.

于 2010-12-21T13:10:04.873 回答
18

我正在尝试使用 Akka（Java api）。我尝试将 Akka 基于 actor 的并发模型与普通 Java 并发模型（java.util.concurrent 类）进行比较。

用例是字符计数的简单规范映射减少实现。数据集是随机生成的字符串（长度为 400 个字符）的集合，并计算其中的元音数。

对于 Akka，我使用了 BalancedDispatcher（用于线程之间的负载平衡）和 RoundRobinRouter（以限制我的函数 actor）。对于 Java，我使用了简单的 fork join 技术（在没有任何工作窃取算法的情况下实现），它将 fork map/reduce 执行并连接结果。中间结果保存在阻塞队列中，以使连接尽可能并行。如果我没记错的话，这可能会以某种方式模仿 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 知识允许 :-)

于 2012-06-21T20:37:53.247 回答
17

我们在口语对话系统（primetalk）中使用 Akka。无论是对内还是对外。为了在单个集群节点上同时运行大量电话通道，显然需要一些多线程框架。Akka 工作得非常完美。我们以前对 java-concurrency 有过噩梦。使用 Akka，它就像一个秋千——它很简单。坚固可靠。24*7，不间断。

在通道内，我们有并行处理的实时事件流。特别是： - 冗长的自动语音识别——由演员完成；- 混合几个音频源（包括合成语音）的音频输出生产者；- 文本到语音的转换是在频道之间共享的一组单独的参与者；- 语义和知识处理。

为了实现复杂信号处理的互连，我们使用SynapseGrid。它具有在复杂参与者系统中对 DataFlow 进行编译时检查的好处。

于 2013-08-09T07:36:21.007 回答
15

我最近在 Akka 中实现了规范的 map-reduce 示例：字数。所以这是 Akka 的一个用例：更好的性能。这更像是对JRuby 和 Akka 演员的一次实验，但它也表明 Akka 不仅仅是 Scala 或 Java：它适用于 JVM 之上的所有语言。

于 2010-12-21T12:48:01.730 回答