Akka官方文档2.5.17（五）——位置透明性

目录

默认分布式

透明性被打破的方式

怎样使用路由

P2P vs C-S

采用路由纵向扩展

---

前面章节描述了怎样使用Actor路径使得位置透明性成为可能。这个特殊的功能值得一些额外的解释，因为相关的术语“透明远程处理”在编程语言、平台和技术的上下文中差异巨大。

默认分布式

Akka里的所有东西都被设计为可以在分布式环境中工作：Actors之间的所有交互都使用纯粹的消息传递，而且一切都以异步方式完成。这样做旨在确保所有的功能在单个JVM或者数百台的集群机器上都可用。The key for enabling this is to go from remote to local by way of optimization instead of trying to go from local to remote by way of generalization. See this classic paper for a detailed discussion on why the second approach is bound to fail.

透明性被打破的方式

在某些情况Akka不一定适用于使用它的应用程序，因为设计为分布式的执行对可能做的事情提出了一些限制。最明显的一点是，所有通过线路传递的消息必须是序列化的。虽然不太明显，这也包括在远程节点创建Actor时使用的Actor工厂方法(Props)。

另一个结果是，应该意识到一切操作都是完全异步执行的。这在计算机网络中意味着消息可能需要几分钟才能到达目的地(取决于配置)。同样表明消息丢失的概率远远高于一个JVM内的消息传递(接近于0，但不完全保证)。

怎样使用路由

我们把透明性的想法做到了极致，从而使得Akka的远程处理几乎没有API：完全采用配置驱动。只需根据前面章节中概述的原则编写应用程序，然后在配置文件中指定Actor的远程部署方式。这样，你的应用程序可以横向扩展而不需要修改代码。API中唯一允许对远程部署通过编程影响的地方是Props中的一个字段，该字段可以设置一个特定的Deploy实例；这与将相同的部署放入配置文件中具有同样的效果(配置文件的优先级高于编程方式，会覆盖编程的deploy实例)。

P2P vs C-S

Akka remoting是以P2P方式连接Actor系统的通信模块，而且是Akka Clustering的基础。remoting的设计由两个相关的设计决策驱动：

1. 系统之间的通信是对等的：如果系统A能够连接到系统B，那么系统B一定能够独立的连接到系统A
2. 不管连接的方式如何，通信系统的角色是对称的：没有系统只接受连接，并且没有系统只启动连接

这一系列决策的结果是无法安全的创建具有预定义角色的C-S的设置(违反决策2)。对于C-S方式，最好使用HTTP或者Akka I/O。

重要提示：使用NAT(网络地址转换)、负载均衡、或者Docker容器违反了决策1，除非在网络配置中采取其他步骤以允许所涉及系统之间的对称通信。在这种情况下，可以配置Akka绑定到用于在Akka节点之间建立连接的网络地址外的不同网络地址。参见Akka在NAT和Docker容器中的使用。

采用路由纵向扩展

除了能够在集群的不同节点上运行Actor系统的不同部分之外，还可以通过支持并行化来进行纵向扩展(例如，搜索引擎并行处理不同的查询)，然后可以以不同的方式路由，如round-robin。实现这一点的唯一必要条件是开发人员需要将某个Actor混入“Router”，这将创建一个路由Actor，它将根据配置创建所需类型的子节点并路由到它们。然后一个路由Actor将会被创建，该路由Actor将生成可配置数量的所需类型的子节点，并以配置的方式路由到它们。一旦声明了这样的路由，就可以在配置文件中自由覆盖其配置，包括将其与（某些）远程部署的子节点混合。 参见routing。