微服务架构和层

Question

让我们讨论一下微服务环境的架构。我们正在公司内部进行讨论，我想要一些反馈。我认真考虑的是编排层（代码重复，更多移动部件更改 API）。

选项一 - 使用编排层：

webapp -> 编排 -> 服务 -> 持久性

api -> api gw -> 编排 -> 服务 -> 持久性

在这种情况下，不允许服务相互交谈。编排层中的聚合服务

选项一 - 没有编排层：

webapp -> 服务 -> 持久性

api -> api gw -> 服务 -> 持久性

这里允许服务相互通信，这里存在聚合服务。

具体问题：

• 计费属于哪里？
• 您更喜欢哪种解决方案？优点/缺点。
• 其他建议？

Answer 1

webapp -> 编排 -> 服务 -> 持久性

api -> api gw -> 编排 -> 服务 -> 持久性（强调我的）

我们可以备份一下吗？我想质疑这里使用的术语。

对我来说，上述堆栈在 SOA 的上下文中没有多大意义。

服务 夹在称为 orchestration 和 persistence 的东西之间。但是，在 SOA 设计中，上述所有元素都是创建单一服务所必需的。

但在您的示例中，是持久性是什么？不管它是什么，它似乎都在服务之外。那么服务如何持久化数据呢？ Web 应用程序/API 也似乎在服务之外。那么服务如何在屏幕上显示它的数据呢？

如果您查看 SOA 的原则，特别是第二个原则：

服务是autonomous

如果服务应该是自治的，那么服务需要负责persisting it's own data。该服务还需要负责通过 UI 显示其内部状态。

我认真考虑的是编排层

因此，服务还应负责内部状态如何与外部世界进行通信，包括自身与其他服务之间的通信。

如果服务需要使用来自另一个服务的数据，那么消费者服务就有责任获取该数据。如果服务的状态发生变化，则该服务有责任让外界知道状态变化。

编排是concern，就像持久性、仪表化等一样，因此在 SOA 的上下文中最好以分布式、自主的方式实现，而不是集中式。

所以，在回答您的问题时：

帐单属于哪里？

计费属于它自己的垂直服务堆栈，包括 UI 视图、持久性、编排、通信、部署和管理。

您更喜欢哪种解决方案？优点/缺点。

如前所述，我认为不应该在提出问题的层面做出选择。我认为任何需要编排的服务都应该对此负责。

其他建议？

如果您还没有看过this，请查看它。