是否可以通過oData.net實現微服務

Question

我一直在閱讀關於Microservice Architecure以及互聯網上有限的有價值信息，我相信我從理論的角度對它有一個公正的理解。據我所知，從高層次上看，這種架構意味着從monoliths轉向，並且擁有小型的獨立服務。但是，我在互聯網上看到的所有示例都建議連接到ESB，以編寫鬆散耦合的Windows服務（在非MS實現的情況下，守護進程）。據我所知，編寫符合SRP的小型，鬆散耦合的Web服務也適合微服務帳單。這就是說，oData.Net服務（所有oData控制器（微服務？）被部署爲一個整體）顯然違反了微服務架構模式。這是否是正確的聲明，使oData.net不是作爲微型服務工作的？如果你的答案是否定的，請在一個例子的幫助下解釋。另外，請幫助我理解，如何在組合中使用API​​網關模式。

Answer 1

ODATA確實適合微服務。但是，微服務不適合odata。我的意思是，沒有什麼能夠阻止你在微服務中暴露OData。

但是，通過這樣做，您通常會在微服務中暴露一大組內部數據結構。這反過來會增加不同服務之間的耦合。通過這樣做，由於依賴關係，您更難以更改服務。

我個人的經驗法則是要儘可能從每個服務中公開一個小的API。我公開的數據結構與內部數據結構不一樣。它們可能會變平或在不同內部實體中的數據之間進行聯合。

我的推理是：如果您要創建單獨的服務，請嘗試儘可能多地分開它們。否則，你只是建立一個巨石，碰巧運行在幾個不同的窗口服務。

Answer 2

oData作爲暴露微服務的方法是完全有效的;暴露一個明確的表，但不是微服務。所以我完全不同意jgauffin。沒有理由使用oData無法提供API。我同意JGauffin的觀點是，API應該有一個與源或目標的詳細數據結構分離的小而平面的空間。因此，服務調用它來轉換API，但意味着API的通用格式可以重用，只要業務需求在那裏，並且技術平臺根據需要進行切換。