您有一组微服务 A、B、C，由于各种原因与微服务 D 交互，有一天您发现有时需要通过加入 D 的一个 REST API 的一个输入字段进行潜在的清理或转换与其他一些信息。你基本上有两种选择：
- 实现一个服务 E 并在调用 D 之前在 A,B,C 中编写与 E 交互的逻辑
- 在 D 中实现一个专门的端口并在那里处理映射、清理和转换
第二种方法似乎更优越，因为它提供的重复更少并且更容易测试。有我们看不到的缺点吗？
问问题
83 次
3 回答
1
从我的角度来看，转换 D 的 rest api 的输入参数的工作必须由 D 的驱动适配器完成，即由 rest 控制器完成，它接受 rest 请求并调用 D 的应用程序服务。
于 2019-10-24T08:38:01.500 回答
0
抱歉，没有答案，只是关于这些服务性质的问题：
谁拥有这个模型转换逻辑？它属于D的业务领域吗？还是应该解决其中一位客户提供的输入的复杂性？
在谈到模型转换时，您使用的是“干净”这个词。这是否意味着清理过多的信息，或者您实际上是否必须删除一些根本不应该存在的敏感细节？
另外，其变化的原因是什么？如果逻辑必须改变，它是否必须与 D、客户或所有这些人同时改变？
于 2019-10-22T08:37:18.900 回答
-1
通过应用依赖倒置原则，您所面临的问题可以通过对架构设计稍作改变来解决。
假设原理很清楚，在架构层面，不是让多个微服务通过多个 API 进行通信，而是应该打破这种直接依赖关系，并且能够尽可能避免向其他微服务询问东西。服务。
您可以通过实现事件驱动架构来实现：当某个服务中发生某些事情时，该服务将事件发布到消息代理（如 RabbitMQ），其他感兴趣的服务可以订阅该事件并使用该信息执行操作，例如创建一个所需信息的本地投影，以避免查询返回。
如果任何微服务知道它所需要的一切，你就可以避免耦合，并且可以适当地扩展生态系统。此外，您可以简单地减少通过让这些服务相互通信而引入的延迟。
祝你好运！
于 2019-11-15T20:02:31.283 回答