因此，我正在使用dotnet core 3.1，并與一個需要訪問網路服務的客戶端一起作業。我想知道是否有可能使用/集成一個API網關架構，使API網關指向該網路服務（SOAP訊息）？我正在研究，當然首選是使用Ocelot，但我還在檢查可行性的階段。這里需要考慮的是，我之所以使用 API Gateway 方法，是因為將有其他端點（其他客戶）確實需要它，因此在這些端點上使用微服務將更容易，所有的 RestAPI 和整個系統都是如此。
另一件我不太了解的事情是，是否可以將Web服務容器化為微服務，以實作這一目標。
我很感謝你的回答。
歡呼吧！
此外，如果有更好的方法，我更愿意 "聽一聽"。
這里有一張圖片，可以提供更好的參考，只要記住其中一個微服務不是 Web API，而是 SOAP Web 服務就可以了
uj5u.com熱心網友回復：
你當然可以在你的微服務和你的SOAP服務前面放置一個網關如果從架構的角度來看這樣做有意義的話。
如果您將 SOAP Web 服務包裝成與所有其他微服務具有類似通信型別的微服務，或者您只是直接呼叫您的 SOAP Web 服務，這取決于網關的實作。網關（你的例子：Ocelot）可以進行SOAP呼叫嗎？還是所有后端服務都需要使用相同的 "語言 "來進行通信？
從架構的角度來看，您的解決方案是合理的，也是可行的。這只是你如何 "按摩 "組件之間的通信的問題，以便網關的客戶不必關心他們的請求是否到達微服務或 SOAP Web 服務。
P.S. 我在這里談論的是 SOAP 服務和 "其他 "微服務，以強調它們與網關之間的不同集成型別，但您當然可以只使用 SOAP 來構建一個微服務架構。您可以從 SOAP 服務中獲得彈性、獨立和易于部署、可擴展性、可組合性等特點，也可以從 REST 服務中獲得這些特點（這似乎是構建微服務的首選方式；主要是出于歷史原因，因為 SOAP 通常被用作與單體的集成選項）。
uj5u.com熱心網友回復：
我將以咆哮的形式來回答。
<rant>所以我對任何類似的事情的建議是，做適合你和你公司的事情。霸主們可能會因為我說你可以在你的微服務實施中使用基于肥皂的產品而恨我，但他們不必支持你的系統，你必須支持。做有意義的事。我曾使用OSB這樣的轉換工具將SOAP轉換為ReST，我曾使用翻譯服務，你不能把技術決定看成是/否。他們需要對你和你的需求進行有意義的權衡。</rant>
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/312432.html
標籤：