微服务体系结构和层

Question

让我们讨论一下微服务环境的体系结构。我们公司内部正在进行讨论，我想得到一些反馈。我认真考虑的是一个编排层(代码复制、更多的移动部分更改api)。

选项一-与编排层：

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

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

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

选项一-没有编排层：

webapp ->服务->持久性

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

在这里，服务可以相互交谈，聚集的服务在这里存在。

具体问题：

• 账单属于哪里？
• 你更喜欢哪种解决方案？赞成/反对。
• 其他建议？

Answer 1

webapp ->编排-> 服务 ->持久性 api -> api gw ->编排-> 服务 ->持久性(重点雷)

我们能退后一点吗？我想质疑这里使用的术语。

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

您将服务夹在所谓的业务流程和持久性之间。但是，在SOA设计中，所有上述元素都是创建单个服务所必需的。

但在你的例子中，坚持到底是什么呢？不管它是什么，它似乎是在服务之外。那么，服务如何持久化数据呢？web应用程序/API似乎也在服务之外。那么，服务如何在屏幕上显示其数据呢？

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

服务是自治

如果服务应该是自治的，那么服务需要负责保存自己的数据。服务还需要负责通过UI显示其内部状态。

我认真考虑的是一个编排层

由此得出的结论是，服务部门还应负责内部国家如何与外部世界沟通，包括其自身与其他服务之间的沟通。

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

编排是一个关注，就像持久性、检测等，因此在SOA上下文中最好以分布式、自治的方式实现，而不是以中心化的方式实现。

所以，在回答你们的问题时：

账单属于哪里？

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

你更喜欢哪种解决方案？赞成/反对。

如前所述，我认为不应在问题提出的水平上作出选择。我认为任何需要统筹的服务都应负责。

其他建议？

如果您还没有看到这，请看一看它。