【问题标题】:Defining Microservice boundaries定义微服务边界
【发布时间】:2020-09-12 01:29:04
【问题描述】:

我已经开始学习和构建基于微服务的项目,但我总是陷入范围界定的情况并最终创建了一种单体应用。在我下面的 foo-bar 示例中,请建议范围应该是什么以及如何实现所需的输出。

服务或表格

  • 员工
  • 部门
  • 员工-部门-映射

假设

EmployeeDepartment 彼此之间没有任何交叉引用所有关系都在第三张表中维护Employee-Department-Mapping 关系可以是One-To-ManyMany-To-Many 基于企业对​​企业,在本例中为One-To-Many(与员工的部门)

要求

我想获得部门支付的总工资。类似于下面的查询,这里我对 3 个表进行简单的连接。这只有在所有都在同一个数据库和单个微服务中时才有可能。

Select d.DepartmentName, SUM(e.salary) 
from Employee e, Department d, Employee-Department-Mapping c 
where d.DepartmentName == c.DepartmentName 
AND e.Employee == c.Employee 
Group By c.DepatmentId 

约束

  • employee表有工资信息
  • 员工部门关系由第三张表维护。

我不是在寻找确切的答案,而是寻找解决此类问题的方法。 想知道如果您需要聚合输出,您将如何设计您的微服务,您会将所有这些表放在单个微服务中吗?我不想从每个微服务中提取数百万条记录并在内存中进行聚合。

【问题讨论】:

    标签: spring-boot architecture microservices


    【解决方案1】:

    微服务边界 - 如果您没有任何其他可扩展性原因 - 应该由业务定义。在这种特殊情况下 - 在不知道任何其他要求的情况下 - 我会说你应该选择一个管理这两个实体的微服务。话虽如此,我有足够的经验知道在现实世界中这个解决方案并不总是可行和可能的。幸运的是,您可以遵循一些模式来解决您所描述的情况。例如,CQRS 可能是一个解决方案https://dzone.com/articles/microservices-with-cqrs-and-event-sourcing

    【讨论】:

      【解决方案2】:

      你必须在这里改变你对微服务的想法。我可以在这里提出的是

      • 您必须多次调用不同的微服务并返回一个结果,您可以使用API Gateway 模式。您必须编写一个聚合器服务来通过两个 API 服务聚合两个表的输出。

      • 如果您不喜欢上述选项,您将不得不对数据库进行非规范化并在Employees 表中包含部门名称。这就是我们在微服务中使用 NoSQL 的原因。

      【讨论】:

      • 我认为聚合将是比非规范化更好的选择,因为这只是一个 foo-bar 示例,而在现实情况下可能难以管理。好吧,no-sql 是比 sql db 更好的选择。
      猜你喜欢
      • 2021-04-13
      • 2020-03-27
      • 2021-05-17
      • 2020-06-27
      • 2015-04-12
      • 2019-04-10
      • 1970-01-01
      • 1970-01-01
      • 2017-09-16
      相关资源
      最近更新 更多