6.3 总结

你是否还记得我们在本章开始的时候，我们为什么不能扳动一个开关，使得我们的应用可以以分布式方式运行(使用remoting)? 这是因为我们需要考虑网络环境，这是我们本地版本的程序忽略的。

如你预料的，本章中我们大部分实际要做的就是考虑这些新环境，像预测的那样，Akka 将其变简单了。

虽然我们需要做一些改变，我们也有很多不需要改变：

• 我们从如下事实中受益：无论 Actor 是本地的，还是远程的，ActorRef 都是一样的。
• 分布式系统中监控死亡的监控 API 与本地系统中的完全一样。
• 虽然现在合作者被网络隔开了，通过简单地使用转发(在 RemoteLookup 和 RemoteBoxOfficeForwarder 中)，我们允许 RestInterface 和 BoxOffice 透明地相互交流。

这很重要，因为将我们的应用升一级不需要我们忘记已经学到的，或者学一堆全新的东西；基本操作大部分是一样的，这是设计良好的工具箱的特征。

我们也学到了一些新东西：

• REPL, 给我们提供了一个简单、交互的方法来让我们的东西在分布式环境中运行。
• multi-node-testkit，使得测试分布式 actor 系统极其简单，无论是用 akka-remote 构建的，还是 akka-cluster，或者两者一起。(Akka 在提供分布式环境的良好的单元测试用具方面相当独特)

我们特意没有处理消息会在后台不可用时在 RemoteLookup 和 RemoteBoxOfficeForwarder 中丢失的情况。 后面的章节中，我们会：

• 看看如何使用 Reliable Proxy 赖在对等的节点间传递消息。
• 处理 goticks 会在后台节点崩溃时丢失 TicketSellers 的状态的问题
• 状态如何在集群中复制

在这之前，我们先来在下一章中看看用 akka-cluster 模块来处理动态节点加入。