我们有几个微服务（同一个帐户），它们发布到主题以便与其他服务进行通信。
在一项服务中，我有一个 lambda (A)，我想在其中调用另一个 lambda (B)，但我不在乎 B 的响应是什么。我只想将消息发送到B，它会从那里处理事情，确保我不会在A 上占用当前线程。
没有其他服务需要关心这个事件，这就是为什么我认为一个主题/子，或者创建一个新服务，不适合这个场景。我真正关心的是 lambda A 不会被 B 所发生的事情所束缚。
我不愿意直接从A 调用B，而不是await（即没有回调），因为它会增加A 的包大小，当有一小部分时间时实际上需要那个函数B。
在微服务架构中，这里最正确的方法是什么？我还能在同一个微服务中为A 创建一个B 将收听的主题吗？还是最好还是创建一个新的“服务”？
我只是想小心分离代码，以便 A lambda 不需要 B 需要的代码/库。
【问题讨论】：
让服务在内部使用 pub/sub 模型完全是“一件事”。这实际上是一种解耦组件及其执行的好方法。但是，此时“微服务”一词可能不再准确 - 并不是一开始就定义明确。
系统组件是强耦合（A 调用B）还是松耦合（A 发布，触发B）与A 和@987654327 的选择有很大关系@ 是，以及它们如何交互。例如：
B 是否非常复杂，或者与A 有很大不同？在你的情况下，答案是“否”——它们都是 lambdas，而且 lambdas 的复杂性是相当自我限制的。
如果A 严重依赖B，是否预计B 会频繁更改以需要更改A？
预计A 是否会频繁更改，从而导致将来直接调用B 不方便？
除了B之外，预计有朝一日还会有C、D、E等触发A吗？
A 和B 之间是否存在一对多关系，即一个A 会触发多个B 吗？
如果您对以上部分或全部的回答是是，那么通过 pub/sub 进行松散耦合可能适合您。如果您对他们中的大多数或全部人的回答是否，那么发布/订阅可能是矫枉过正的。 IE。如果您的回答是否定的，那么您正在链接两个简单的组件，几乎没有预期的变化和复杂性。
关于捆绑包大小的说明：
我的观点是，除非您正在使用真正庞大的捆绑软件，或者构建一个绝对尽可能精简的系统，否则这可能无关紧要。 It won't even increase your cold-start time。我建议不要担心它，直到它成为一个问题（对于大多数用例来说不太可能），而不是过早地优化。
【讨论】：
您必须使用异步调用在另一个 lambda 中调用 lambda。
这里正确解释了如何调用异步 lambda。
https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html
如果您使用 python 作为 lambda 的基础语言，这可以帮助您。
在微服务架构中，SNS (topis) 用于握手概念。它的意思是 pubs -sub 模型。当 A 完成工作时，发布就是您的工作完成。无论谁订阅 A，他们都会倾听并开始他们的工作。
如果您需要在 lambda A 作业完成后调用 lambda B，那么您就是 SNS 主题。但是如果需要在 lambda A 的过程完成之前调用 lambda B，那么您也可以在 lambda 内部调用，也可以在 lambda 内部调用 SNS raise SNS topic。
【讨论】：