微处事的三种通讯要领
假如我们的应用在 Amazon Web Services 中,可以用简朴关照处事(SNS)作为动静署理。此刻 ServiceA 可以将动静推送到 ServiceB 监听的 SNS 主题。
ServiceB 侦听 SNS 主题上的动静,当收到一个体谅的动静时,就会执行它的营业逻辑。 这引入了它本身的伟大性。请留意,ServiceA 不再吸取状态 URL 搜查进度。这是由于我们只知道动静已经被发送,而不知道 ServiceB 是否已经收到了它。 这可以通过很多差异的方法办理。一种要领是将 MessageId 返回给挪用者。可以用它来查询 ServiceB,它将存储它收到的动静的 MessageId。 留意,行使此模式的两个处事之间如故存在一些耦合。譬喻,ServiceB 和 ServiceA 必需就动静布局的界说以及个中包括什么告竣同等。 变乱驱动的通讯 最后一种模式是变乱驱动模式。这是另一种异步要领,它看起来完全消除了处事之间的耦合。 与动静转达模式差异,变乱驱动要领不必要处事必需知道民众动静布局。处事之间的通讯通过各个处事发生的变乱举办。 此处如故必要动静署理,由于各个处事会将其变乱写入个中。可是与动静要领差异,斲丧处事不必要知道变乱的细节,它们对变乱的产生做出回响,而不是发生能会或也许不会转达的信息。 在情势上,这凡是被称为“仅变乱驱动的通讯”。下面的代码和动静转达要领相同,但推送到SNS的变乱是通用的。
留意,我们的 SNS 主题动静是一个简朴的 event 属性。每个处事都赞成以这种名目将变乱推送到署理,这使得通讯疏松耦合。处事可以监听他们体谅的变乱,而且提供为相应它们而必要运行的逻辑。 此模式使处事的耦合疏松,由于变乱中不包括任何有用负载。此要领中的每个处事城市相应变乱的产生并运行其营业逻辑。在这里,我们通过 SNS 主题发送变乱。也可以行使其他变乱,譬喻文件上传或数据库行更新。 结论 这些是基于微处事的架构中全部也许的通讯模式吗?虽然不是。基于同步和异步模式举办通讯的方法尚有许多种。 可是这三个突出了支持同步与异步的优弱点。在选择时要思量耦合身分,但也必要思量开拓和调试的详细环境与留意事项。
(编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |