【问题标题】:Microservices dependence uml diagram [closed]微服务依赖 uml 图
【发布时间】:2020-05-21 02:08:05
【问题描述】:

解释微服务如何相互依赖的最佳图表是什么? 比如下面这种情况:

用户服务暴露user_detail端点;

产品服务公开product_item_detail端点;

排序服务公开make_order 端点。

用户选择产品并下订单。

这是如何使用 uml 解释的?

我本来打算使用组件图,但我不明白如何解释每个服务的接口以及它们如何与其他服务的接口相关。

【问题讨论】:

  • 您对静态依赖项(暴露/使用的端点)感兴趣吗?还是您在案例最后一句话中描述的动态交互?
  • 我对静态依赖感兴趣。谢谢
  • 理想情况下,您希望完全避免微服务相互依赖。微服务的全部意义在于解耦您的服务。

标签: dependencies uml microservices endpoint component-diagram


【解决方案1】:

Microservices 是可独立部署的组件。因此,使用component diagram 似乎是一种很好的直觉:

它将组件指定为具有定义明确的接口的模块化单元,可在其环境中替换。组件概念涉及基于组件的开发和基于组件的系统结构(...)领域。

在您的组件图中,每个微服务都将显示为一个单独的component,其原型为«service»。由于微服务不只是实现一个接口,而是通过端点公开它,你应该使用ports

端口表示 EncapsulatedClassifier 与其环境通信的交互点。

提供或需要的接口(棒棒糖和套接字)将连接到端口。端口有所不同:没有端口,棒棒糖和套接字也可能意味着realisation«use» dependency 对大型单体中的接口分类器!

最后你的图表可能看起来有点像:

其他想法:

  • 如果您在 «service»«subsystem» 原型之间犹豫不决,您可以考虑创建自己的 UML 配置文件来定义 «microservice» 原型。

  • 1234563
  • 同样,如果您主要对依赖感兴趣,您可以只显示组件及其依赖关系(因为组件是分类器)。

  • 如果您想到微服务,您将不可避免地想到scaling strategies,例如在多个容器/服务器上运行同一服务的多个实例,或者将同一微服务的多个实例对数据进行分区.这种虽然是关于组件的部署场景。然后你可以考虑deployment diagrams。但这远远超出了你的问题。

【讨论】:

  • 先生,您是 UML 大师。
猜你喜欢
  • 2015-09-03
  • 2022-01-08
  • 2021-05-12
  • 2020-12-09
  • 2017-09-08
  • 2019-04-01
  • 2018-06-07
  • 1970-01-01
  • 2016-11-24
相关资源
最近更新 更多