带Typesafe的赌注让我进入了Akka大厦

返回绘图板：在Akka Streams，Akka HTTP和Akka Typed的路上丢失的代码行

如果您曾经对如何开发新的核心功能以及为什么喜欢的技术走在特定的道路上感到好奇，那么您来对地方了。 在Takipi博客上的新设计决策系列中，您将发现每天使用的工具和框架背后的驱动力。 您将看到是什么使它们打勾，齿轮如何安装，与所有这些代码行背后的开发人员会面，并有机会介入并提出您想回答的棘手问题。

新帖：带Typesafe的赌注让我进入了Akka大厦http://t.co/yqtpFahIMB pic.twitter.com/H5oTlhD9Uz

— Takipi（@takipid） 2015年5月11日

在第一次采访中，我们与Typesafe的Akka技术负责人Roland Kuhn博士进行了接触，以深入了解Akka背后的工作。 在Typesafe，Kuhn和团队负责决定下一步要使用框架，新操作的语义以及确定要解决的问题的正确答案。 一个鲜为人知的事实是，罗兰（Roland）在2011年1月1.0版发布之前就成为Akka的核心贡献者。圣诞节期间，他向维克多·巴生（Viktor Klang）建议，他现在是Typesafe的副CTO，他对CallingThreadDispatcher的想法得到了回应 ，他回答道：您将无法做到–我挑战您写一个！” –就是这样 。 Roland说：“从事开源项目一直是我的梦想，因为我不知道要花多长时间。”

从左到右：Konrad Malawski，MartynasMickevičius，Roland Kuhn，EndreSándorVarga和Patrik Nordwall。

Akka团队由5名开发人员组成，加入的唯一前提是您需要进入或搬到欧洲。 尽管是分散的团队，但他们定期开会并停留在几乎相同的时区。 但这还不是全部，因为在Akka的情况下，社区也发挥着重要作用，并且可能是创建框架的最大动机。

Akka解决方案是分布式计算的问题

“ Actor模型被描述为并发构造； 但这是一个非常狭窄的观点。”罗兰德说。 “实际上是关于分销。 独立的分布式代理使用消息进行通信，而这正是我们关注的焦点– Akka的所有业务均针对此。 您可以在单个进程中运行应用程序，并且如果需要，可以在包含数千个节点的群集中运行它。 我们内置的所有功能都围绕着使演员能够做某事”。

“我们始终牢记的首要问题是保持模型的简洁和简洁。 因此，通常定义的易用性不是我们的主要驱动因素。 我们的观点是，我们需要公开所建模领域的本质复杂性。 就分布式计算而言，这意味着，如果您真的想编写一个分布式应用程序，则必须了解这意味着什么，Akka不会把这方面的事情带给您。 我们要做的是提供一个抽象，在这种情况下是一个Actor，它提取了要分发的含义的实质，然后才起作用。 您将消息发送给Actor，无论接收者位于群集中的何处，该消息都会传递给该Actor。

“我们坚信使用正确的工具来完成工作，因此我们尝试构建简单易懂的东西，但是您必须愿意考虑使用的东西。 即使在性能上付出一点点代价，它也必须在所有情况下都不会妥协地工作。 在这些限制条件下，我们仍将尽力使其尽快”。

在决定使用Akka Streams之前，已经丢弃了6个版本

“我们让自己受到社区的指导，但这不是全部真理，因为有时我们只需要向前走几步，然后有人会跟随并验证，或者，好吧，告诉我们我们的问题是什么想法。 例如，在我们的邮件列表中看到使用Akka的开发人员通常会遇到两种问题之后，便想到了Akka Streams。

1.他们将消息从一个Actor发送到另一个Actor，而接收方的Actor具有不受限制的邮箱，因此他们不应对背压或根本不在乎它，然后邮箱会不受约束地增长，直到出现OutOfMemoryError 。 因此，您需要在此处实现的模式是流控制。

2.演员目前没有像我喜欢的那样被“有用地键入”，而是单类型的。 您可以将任何消息发送给任何演员。 我们正在努力改变这种状况，我认为我们很有可能成功完成Akka Typed项目。 但是与此同时，它具有很大的自由度，因此您可以用它来建模任何消息传递模式。”

“ Akka Streams基本上是社区要求它的东西”

“因此，我们已经看到了这些问题，我们认为，好吧，我们将其打包并创建一个可以解决这些问题的抽象，即Akka Streams。 我们认为它必须产生反压力，它一定不能耗尽内存，并且应该正确地进行类型检查，然后进行整个设置。 这些都是模糊的约束，这解释了为什么我们花了1.5年的时间进行实验，建立新的解决方案并把它扔掉，我认为这是至少六次了，至少那是我停止计数之前，我们决定采用现在认为会成功的设计。”

Akka流的状态：它们准备好进行生产了吗？

Akka流被设计为解决流处理问题的通用解决方案。 它们使您可以描述任何类型的数据流，对各种组合进行建模，不仅依赖于诸如map或filter之类的转换，而且还可以修改元素流动的速率。 这意味着，如果输入速度太快或外推，则可以将多个元素合并为一个元素，或者将一个元素转换为多个元素。 更多操作包括对结点建模，以便您可以合并或路由到多个目的地。

此外，罗兰说：“我们会尽力做到最好和彻底。 因此代码应该可以工作，但是它仍然是开发分支，因此存在错误，但是人们已经在生产系统中使用它了。 它解决了这些背压问题，并具有更多的类型安全性，并且人们真的很饿，所以这就是他们甚至使用这些开发预览的原因。 我们的目标是即将发布的版本来满足这一需求。”

“基于Akka Streams，我们正在重新设想应该如何处理HTTP”

