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

Question

首先，我爲我的項目使用JHipster 4.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" }

然後當我CRUD的商店，我會從技能使用CRUD太感謝this article不過這點是另一回事。

您認爲如何？這是正確的方式嗎？

Answer 1

沒有正確的方法，因爲它取決於您的需求。在你提到的文章中（我是作者，感謝你的補充！），我描述了一般方法，它有一個更好的工作流程described here，這使得它更容易實現，但不會改變事實，你做更多的CRUD在增加服務通信鏈時需要一個請求。

那麼，這可能是什麼問題？雖然這是最一致的方法（你永遠得到一個非常新的數據的狀態），你有一個缺乏可用性，您的存儲服務耦合到技能服務。如果失敗，也沒有先進的緩存設置（如與紅椎），你有2個服務失敗，如果技術服務崩潰。此外，請求會產生更大的網絡開銷。

另一種方法稱爲事件貨源，你的技能服務於約技能實體變化的消息信道通知，所以，所有的消費服務，可以通過應用更新日誌計算的當前狀態。雖然這會導致較少的網絡開銷和保證的可用性，但您的數據「最終一致」。

爲此，您可以採取的Apache卡夫卡（這也是由JHipster支持）並切換到基於事件的實體進行通信。這種方法是很難實現，因爲當他們爲基於REST和安全通信