2.6 位置透明性
前一章节描述了如何使用角色路径来实现位置透明性。这一个特性应该需要一些额外的说明，因为与之关联的术语“transparent remoting”（透明的远程处理）在编程语言、平台和技术中的用法是不一样的。
2.6.1 默认分布式
Akka中的所有事物被设计成用于分布式环境中：角色之间的交流都是纯信息传递，并且是同步的。这一成就已经被用于确保所有的功能在单个JVM或者在拥有数以百计的机器的集群中运行都同样有效。实现这一功能的关键在于从远程到本地的优化代替试图从本地到远程的范化。关于第二种方式注定要失败的详细讨论请访问this classic paper
2.6.2 透明方式被打破
对Akka适用的，不一定适用于使用它的应用，因为设计分布式执行会带来一些限制。最明显的一点就是所有通过电缆发送的消息都必须可序列化。虽然有一点不太明显的就是包括闭包在内的远程角色工厂，用来在远程节点创建角色（即Props内部）。
另一个结论是，要意识到所有交互都是完全异步的，它意味着在一个计算机网络中一条消息需要几分钟才能到达接收者那里（基于配置），而且可能比在单JVM中有更高丢失率，后者丢失率接近于0（还没有确凿的证据）。
2.6.3 如何远程使用？
我们持透明性的观点的限制是几乎没有关于Akka远程处理层的API：它纯粹是配置驱动的。根据前面章节讲述的原则去编写你的应用，然后在配置文件中指定角色子树的远程部署。你的应用可以用这种方式在不需要改动代码的情况下实现横向扩展。唯一的允许通过编程影响远程部署的API是Props，Props可以指定Deploy实例的属性，这种方式等同于通过配置文件部署（如果两种方式都用了，会以配置文件优先）。
2.6.4 点对点 VS 客户端-服务器端
Akka远程处理是一个在点对点模式下用来连接角色系统的通讯模块，而它是Akka集群的基础。远程处理是通过两个设计决策（相关的）作为导向来设计的：
- 相关系统之间的通信是对等的：如果一个系统A可以连接到系统B，那么系统B也一定可以独立的连接到系统A。
- 关于连接模式，通信系统的地位是对等的：没有一个系统是只能接受连接，也没有一个系统只能发起连接。
通过这些决策我们知道是不可能通过预定义角色（审校者注：原文为role，而不是文档通常出现的Actor）（违反假设1）和涉及网络地址转换或负载平衡器的设置（违反假设2）来安全的创建纯粹的client-server设置。
client-server的设置最好使用HTTP或者Akka I/O。
2.6.5 利用路由器纵向扩展标记点
除了能够在集群的不同节点上运行角色系统的不同部分，还可以通过支持并行的多角色子树扩展到更多的内核（想象成一个搜索引擎可以并行的处理不同的查询）。克隆可以不同的方式路由，例如轮询。唯一要做的就是开发人员需要声明一个特定的角色“withRouter”，然后，将会创建一个路由角色，该角色将产生许多可配置的期望类型的子角色并以配置指定的方式路由到它们。一旦声明了这样的一个路由器，它的配置可以*的用配置文件覆盖，还可以与远程部署（的一些）子角色混合。更多内容请见Routing(Scala)和Routing(Java)。