Artery Remoting

留神
近程解决是一种机制，通过这种机制，不同节点上的 Actor 能够互相通信。
在构建 Akka 应用程序时，通常不会间接应用 Remoting 概念，而会应用更高级的 Akka Cluster 实用程序或与技术无关的协定，例如 HTTP，gRPC 等。

依赖

要应用 Artery Remoting，必须在我的项目中增加以下依赖项：

Artery UDP 依赖 Aeron。如果应用 aeron-udp，则须要将其显式增加为依赖项，未应用 Artery Remoting 的用户的类门路上没有 Aeron：

如果要从 classic remoting 迁徙，请查看 Artery 的新性能

配置

要在 Akka 我的项目中启用近程性能，您至多应将以下更改增加到 application.conf 文件中：

如您在下面的示例中看到的，开始须要增加四件事：

• 批改 local provider。与间接应用近程解决相比，咱们倡议应用 Akka 集群。
• 启用 Artery，能够将其用作近程施行
• 增加主机名 - 您要在其上运行 actor 零碎的机器；该主机名正是传递给近程零碎以辨认该零碎的名称，因而在须要时可用于连贯该零碎，因而将其设置为可拜访的 IP 地址或可解析的名称，万一您想通过网络进行通信。
• 增加端口号 -actor 零碎应侦听的端口，设置为 0，以主动设置端口号

留神
即便 actor 零碎具备不同的名称，端口号对于同一台机器上的每个 actor 零碎也必须是惟一的。这是因为每个 actor 零碎都有本人的网络子系统，监听连贯并解决音讯，免得烦扰其余 actor 零碎。

下面的示例仅阐明了必须增加能力启用近程解决的起码属性。所有设置在 ” 近程配置 ” 中形容。

介绍

咱们倡议 Akka Cluster 优于间接应用近程解决。因为近程解决是反对集群的根底模块，因而理解无关它的细节依然很有用。

留神
本页形容了 Artery 近程子系统，该子系统已代替了经典的近程实现。

近程解决使不同主机或 JVM 上的 Actor 零碎可能互相通信。通过启用近程解决，零碎将开始侦听指定的网络地址，并且还具备通过网络连接到其余零碎的能力。从应用程序的角度来看，本地零碎或近程零碎之间没有 API 区别，指向近程零碎的 ActorRef 实例看起来与本地零碎完全相同：它们能够被发送音讯，被监督等。每个 ActorRef 都蕴含主机名和端口信息，即便在网络上也能够传递 ActorRef。这意味着在网络上，每个 ActorRef 都是该网络上的 actor 的惟一标识符。

您须要为 actor 音讯启用序列化。在许多状况下，应用 Jackson 进行序列化是一个不错的抉择，如果您没有其余抉择，咱们建议您这样做。

近程解决不是服务器 - 客户端技术。如果所有应用近程解决的零碎都具备指向该零碎的 ActorRef，则它们能够分割网络上的任何其余零碎。这意味着启用了近程性能的每个零碎都充当 ” 服务器 ”，同一网络上的任意零碎都能够连贯到该服务器。

抉择传输协定

有三种应用根底传输的办法。它由属性 akka.remote.artery.transport 配置，可能的值是：

• tcp- 基于 Akka Streams TCP(如果未配置其余则为默认值)
• tls-tcp- 与 tcp 雷同，应用 Akka Streams TLS 加密
• aeron-udp- 基于 Aeron(UDP)

如果不确定如何抉择，最好应用默认值 tcp。

Aeron(UDP)传输是一种高性能传输，利用于须要高吞吐量和低提早的零碎。当零碎处于闲暇状态或音讯速率较低时，它比 TCP 应用更多的 CPU。Aeron 没有加密。

TCP 和 TLS 传输是应用 Akka Streams TCP/TLS 实现的。这是须要加密时的抉择，但也能够与不带 TLS 的纯 TCP 一起应用。当无奈应用 UDP 时，这也是不言而喻的抉择。它具备十分好的性能(高吞吐量和低提早)，然而高吞吐量下的提早可能不如 Aeron Transport。与 Aeron Transport 相比，它的操作复杂度更低，并且在容器环境中产生故障的危险也更低。

Aeron 要求 64 位 JVM 牢靠地工作，并且只正式反对 Linux，Mac 和 Windows。它可能在其余 Unix 上如 Solaris 运行，但尚未进行充沛的测试以使其失去正式反对。如果您应用的是 Big Endian 处理器(例如 Sparc)，则倡议应用 TCP。

