两个微服务之间的通信架构

Question

首先，我在项目中使用JHIPSTER 4.0.x。我正在使用微服务架构。

在此示例中，我有一个网关，一个用于"商店"的微服务，第二个用于"技能"。我想将所有商店集中在一个数据库中，并在第二个数据库中集中。

每个是一个数据存储库，不会以相同的速度发展。另一方面，它们将是我的基础架构的中心，以通过ESB更新其他软件。

jhipster对此很棒，我很容易为每种服务的碎屑。

棘手的点是商店是由技能定义的。最简单的方法是说我只用"技能"one_answers"商店"进行一项服务。但是我做不到，因为"技能"也必须是其他数据的中心。

我想象该实体的体系结构

[技能]

[商店] ----多到一个---- [link_with_other_entities]

（使用 *.json生成Jhipster）：

• 在技能服务上：

  • 实体技能

  { "fluentMethods": true, "relationships": [], "fields": [ { "fieldName": "code", "fieldType": "String" }, { "fieldName": "libelle", "fieldType": "String" } ], "changelogDate": "20161201084915", "dto": "no", "service": "no", "entityTableName": "filiere_metier", "pagination": "no", "microserviceName": "metiers", "searchEngine": "elasticsearch" }

• 在商店服务上：

  • 一个实体商店

  { "fluentMethods": true, "relationships": [ { "relationshipName": "categorie_metier", "otherEntityName": "pont_msvc", "relationshipType": "many-to-one", "otherEntityField": "id" } ], "fields": [ { "fieldName": "code", "fieldType": "String" }, { "fieldName": "lib", "fieldType": "String" } ], "changelogDate": "20161125141916", "dto": "no", "service": "no", "entityTableName": "store", "pagination": "no", "microserviceName": "store", "searchEngine": "elasticsearch" }

  • 与技能建立链接的实体

  { "fluentMethods": true, "relationships": [], "fields": [ { "fieldName": "idext", "fieldType": "String" }, { "fieldName": "msvcName", "fieldType": "MicroServices", "fieldValues": "gw,metier" }, { "fieldName": "msvcEntityName", "fieldType": "String" } ], "changelogDate": "20161208100401", "dto": "no", "service": "no", "entityTableName": "pont_msvc", "pagination": "no", "microserviceName": "store", "searchEngine": "elasticsearch" }

然后，当我在商店上crud时，我也会使用技巧中的Crud，谢谢这篇文章，但这是另一个故事。

您怎么看？这是正确的方式吗？

Answer 1

没有正确的方式，因为这取决于您的需求。在您提到的文章（我是作者，感谢您的补充！），我描述了一般方法，该方法在此处描述了更好的工作流程，这使实施更容易，但不会改变事实，您会做更多当您增加服务通信链时，Crud要求一个请求。

那么，这可能是什么问题？虽然这是最一致的方法（您始终得到数据的最新状态），但由于您的商店服务与技能服务相连，因此您缺乏可用性。如果失败并且没有高级缓存设置（例如HyStrix），则如果技能服务崩溃，则有2个服务失败。此外，请求将产生更大的网络开销。

另一种方法称为事件制品，您的技能服务在消息传递渠道中有关技能实体的变化提供了信息，因此所有消费服务都可以通过应用该更改程序来计算当前状态。尽管这导致网络开销较少并保证可用性，但您的数据"最终是一致的"。

为此，您可以将Apache Kafka（也得到JHIPSTER的支持），然后切换到基于事件的实体通信。这种方法很难实施，因为没有预先构建的功能，因为它们用于基于静止的和安全的通信