位置透明
上一节描述了如何使用 Actor 路径来启用位置透明（location transparency）。这个特殊的特性需要一些额外的解释，因为在编程语言、平台和技术的上下文中，相关术语“透明远程处理（transparent remoting）”的使用方式非常不同。
默认分布
Akka 中的所有内容都设计成在分布式环境中工作：Actor 的所有交互都使用纯消息传递，而所有内容都是异步的。这项工作的目的是确保在单个 JVM 中或在成百上千台机器的集群上运行时，所有功能都可以平等地使用。实现这一点的关键是通过优化从远程到本地，而不是通过泛化从本地到远程。有关第二种方法必然失败的原因的详细讨论，请参阅这篇「经典」文章。
打破透明的方法
Akka 的真实情况不必是使用它的应用程序的真实情况，因为分布式执行的设计对可能的情况有一些限制。最明显的一点是，通过线路发送的所有消息都必须是可序列化的。虽然不太明显，但如果要在远程节点上创建 Actor，则包含用作 Actor 工厂（即在Props中）的闭包。
另一个后果是，每件事都需要意识到所有的交互都是完全异步的，在计算机网络中，这可能意味着消息到达收件人可能需要几分钟时间（取决于配置）。这还意味着消息丢失的概率要比一个 JVM 中的高很多，在同一个 JVM 中，它接近于零，但仍然是：没有硬保证！
如何使用远程处理？
我们将透明的概念限制在几乎没有用于 Akka 远程处理层的 API：它纯粹是由配置驱动的。只需根据前面几节中概述的原则编写应用程序，然后在配置文件中指定 Actor 子树的远程部署。这样，你的应用程序就可以在不需要触摸代码的情况下进行扩展。API 中唯一允许对远程部署产生编程影响的部分是，Props包含一个可以设置为特定Deploy实例的字段；这与将等效部署放入配置文件（如果两者都给出，则配置文件获胜）的效果相同。
Peer-to-Peer vs. Client-Server
Akka 远程处理是一种以对等（peer-to-peer，或者称之为“点对点”）方式连接 Actor 系统的通信模块，是 Akka 集群的基础。远程处理的设计由两个（相关的）设计决策驱动：
- 所涉及系统之间的通信是对称的：如果系统 A 可以连接到系统 B，那么系统 B 也必须能够独立地连接到系统 A。
- 就连接模式而言，通信系统的角色是对称的：没有只接受连接的系统，也没有只启动连接的系统。
这些决策的结果是不可能安全地创建具有预定义角色的纯客户机-服务器（client-server）设置（违反假设 2）。对于客户机-服务器设置，最好使用 HTTP 或 Akka I/O。
重要提示：使用涉及网络地址转换的设置、负载均衡器或 Docker 容器违反假设 1，除非在网络配置中采取其他步骤以允许相关系统之间的对称通信。在这种情况下，可以将 Akka 配置为绑定到不同于用于在 Akka 节点之间建立连接的网络地址。详见「 Akka behind NAT or in a Docker container」。
用路由器扩容标记点
除了能够在集群的不同节点上运行 Actor 系统的不同部分之外，还可以通过将支持并行化的 Actor 子树（例如，搜索引擎并行处理不同的查询）相乘，扩展到更多的核心。然后，克隆可以以不同的方式被路由到，例如循环。实现这一点的唯一必要的是，开发人员需要将某个 Actor 声明为withRouter，然后取而代之的是，将创建一个路由器 Actor，该 Actor 将生成所需类型的可配置子级，并以配置的方式路由到这些子级。一旦声明了这样的路由器，就可以从配置文件中自由地覆盖其配置，包括将其与（部分）子级的远程部署混合在一起。在「Routing」中可以阅读更多关于此的信息。
英文原文链接：Location Transparency.
