web-services - 微服务组合方法

Question

我有一个问题要问微服务社区。我将举一个教育领域的例子，但它适用于每个微服务架构。

假设我有 学生服务和 许可服务业务要求学生人数受许可证限制。因此，每次创建学生时都必须进行许可检查。有多种类型的许可证，因此操作中必须包含许可证的类型。

我的问题是您发现哪种方法在实践中更好:

构建一个复合服务，调用这 2 个服务

将学生服务耦合到许可服务，以便在调用 createStudent 时，学生服务会调用许可服务，并且只有在完成后才会创建学生

使用基于事件的架构

人们谈论微服务架构更像是图表而不是层次结构和 选项 1 有点把它变成一个层次结构，在那里你会得到越来越粗糙的复合 Material 。其他缺点是它对客户端实际使用的服务造成了混淆，并且存在一些重复，因为复合 API 必须包含调用下游服务所需的所有参数。
它确实有一个很大的好处，因为它为您提供了一个进行故障处理、编排和处理一致性的自然场所。

选项 2 似乎它也有缺点:

许可 API 必须泄漏到学生 API 中，以便您可以指定许可限制。

它给学生服务带来了很大的负担，因为它必须处理所有相关服务的一致性

随着更多服务需要在创建学生时使用react，我可以看到依赖关系图很快失控，除了来自管理学生的自己的逻辑之外，服务还必须处理这种复杂性。

选项 3 在解耦天堂时，我真的认为这行不通，因为这一切都是从 UI 触发的，人们并不真正习惯于“在这个新学生出现之前去做其他事情”的方法。

谢谢

Answer 1

选项 1 和 2 会产生紧密耦合，应尽可能避免这种耦合，因为您希望服务是独立的。所以问题变成了:

我们如何使用基于事件的架构来做到这一点？

使用事件跟踪学生服务中许可服务的许可信息，实际上是数据重复。这里的缺点是:由于数据复制是异步的，因此您只有最终的一致性。

使用异步事件触发事件链，最终触发学生创作。从您的问题来看，您似乎已经有了这个想法，但是在处理 UI 时遇到了问题。您在这里有两种可能的选择:WAITING学生创建(或失败)事件并有少量超时，或者(事件更好)，让您的系统完全响应(对 UI 使用服务器-客户端推送机制)。