留神
从一种传输方式更改为另一种传输方式时，不反对滚动更新。

从经典近程迁徙

查阅 migrating from classic remoting

规范地址

为了使近程失常工作，每个零碎都能够将音讯发送到同一网络上的任何其余零碎 (例如，零碎将音讯转发到第三个零碎，第三个零碎间接回答给发件人零碎)，每个零碎具备惟一的，寰球可拜访的地址和端口。该地址是零碎惟一名称的一部分，其余零碎将应用该地址关上与该地址的连贯并发送音讯。这意味着，如果主机具备多个名称(指向雷同 IP 地址的不同 DNS 记录)，则只有一个能够是规范名称。如果音讯达到零碎，但蕴含的主机名与预期的规范名称不同，则该音讯将被抛弃。如果容许应用一个零碎的多个名称，则将不再信赖 ActorRef 实例之间的相等性查看，这将违反一个基本前提，即一个 actor 在给定网络上具备全局惟一援用。这也意味着本地地址(例如 127.0.0.1) 不能被广泛应用(除了本地开发)，因为它们不是实在网络中的惟一地址。

在应用网络地址转换 (NAT) 或波及其余网络桥接的状况下，为了监听连贯，配置零碎以使其理解内部可见的标准地址与主机端口对之间存在差别。无关详细信息，请参阅 Akka behind NAT or in a Docker container。

获取对近程 actor 的援用

为了与 actor 进行交换，必须领有其 ActorRef。在本地状况下，通常是 actor 的创建者 (actorOf() 的调用者)为该 actor 获取 ActorRef，而后将其发送给其余 actor。换一种说法：

• Actor 能够通过接管来自近程 Actor 的音讯 (因为该音讯能够通过 getSender() 取得)或在近程音讯外部 (例如 PleaseReply(message: String, remoteActorRef: ActorRef)) 取得近程 Actor 的援用。

或者，actor 能够应用 ActorSelection 查找位于已知门路的另一个 actor。这些办法甚至在启用近程的零碎中也可用：

• 近程查找：用于应用 actorSelection(path)在近程节点上查找 actor
• 近程创立：用于在具备 actorOf(Props(…)，actorName)的近程节点上创立 actor

在下一节中，将具体介绍这两种抉择。

查找近程 actor

actorSelection(path)将取得一个 ActorSelection 到近程节点上的 Actor，例如：

从下面的示例中能够看到，以下模式用于在近程节点上查找 actor：

留神
与晚期的近程解决不同，协定字段始终为 akka，因为不再反对可插拔传输。

抉择 actor 后，您能够应用与本地 actor 雷同的形式与之交互，例如：

要为 ActorSelection 获取 ActorRef，您须要向 selection 发送一条音讯，并应用来自 actor 的回复的发送者援用。有一个内置的标识音讯，所有 Actor 都会了解该音讯，并主动通过蕴含 ActorRef 的 ActorIdentity 音讯进行回复。也能够应用 ActorSelection 的 resolveOne 办法来实现，该办法返回匹配的 ActorRef 的 Future。

无关 Actor 地址和门路的造成和应用形式的更多详细信息，请参阅 Actor 参考，门路和地址。

留神
不会通过近程 actor ref 提供程序，向发送 actor 零碎中的 actor 的发送音讯。它们是由本地 actor 援用提供者间接交付的。
除了提供更好的性能外，这还意味着，如果无奈在完全相同的 actor 零碎中解析您配置的监听主机名，则能够 (兴许违反直觉) 传递此类音讯。

近程平安

ActorSystem 不应通过 Akka Remote(Artery)通过一般的 Aeron/UDP 或 TCP 裸露给不受信赖的网络 (例如 Internet)。它应该受到网络安全性(例如防火墙) 的爱护。如果没有足够的爱护，则应启用具备双向身份验证的 TLS。

最佳实际是 Akka 近程解决节点只能从相邻网络拜访。请留神，如果通过互相身份验证启用了 TLS，则攻击者仍有可能通过应用由同一外部 PKI 树颁发的证书毁坏任何节点, 来取得对无效证书的拜访权。

默认状况下，在 Akka 中禁用 Java 序列化。因为它具备多个已知的攻击面，因而这也是安全性最佳实际。