路线图上的下一件事是Akka HTTP。 传统上，HTTP是经过处理的，因此请求是一个对象，而响应是另一个对象。 您收到一个请求，然后生成一个响应，该响应传递回HTTP层并返回给客户端。 根据Roland所说，这已经成为一种古老的处理方式：“越来越明显的是，您不仅要交换小的请求和响应对，而且有时您只想上传或下载几GB的数据，不太适合此模型。 由于我们是从头开始的，因此Akka HTTP完全基于Akka Streams构建。 因此，当您在Akka HTTP中收到HTTP请求时，它实际上是一个字节串流，您可以对其进行组合，转换，将其传递到其他服务器或文件，而不必在内存中保留字节。 我认为这是我们要添加的新事物，我们进行了完全流化的HTTP处理”。

Akka Typed –可行的解决方案不一定是正确的解决方案

Akka路线图上的另一个项目是Akka Typed ，使类型检查可用于Actor交互。 罗兰（Roland）在Akka 1.2中开始尝试通过在渠道抽象下统一Futures和ActorRefs来开始这一工作：“那实际上没有用，我删除了它。 然后，当Scala宏问世时，我们创建了另一个可行的实现，但并没有真正成功，因为宏是一种实验性功能，许多人不敢在商业产品中使用它。 因此，这就是为什么也删除了“类型化通道”的原因。 他们工作了，但是太复杂了，所以实验失败了。 看到这些失败之后，我最终放弃并简化了整个提案，删除了我们实施的Actor模型的Akka功能，这些功能根本不在原始模型中。”

“ Akka Typed将成为我们下一版本的一部分–比平常的预览模式更具实验性。 这将需要很长时间才能被称为稳定”。

“现在，它不是某种类型的T的ActorRef，而是ActorRef的替代品，您不能向该ActorRef发送除T类型的消息以外的其他消息。 这是基本的变化，但在幕后却发生了很大变化。 我不确定何时或是否要删除未类型化的Actor，他们可能会并排居住很长一段时间，我们都会尝试Akka Typed并等待社区的反馈，看看它应该去哪里。”

环聊自拍！

“我们尚未完全解决的一件事是Akka Persistence ，它仍然具有实验性标记。 根据社区的意见，我们得出的结论是，我们需要先发布Akka Streams，然后才能在Akka持久性中使用它们。 这也是我们今年还将努力的事情。” 我们还询问是否有其他修补程序等待引入Akka：

“我们在设计中犯了一些错误，现在这些错误基本上无法解决，因为它们破坏了所有代码”。

“其中之一是，您可以调用System.ActorOf并同步获取ActorRef。 这不是为支持该功能而编写的代码所应有的方式。 这真的很微妙，太复杂了。 由于我们无法真正删除System.ActorOf，因此我们计划对此进行修改的方法是不将其包含在Akka Typed中。 在Akka Typed中，有一种新型的Actor系统，可以达到相同的目的，但不再具有ActorOf。 然后，我的狡猾计划是将其提供给社区，并向社区展示，看看是否有人尖叫：“我需要我的系统负责人！”。

“有趣的是，通过所有这些更改，我们正在删除在原始Actor模型之上添加的方面。 因此，我们正在进行压缩，我们将比以前更接近Actor模型。”

“我们继续受到早期思想的启发，因此卡尔·休伊特 （ Carl Hewitt ）在'73所写的内容仍然准确无误，我们得以实现，而且我们也受到计算机科学理论方面最新进展的启发。 例如，CRDT（无冲突复制数据类型 ）非常有趣。 在实施Akka集群时，我们碰巧碰到过一次，在描述它们的论文实际发表之前，我们实现了自己的CRDT，我认为我们也将继续致力于该主题。”

关于与Scala一起支持Java，Roland表示：“我们的总体理念是，我们在同一对象上同时提供Java和Scala API。 我们所做的一切都可以从Java和Scala上同样出色地工作，我们尝试提供相同的功能。

大规模调试演员–世界现已分布，您无法阻止它

附加调试器，达到断点，然后停止运行的旧方案不再起作用：“在检查数据时，其他系统将在运行，超时通常会触发，并且开发人员在调试器下的行为将与您在生产中实际尝试理解的有很大不同。 这就是为什么要调试任何类型的反应式系统，您都需要依赖实时系统上的跟踪，监视和记录。 您无法在开发环境中放置断点并查看正在发生的事情，因为通常不会告诉您您需要知道什么。

如何调试分布式系统？

大型生产环境每天可能在代码中的数百个不同位置产生数百万个错误。 尽管有些错误可能是微不足道的，但有些错误会破坏关键功能并影响最终用户，而您可能并不了解。 传统上，要识别和解决这些错误，您甚至必须依靠日志文件或日志管理工具来知道发生了错误，更不用说如何解决了。 但是...如果要调试Scala或Java应用程序，则情况会有所不同。 通过在监视堆栈中使用Takipi，您可以检测到已捕获和未捕获的异常，Actor和日志错误，并查看导致它们的代码和变量状态。 您可以在这里查看 。

最后，我们要感谢罗兰（Roland）加入我们的这次采访，希望您发现它和我们一样有趣！ 无疑这是一个有趣的旅程，我们希望您能更好地了解Akka的工作方式，其基础以及在我们讲话时不断塑造它的力量。 从跟踪Scala邮件列表中的消息到成为Akka的技术主管并实现他从事开源项目的梦想，了解Roland的旅程也很棒。 想到这一旅程将如何继续下去以及下一步将把我们带到何方，真是令人兴奋。

如果您还有其他问题或想清除本采访中未涵盖的一些主题，请随时在下面的评论部分中发表您的问题。

翻译自: https://www.javacodegeeks.com/2015/05/the-bet-with-typesafe-that-got-me-into-building-akka.html