如果我们考虑 web 服务、RMI 连接或任何其他通信协议,这里的问题是一个常见问题。始终建议共享“原始”值然后引用,因为编组/解组或序列化/反序列化总是令人头疼。还要考虑相互交流的不同类型的环境。分享坚实的价值观是解决沟通问题的安全方式。
Akka 本身就是“微服务”相互通信参与者的一个很好的例子。当我阅读 Akka 的文档时,一个好词很好地定义了 Akka 演员。Actor 就像邮箱客户端,您可以认为每个客户端都有一个邮箱。当您传递一个变量时,就像您收到一封新电子邮件一样。
长故事的简短结果,避免共享“依赖”对象,这些对象在从另一个参与者读取之前可能会失效。此外,如果您的系统动态命名 actorRefs,请避免通过其引用调用它们。
“物化”在 akka-streams 的文档中进行了解释。
物化过程可以被参数化,例如用关于连接地址和端口信息的特定信息来实例化用于处理TCP连接数据的蓝图。此外,物化通常会创建特定对象,这些对象在处理引擎运行后可用于与处理引擎进行交互,例如用于关闭它或用于提取指标。这意味着物化函数从外部获取一组参数并产生一组结果。组合性要求这两个集合不能交互,因为这会建立一个隐蔽的通道,不同的部分可以通过该通道进行通信,从而导致初始化顺序问题和难以理解的运行时故障。
所以使用参数而不是传递“连接”本身。
推迟实时资源并不是什么大问题。这意味着如果您为所有系统使用一个连接,您应该始终保持它处于活动状态。或者当您在actor-1 中创建一个事务并将其发送给actor-2 时,您不应该在actor-1 中终止事务,直到actor-2 完成其事务工作。
那你怎么理解?然后你使用“Future”和“offer()”。
希望我能理解你的问题,希望我能表达自己。