配置 SSL/TLS 以进行 Akka 近程解决

通过应用 tls-tcp 传输，将 SSL 用作近程传输：

接下来，必须配置理论的 SSL/TLS 参数：

始终应用环境变量来代替明码。不要在配置文件中定义实在明码。

依据 RFC 7525，倡议与 TLS 1.2 一起应用的算法 (撰写本文时) 为：

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

在配置零碎之前，您应该始终查看无关安全性和算法倡议的最新信息。

Lightbend 的 SSL-Config 库的 ” 生成 X.509 证书 ” 局部具体记录了创立和应用密钥库和证书的过程。

因为 Akka 近程解决实质上是对等的，因而须要在参加集群的每个近程解决节点上配置密钥存储和信赖存储。

官网 Java Secure Socket Extension 文档以及无关创立 KeyStore 和 TrustStore 的 Oracle 文档都是在 JVM 上设置安全性时钻研的重要资源。在对 SSL 进行故障排除和配置时，请查阅这些资源。

TLS 对等方之间的互相身份验证默认状况下处于启用状态。互相认证意味着连贯的被动方 (TLS 服务器方) 也将申请并验证连贯对等方的证书。如果没有此模式，则仅客户端在申请和验证证书。尽管 Akka 是点对点技术，但节点之间的每个连贯都从一侧 (“ 客户端 ”) 开始到另一侧(“ 服务器 ”)。

请留神，如果通过互相身份验证启用了 TLS，则攻击者仍有可能通过应用由同一外部 PKI 树颁发的证书毁坏任何节点来取得对无效证书的拜访权。

建议您通过 akka.remote.artery.ssl.config-ssl-engine.hostname-verification = on 启用主机名验证。启用后，它将验证指标主机名是否与对等方证书中的主机名匹配。

在主机名是动静的且当时不晓得的部署中，能够勾销主机名验证。

您能够抉择几种形式来设置证书和主机名验证：

• 所有节点具备一套密钥和一个证书，并禁用主机名查看

  • 单个密钥集和单个证书调配给所有节点。证书能够自签名，因为它既作为身份验证证书散发，也作为受信赖证书散发。
  • 如果密钥 / 证书失落，其他人能够连贯到您的群集。
  • 将节点增加到集群很简略，因为能够将要害 material 部署 / 散发到新节点。

• 蕴含所有主机名的所有节点，具备一套密钥和一个证书，并启用主机名查看。

  • 这意味着只有证书中提到的主机能力连贯到群集。
  • 如果要与之交谈的节点是它应该是的节点 (或者它是其余节点之一)，则无奈查看它。这仿佛是一个较小的限度，因
    为无论如何您必须信赖 Akka 群集中的所有群集节点。
  • 证书能够是自签名的，在这种状况下，雷同的单个证书能够在所有节点上散发和信赖(但请参阅下一个我的项目符号)
  • 增加新节点意味着其主机名须要与证书中的受信赖主机名统一。这要么意味着预感新主机，要么首先应用通配符证书，要么首先使 用残缺的 CA，因而，如果要增加更多的节点，则能够稍后颁发更多的证书(然而您曾经进入下一个解决方案的畛域了)。
  • 如果证书被盗，则只能用于通过可信赖证书中的主机名从可拜访的节点连贯到群集。这将须要篡改 DNS，以容许其余节点拜访群集(然而，在外部设置中篡改 DNS 可能比在 Internet 规模上更容易)。

• 为每个节点设置一个 CA，密钥 / 证书，并启用主机名查看。

  • 基本上像 Internet HTTPS 一样，然而您只信赖外部 CA，而后为每个新节点颁发证书。
  • 须要一个 PKI，CA 证书在所有节点上都是受信赖的，各个证书用于身份验证。
  • 仅散发 CA 证书和节点的密钥 / 证书。
  • 如果密钥 / 证书被盗，则只有同一节点能够拜访群集(除非 DNS 也被篡改)。您能够吊销单个证书。

另请参阅 ” 近程配置 ” 局部中的设置阐明。

留神
在 Linux 上应用 SHA1PRNG 时，倡议将 -Djava.security.egd=file:/dev/urandom 指定为 JVM 的参数，以避免阻塞。它不那么平安，因为它会重用种子。

不信赖模式

