【问题标题】:Update/Add as separate service and Get as separate service更新/添加为单独的服务和获取为单独的服务
【发布时间】:2018-06-04 20:22:48
【问题描述】:

我们开始将现有项目迁移到微服务架构中。在浏览了很多视频/讲座之后,我们得出一个结论,一个服务应该做一个任务,只做一个任务,并且应该擅长它。服务应围绕NounVerb 设计。

我们有一个基本上具有 CRUD 操作的实体。现在添加、更新和删除是最少使用的操作,但与这些操作相比,GET 请求太高了。通常,更新/添加/删除由管理员完成。

我们想到的是把 CRUD 实体分成两个服务

  • EntityCUDService(创建/更新/删除)
  • EntityLookupService(获取)

现在这两个服务都指向 mongo 中的同一个集合,或者说一些 SQL。 现在如果EntityCUDService 对集合/表进行了一些更改,那么EntityLookupService 将失败。

我们听说过维护语义版本控制,这听起来不错,但我们也听说微服务不应该共享模型/数据源。那么在我们有大量获取但同一实体的数十次更新/添加的情况下,处理此问题的最佳解决方案是什么

非常感谢任何帮助。

【问题讨论】:

  • 你正试图一口气打开所有的潘多拉魔盒。我的建议是继续采用最简单的解决方案,在一项服务中公开 REST 实体的 CRUD 操作。尝试使用负载均衡器分配负载。如果其他一切都无法满足所需的规模/负载,请选择 CQRS。

标签: microservices


【解决方案1】:

通常,微服务应该管理单个实体。因此,在您的情况下,您可以拥有一个微服务来管理实体(用于实体上的各种操作)。现在,如果您想在读写操作的基础上再次拆分服务,那么您将遵循 CQRS 模式。在 CQRS 中,您根据读写操作拆分您的微服务。因此,现在您将在同一实体上拥有 2 个服务,一个称为命令服务,另一个称为查询服务。我会建议首先使用一项服务来管理实体,然后如果需要将其拆分为更多单独的服务以进行读取和写入操作。同样,如果您要使用 CQRS,请查看事件溯源,因为它非常适合微服务设计中的 CQRS。

【讨论】:

    猜你喜欢
    • 2018-11-12
    • 2021-02-16
    • 1970-01-01
    • 1970-01-01
    • 2012-03-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多