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

Question

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

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

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

Jhipster 非常适合这一点，我可以轻松获得每项服务的 CRUD。

棘手的一点是商店是由技能定义的。最简单的方法是说我只做“技能”和“商店”一项服务。但我不能这样做，因为“技能”也必须是其他数据的中心点。

我想象了这个实体的架构

[技能]

[STORE]----多对一----[LINK_WITH_OTHER_ENTITIES]

(由 jhipster 生成 *.json):

• 技能服务:

  • 实体技能

  {
“流畅的方法”:正确，
“关系”:[]，
“字段”:[
{
"字段名称": "代码",
“字段类型”:“字符串”
},
{
"fieldName": "诽谤",
“字段类型”:“字符串”
}
],
“更改日志日期”:“20161201084915”，
“dto”:“不”，
“服务”:“没有”，
"entityTableName": "filiere_metier",
“分页”:“否”，
“微服务名称”:“技术”，
“搜索引擎”:“ Elasticsearch ”
}

• 商店服务:

  • 实体商店

  {
“流畅的方法”:正确，
“关系”:[
{
"relationshipName": "categorie_metier",
"otherEntityName": "pont_msvc",
"relationshipType": "多对一",
“其他实体字段”:“id”
}
],
“字段”:[
{
"字段名称": "代码",
“字段类型”:“字符串”
},
{
“字段名称”:“lib”，
“字段类型”:“字符串”
}
],
“变更日志日期”:“20161125141916”，
“dto”:“不”，
“服务”:“没有”，
"entityTableName": "商店",
“分页”:“否”，
"微服务名称": "商店",
“搜索引擎”:“ Elasticsearch ”
}

  • 与技能建立链接的实体

  {
“流畅的方法”:正确，
“关系”:[]，
“字段”:[
{
"fieldName": "idext",
“字段类型”:“字符串”
},
{
"fieldName": "msvcName",
"fieldType": "微服务",
“fieldValues”:“gw，metier”
},
{
"fieldName": "msvcEntityName",
“字段类型”:“字符串”
}
],
“更改日志日期”:“20161208100401”，
“dto”:“不”，
“服务”:“没有”，
"entityTableName": "pont_msvc",
“分页”:“否”，
"微服务名称": "商店",
“搜索引擎”:“ Elasticsearch ”
}

然后，当我在商店中进行 CRUD 时，我也会使用 Skill 中的 CRUD，谢谢 this article但这是另一回事了。

你觉得怎么样？这是正确的方法吗？

Answer 1

没有正确的方法，因为这取决于您的需求。在你提到的文章中(我是作者，感谢补充!)，我描述了一般方法，它有更好的工作流程described here ，这使得它更容易实现，但并没有改变这样一个事实:随着服务通信链的增加，您会对一个请求执行更多的 CRUD 调用。

那么，这可能有什么问题呢？虽然这是最一致的方法(您始终可以获得数据的最新状态)，但您缺乏可用性，因为您的商店服务与技能服务耦合。如果此操作失败并且没有高级缓存设置(例如使用 hystrix)，则如果技能服务崩溃，您将有 2 个服务失败。另外，请求会产生较大的网络开销。

另一种方法称为事件溯源，您的技能服务在消息传递 channel 中通知技能实体的更改，因此所有使用服务都可以通过应用该更改日志来计算当前状态。虽然这会减少网络开销并保证可用性，但您的数据“最终一致”。

为此，您可以采用 apache kafka(JHipster 也支持)并切换到基于事件的实体通信。这种方法更难实现，因为没有用于基于 REST 的安全通信的预构建函数