一个 actor 零碎一旦能够近程连贯到另一个零碎，则原则上能够将任何可能的音讯发送到该近程零碎中蕴含的任何 actor。一个示例可能是将 PoisonPill 发送给零碎守护者，从而敞开了该零碎。并非总是如此，能够应用以下设置禁用它：

这不容许发送零碎音讯 (actor 生命周期命令，DeathWatch 等) 以及任何扩大 PossibleHarmful 的音讯。然而，如果客户端发送了它们，则它们将被抛弃并记录下来(处于 DEBUG 级别，以缩小拒绝服务攻打的可能性)。“PossiblyHarmful” 涵盖了诸如 PoisonPill 和 Kill 之类的预约义音讯，但也能够将其作为标记接口增加到用户定义的音讯中。

正告
不受信赖的模式不能齐全爱护本人免受攻打。它使执行歹意或意外动作的难度稍大一些，但应留神，仍不应启用 Java 序列化。当在不受信赖的网络中运行时，能够通过网络安全性 (例如防火墙) 和 / 或启用具备互相身份验证的 TLS 来取得额定的爱护。

默认状况下，应用 actor selection 发送的音讯在不受信赖的模式下被抛弃，然而能够将接管 actor selection 音讯的权限授予配置中定义的特定 actor：

理论音讯仍不能为 PossibleHarmful 类型。

总之，当通过近程解决层传入时，以非信赖模式配置的零碎将疏忽以下操作：

• 近程部署(这也意味着没有近程监管)
• 近程 DeathWatch
• system.stop()，PoisonPill, Kill
• 发送扩大 PossiblyHarmful 接口的任何音讯，包含 Terminated
• 除非已在 trusted-selection-paths 中定义了目的地，否则应用 actor selection 发送的音讯。

留神
启用不信赖模式不会删除客户端自由选择其音讯发送指标的性能，这意味着能够将上述规定未禁止的音讯发送给近程零碎中的任何 actor。面向客户的零碎的良好做法是仅蕴含一组定义明确的入口点 actor，而后将申请 (可能在执行验证之后) 转发到蕴含理论工作者 actor 的另一个 actor 零碎。如果这两个服务器端零碎之间的消息传递是应用本地 ActorRef 实现的(能够在同一 JVM 中的 actor 零碎之间平安地替换它们)，则能够通过在音讯接口上标记 ”PossiblyHarmful” 来限度音讯，以使客户端无奈伪造音讯。

隔离

Akka 近程解决将 Aeron 用作底层音讯传输。Aeron 应用 UDP，还增加了牢靠的传递和会话语义，这与 TCP 十分类似。这意味着将保留音讯的程序，这是 Actor 音讯程序保障所必须的。在失常状况下，所有音讯都将被传递，然而在某些状况下，可能无奈将消息传递到目的地：

• 在网络分区和 Aeron 会话中断期间，一旦分区完结，此操作将主动复原
• 当发送太多音讯而没有流控制，塞满出站发送队列时(outbound-message-queue-size 配置)
• 如果音讯的序列化或反序列化失败(只会丢掉该音讯)
• 如果近程解决发生意外的异样

简而言之，如消息传递可靠性中所述，Actor 消息传递是 ” 最多一次 ”

Akka 中的某些音讯称为零碎音讯，不能删除这些音讯，因为这会导致系统之间的状态不统一。这些音讯次要用于两个性能：近程死亡监督和近程部署。这些音讯由 Akka 近程解决传递，通过确认每条音讯并从新发送未确认的音讯实现 ” 齐全一次 ” 保障。如果依然无奈传递零碎音讯，则与指标零碎的关联将无奈复原，并且将向近程零碎上的所有受监督的 actor 收回终止音讯。它处于所谓的隔离状态。如果不应用近程监督或近程部署，通常不会产生隔离。

每个 ActorSystem 实例都有一个惟一的标识符(UID)，这对于重新启动零碎时，辨别具备雷同主机和端口的零碎很重要。被隔离的是特定的(UID)。从此状态复原的惟一办法是重新启动其中一个 actor 零碎。

发送到隔离零碎和从隔离零碎接管的音讯将被抛弃。然而，能够应用 actorSelection 将音讯发送到隔离零碎的地址，这对于探测系统是否已重新启动很有用。

在以下状况下，将隔离关联：

