兩個微服務之間的通信架構

Question

首先，我正在為項目使用JHipster4.0.x。 我正在使用微服務架構。

對於此示例，我有一個網關，一個微服務用於“ Store”，第二個微服務用於“ Skill”。 我想將所有商店集中在一個數據庫中，而技能則集中在另一個數據庫中。

每個數據庫都是一個不會以相同速度發展的數據庫。 另一方面，它們將成為我基礎結構的中心，以便通過ESB更新其他軟件。

Jhipster很好，我很容易為每項服務提供CRUD。

棘手的一點是商店由技能定義。 最簡單的方法是說我只對“技能”和“商店”提供一項服務。 但是我不能這樣做，因為“技能”也必須是其他數據的中心點。

我想象這個實體的架構

[技能]

[STORE] ----一對多---- [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" }

然后，當我在Store上進行CRUD時，我也將使用Skill中的CRUD，感謝本文，但這是另一回事了。

你怎么看？ 這是正確的方法嗎？

Answer 1

沒有正確的方法 ，因為這取決於您的需求。 在您提到的文章中（我是作者，謝謝您！），我描述了通用方法，該方法在此處描述了更好的工作流程，這使它更易於實現，但又沒有改變事實，您可以做更多隨着您增加服務通信鏈，CRUD要求一個請求。

那么，這可能有什么問題呢？ 盡管這是最一致的方法（您始終會獲得最新的數據狀態），但是由於存儲服務與技能服務耦合，因此缺乏可用性。 如果失敗，並且沒有高級緩存設置（例如使用hystrix），則如果技能服務崩潰，則有2個服務將失敗。 此外，請求將產生更大的網絡開銷。

另一種方法稱為事件源，其中您的技能服務在消息傳遞通道中通知技能實體的更改，因此所有使用服務的服務都可以通過應用更改日志來計算當前狀態。 盡管這將減少網絡開銷並保證可用性，但您的數據“最終是一致的”。

為此，您可以使用apache kafka（JHipster也支持）並切換到基於事件的實體通信。 這種方法很難實施，因為不存在用於基於REST的安全通信的預構建功能。