基於Java中RESTful API的微服務體系結構

-1

實現WebService的最佳體系結構，它接受來自一方的請求，保存並增強該請求，然後用新參數調用另一服務。這裏有沒有特別的Design Pattern？基於Java中RESTful API的微服務體系結構

來源

2017-05-16 Mohsen Sabbaghi

聽起來像[事件驅動的體系結構]的一個很好的用例（https://en.wikipedia.org/wiki/Event-driven_architecture） –

所有服務都屬於您的應用程序，或者最後一個請求將會發送到外部服務？您可以檢查api網關模式以增強您的請求。在第一個請求到達api網關服務之後。 Api網關可以提出額外請求並增強原始請求並傳遞它。 – barbakini

是@barbakini，正好最後一個請求將被提交給外部服務。 –

有沒有很多要繼續，但從你說的這聽起來像是一個工作"pipes and filters"！

爲了得到更精確的答案，你可能要問自己一些更詳細的問題：

如果你需要做的傳入消息的任何確認或轉型？你想要以相同的方式處理所有請求，還是有不同的類型？外部服務是否可能發生變化，如果是，他們會經常這樣做嗎？如果最終的Web服務調用失敗（您是否應該回滾數據庫記錄？），您希望執行什麼操作？你如何報告失敗/迴應 - 你需要回報這些嗎？您是否需要一種機制來跟蹤特定請求的進度？

來源

2017-05-16 11:42:29 hugh

既然您正在尋找設計模式，我想您可能想比較在項目環境中使用微服務編排vs編排的優缺點。

來源

2017-05-17 20:34:24 clonq

如果您不需要立即響應呼叫系統，我建議您使用event-driven方法，如果這是可行的。因此，而不是REST服務，您將有一個消息代理，您的服務將訂閱特定事件。這將隱藏你的消費者在消息代理之後，這將使你的系統更少耦合。這可以通過Spring Cloud Stream來實現，在這裏你將有一個接收器（微服務產生事件，變換器 - 微服務使中間變換成爲可能，源 - 微服務接收最終結果以供進一步處理）。

另一種可能的情況可能是駱駝。它基本上具有所有內置的集成模式，所以基於REST API或事件實現解決方案應該不成問題。

來源

2017-06-11 17:55:16

基於Java中RESTful API的微服務體系結構

回答

相關問題