• 集群节点已从群集成员关系中删除。
• 近程故障检测器触发器，即应用近程监督。应用 Akka 集群时，这是不同的。如果网络分区修复，则集群故障检测器无奈进行的察看能够复原到能够进行的状态。故障检测器触发时，集群成员未隔离。
• 零碎消息传递缓冲区溢出，例如因为同时有太多监督申请(system-message-buffer-size)。
• 近程零碎的管制子通道中产生异样。

当第一个音讯发送到目的地时，ActorSystem 的 UID 在双向握手中进行替换。握手将重试，直到其余零碎回答为止，直到握手实现，其余音讯都不会通过。如果无奈在超时 (握手超时配置) 内建设握手，则关联将进行(开释资源)。如果无奈建设握手，则排队的音讯将被抛弃。因为 UID 未知，因而不会被隔离。当下一条音讯发送到目的地时，新的握手尝试将开始。

实际上，还会在指标零碎重新启动后定期发送握手申请，以建设工作连贯。

监控近程 actor

监控近程 actor 就像监控本地 actor 一样，如 Lifecycle Monitoring 或 DeathWatch 中所述。然而，须要留神的是，与本地状况不同，当近程 actor 不能以一种优雅的形式终止，发送零碎音讯以告诉观察者 actor 无关事件，而是将其托管在一个忽然进行的零碎。这些状况由内置的故障检测器解决。

故障检测

在后盾，近程死亡监督程序除了失常终止受监督的 actor 之外，还应用心跳音讯和故障检测器从网络故障和 JVM 解体生成终止音讯。

心跳达到工夫由 Phi 应计故障检测器解释。

失败的可疑水平由称为 phi 的值给出。phi 故障检测器的根本思维是在能够动静调整以反映以后网络情况的标度上，表白 phi 的值。

phi 的值计算如下：

其中 F 是正态分布的累积散布函数，其均值和标准差是依据历史心跳达到间隔时间估算得出的。

在近程配置中，您能够调整 akka.remote.watch-failure-detector.threshold 来定义何时将 phi 值视为失败。

较低的阈值易于产生许多误报，但能够确保在产生理论碰撞时疾速检测到。相同，较高的阈值产生较少的谬误，但须要更多的工夫来检测理论的解体。默认阈值为 10，实用于大多数状况。然而，在诸如 Amazon EC2 之类的云环境中，该值能够减少到 12，以解决有时在此类平台上产生的网络问题。

下图阐明了自上一个心跳以来 phi 如何随着工夫减少而减少。

依据历史达到工夫的平均值和标准偏差计算出 Phi。上一张图表是 200 ms 标准偏差的示例。如果心跳以较小的偏差达到，则曲线会变陡，即能够更快地确定故障。对于 100 ms 的标准偏差，曲线看起来像这样。

为了可能应答突发异样(例如垃圾收集暂停和瞬态网络故障)，故障检测器配置无余量 akka.remote.watch-failure-detector.acceptable-heartbeat-pause。您可能要依据您的环境调整此性能的 ” 近程配置 ”。这是配置为 3 秒的 ”acceptable-heartbeat-pause” 曲线的样子。

序列化

您须要为 actor 音讯启用序列化。在许多状况下，应用 Jackson 进行序列化是一个不错的抉择，如果您没有其余抉择，咱们倡议应用。

基于 ByteBuffer 的序列化

Artery 引入了一种新的序列化机制，该机制容许 ByteBufferSerializer 间接写入共享的 java.nio.ByteBuffer，而不用为每个序列化的音讯调配并返回 Array[Byte]。对于高吞吐量消息传递，此 API 更改能够带来显着的性能劣势，因而咱们倡议更改序列化程序以应用此新机制。

这个新的 API 还能够与新版本的 Google Protocol Buffers 和其余序列化库一起很好地应用，它们具备间接与 ByteBuffers 进行串行化的性能。

因为新性能仅更改字节的读取和写入形式，而其余序列化根底构造放弃不变，因而咱们建议您先浏览序列化文档。

实现 akka.serialization.ByteBufferSerializer 的形式与其余任何序列化器雷同。

因而，为 Artery 实现序列化程序与实现此接口一样简略，并像平常一样绑定序列化程序(在序列化中进行了阐明)。

实现通常应扩大 SerializerWithStringManifest，除了基于 ByteBuffer 的 toBinary 和 fromBinary 办法之外，还应实现基于数组的 toBinary 和 fromBinary 办法。当不应用 ByteBuffer 时将应用基于数组的办法，例如 在 Akka Persistence 中。

