位置透明性

上一节讲到了如何使用actor路径来实现位置透明性。这个特殊的功能需要额外的解释，因为“透明远程调用”在不同的上下文中（编程语言，平台，技术）有非常不同的用法。

默认是分布式

Akka中所有的东西都是被设计成在分布式的环境中工作的：actor之间的所有互操作使用纯粹的消息传递机制，所有的操作都是异步的。付出这些努力是为了保证所有功能无论是在单一的JVM上还是在很多机器的集群里都能同样工作。实现这一点的要点是从远程到本地进行优化而不是从本地到远程进行一般化。参阅这篇经典论文来了解关于为什么第二种方式注定要失败的讨论。

透明性会被破坏的方式

由于设计分布式执行对可以做的事情添加了一些限制，Akka所满足的在使用akka的应用程序中并不一定也满足。最明显的一条是网络上发送的所有消息必须是可序列化的。而不那么明显的是这也包括在远程节点上创建actor时用作actor工厂的闭包（在Props里）。

另一个结果是所有元素都需要知道所有交互是完全异步的，在一个计算机网络中这可能意味着一个消息需要好几分钟才能到达接收方（跟配置有关）。还意味着消息丢失的概率比在单一的jvm中（接近0，但仍不能完全保证！）高得多。

远程调用如何使用？

我们把透明性的想法限制在“Akka中几乎没有为远程调用层设计的API”：而完全由配置来驱动。你只需要按照之前的章节概括的那些原则来编写你的应用，然后在配置文件里指定远程部署的actor子树。这样你的应用可以不用修改代码而进行扩展。API中唯一允许编程来影响远程部署的部分是Props包含一个属性，这个属性可能被设为一个特定的 Deploy 实例；这与在配置文件中放置同样的部署具有相同的效果（如果两者都有，那么配置文件优先）。

Peer-to-Peer vs. Client-Server

Akka remoting是一个通讯模型，它通过点到点风格连接actor系统。它是Akka集群的基础。remoting的设计是通过下面两个决定驱动的：

• 相互通讯的系统是对称的。如果系统A可以连接到系统B，那么系统B也可以连接到系统A
• 通讯的系统关于连接模式的角色是对称的。没有系统仅仅接受连接，没有系统仅仅发起连接

这些决定的结果是，不可能安全的通过预先确定的角色(违反条件2)创建纯client-server setups，并让setups处理网络地址转换或者负责均衡(违法条件1)

使用路由来进行垂直扩展的标记点

除了可以在集群中的不同节点上运行一个actor系统的不同部分，还可以通过并行增加actor子树的方法来垂直扩展到多个cpu核上。新增出来的子树可以使用不同的方法来进行路由，如循环。要达到这种效果，开发者只需要声明一个“withRouter”的actor，这样创建出来的actor会生成一些具有所期望的类型的数目可配置的子actor，并使用所配置的方式来对这些子actor进行路由。一旦声明了这样的路由，它的配置可以自由地对配置文件里的配置进行重写，包括把它与其(某些)子actor的远程部署进行混合。