关于vue.js:Artery-Remoting

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。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据