请留神，基于数组的办法能够通过委派来实现，如下所示：

带有远程目标的路由器

将近程解决与路由相结合是相对可行的。

近程部署路由池能够配置为：

此配置设置将克隆 remotePool 的 Props 中定义的 actor 10 次，并将其均匀分布在两个给定的指标节点上。

应用近程部署的路由池时，必须确保能够对 Props 的所有参数进行序列化。

一组近程 actor 能够配置为：

此配置会将音讯发送到已定义的近程 actor 门路。它要求您在具备匹配门路的近程节点上创立指标 actor。这不是由路由器实现的。

Artery 的新变动

Artery 是旧近程模块的从新实现，旨在进步性能和稳定性。它在很大水平上与旧的实现兼容，并且在许多状况下是间接代替。与之前的实现相比，Artery 的次要性能：

• 基于 Aeron(UDP)和 Akka Streams TCP/TLS 而不是 Netty TCP
• 专一于高吞吐量，低提早的通信
• 通过应用专用子通道，能够将外部管制音讯与用户音讯隔离开来，从而进步了稳定性并缩小了在流量较大时的谬误故障检测。
• 次要是无调配操作
• 反对大音讯的独自子信道，以防止烦扰小音讯
• 压缩线上的 actor 门路以缩小较小音讯的开销
• 间接应用 ByteBuffer 反对更快的序列化 / 反序列化
• 内置的 Flight-Recorder 可帮忙调试施行问题，而不会因施行特定事件而净化用户日志
• 提供次要 Akka 版本之间的协定稳定性，以反对大规模零碎的滚动更新

与以前的实现的次要不兼容变动是 ActorRef 的字符串示意模式的协定字段始终为 akka，而不是先前应用的 akka.tcp 或 akka.ssl.tcp。配置属性也不同。

性能调优

通道

音讯序列化和反序列化可能是近程通信的瓶颈。因而，反对并行的入站和出站通道以并行执行序列化和其余工作，以供不同的指标 actor 应用。对于入站音讯，应用多个通道最有价值，因为来自所有近程零碎的所有入站音讯共享同一入站流。对于出站音讯，每个远程目标零碎曾经有一个流，因而，多个出站通道仅在发送到同一指标零碎中的不同 actor 时才减少价值。

通道的抉择基于接收者 ActorRef 的统一哈希值，以保留每个接收者的音讯程序。

留神，入站通道数 = 1 和出站通道数 = 1 能够实现最低的提早，因为多个通道引入了异步边界。

还要留神，并行任务的总数受 remote-dispatcher 的束缚，并且线程池的大小不应超过 CPU 外围数减去理论在应用程序中解决音讯的，实际上 pool 的大小应小于外围数量的一半。

无关默认值，请参见参考配置中的入站通道和出站通道。

大音讯专用子通道

用户定义的近程 actor 之间的所有通信均与 Akka 内部消息的通道隔离，因而，较大的用户音讯不能阻塞紧急零碎音讯。尽管这为 Akka 服务提供了良好的隔离，然而默认状况下，所有用户通信都是通过共享网络连接 (Aeron 流) 进行的。当一些 actor 发送大音讯时，这可能导致其余音讯蒙受更高的提早，因为他们须要期待直到残缺音讯已在共享通道上传输(因而成为共享瓶颈)。在这些状况下，拆散具备不同 QoS 要求的 actor 通常是有帮忙的：大音讯与低提早。

Akka 近程解决 (如果已配置) 为大型音讯提供了专用通道。因为肯定不能违反 actor 音讯的程序，因而该通道实际上专用于 actor 而不是音讯，以确保所有音讯都按发送程序达到。通过应用必须在发送方和接管方的 actor 系统配置中指定的门路模式，能够在给定门路上调配 actor 以应用此专用通道：

conf
这意味着发送给以下 actor 的所有音讯都将通过专用的大型音讯通道传递：

-/user/largeMessageActor
-/user/largeMesageActorGroup/actor1
-/user/largeMessageActorGroup/actor2
-/user/anotherGroup/actor1/largeMes​​sages
-/user/anotherGroup/actor2/largeMes​​sages
-/user/thirdGroup/actor3/
-/user/thirdGroup/actor4/actor5

如前所述，应用默认通道发送发往与这些模式都不匹配的 actor 的音讯。

内部共享的 Aeron 媒体驱动程序

Aeron 传输在所谓的 media driver 中运行。默认状况下，Akka 启动与应用程序雷同的 JVM 过程中嵌入的媒体驱动程序。这很不便，并且只需一个过程即可启动和监督，从而简化了操作问题。

media 驱动程序可能会占用大量 CPU 资源。如果在同一台机器上运行多个 Akka 应用程序 JVM，则理智的做法是将其作为独自的过程运行，以共享媒体驱动程序。

媒体驱动程序还具备与一般应用程序不同的资源应用个性，因而，将媒体驱动程序作为独自的过程运行会更加高效和稳固。

鉴于 Aeron jar 文件位于类门路中，能够应用以下形式启动独立的媒体驱动程序：

须要的 classpath

您能够在 Maven Central 上找到这些 jar 文件，也能够应用首选的构建工具创立一个包。

您能够将 Aeron 属性作为命令行 - D 零碎属性传递：

您还能够在文件中定义 Aeron 属性：

此类属性文件的示例：

在 Aeron 文档中理解无关媒体驱动程序的更多信息。

要应用 Akka 应用程序中的内部媒体驱动程序，您须要定义以下两个配置属性：

aeron-dir 必须与您启动媒体驱动程序时应用的目录匹配，即 aeron.dir 属性。

而后，能够通过指向同一目录将多个 Akka 应用程序配置为应用雷同的媒体驱动程序。

请留神，如果媒体驱动程序过程已进行，则正在应用该过程的 Akka 应用程序也将进行。

Aeron 调优

请参阅无关性能测试的 Aeron 文档。

微调 CPU 使用率提早衡量

Artery 设计用于低提早，因而，当零碎大部分处于闲暇状态时，它可能会占用大量 CPU。这并不总是可取的。应用 Aeron 传输时，能够通过以下配置在 CPU 使用率和提早之间进行衡量：
conf
通过将此值设置为较小的数字，它通知 Akka 在专用于自旋期待的线程上执行更长的 ” 休眠 ” 时间段，从而在没有立刻执行的工作的状况下缩小 CPU 负载，但代价是对理论产生的事件响应工夫更长。值得一提的是，在间断的高吞吐量期间，此设置没有太大的区别，因为线程次要执行工作。这也意味着在高吞吐量 (但低于最大容量) 下，零碎的提早可能比低音讯速率下的提早少。

近程配置

有许多与 Akka 中的近程解决相干的配置属性。咱们参考 reference configuration 以获取更多信息。

留神
最好以编程形式设置诸如侦听 IP 和端口号之类的属性，办法如下：

NAT 或 Docker 容器中的 Akka

在波及网络地址转换 (NAT)，负载均衡器或 Docker 容器的设置中，Akka 绑定到的主机名和端口对将不同于用于从内部连贯到零碎的 ” 逻辑 ” 主机名和端口对。这须要非凡的配置，该配置同时设置逻辑对和绑定对以进行近程解决。
conf
您能够查看带有 docker-compse 的示例我的项目集群，以理解理论状况。

在 Docker/Kubernetes 中运行

在容器化环境中应用 aeron-udp 时，必须特地留神媒体驱动程序在 ram 磁盘上运行。默认状况下，它位于 /dev/shm 中，在大多数物理 Linux 机器上，它将被挂载为零碎内存大小的一半。

Docker 和 Kubernetes 挂载了一个 64Mb 的 ram 磁盘。这不太可能足够大。对于 docker，能够应用 –shm-size =”512mb” 笼罩。

在 Kubernetes 中，尚无间接反对来设置 shm 大小。而是将一个 Memory 类型的 EmptyDir 挂载到 /dev/shm 中，例如在一个 deployment.yml 中：
yml

以后没有方法限度内存空目录的大小，然而有增加的 pull request。

挂载中应用的所有空间都将计入容器的内存使用量。

航行记录仪

在 JDK 11 上运行 Artery 时，可通过 Java Flight Recorder(JFR)取得特定的航行记录。通过检测 JDK 11 能够主动启用航行记录器，但能够通过设置 akka.java-flight-recorder.enabled=false 禁用航行记录器。

启用 JFR 时，默认状况下会收回开销较低的 Artery 特定事件，开销较高的事件须要自定义设置模板，并且不会通过剖析 JFR 模板主动启用。要启用这些性能，请创立概要剖析模板的正本并启用所有 Akka 子类别事件，例如通过 JMC GUI。