將請求路由到微服務架構中的相關服務的方法

Question

假設我們有5個服務（用戶和授權，產品，訂單，庫存，歷史記錄）公開基於REST的API，並通過這些暴露的API在內部服務之間進行內部通信。現在，在Microeservice架構模式中開發這些應用程序時，這些將是不同的單獨服務，它們將自我依賴並通過REST /隊列相互通信。

首先讓我們考慮一下，我們正在單個節點上部署它，但現在所有5個服務都只部署在這個單一節點上。因此，一種方法是

1. （理想）若要通過Netflix的工具鏈（尤里卡）服務發現和註冊機制或通過Zookeper認證和授權例如：/ API/V1 /後請求定向到相關服務產品/ {id}被定向到產品服務，/ api/v1/order/{id}被定向到定購服務等等。
2. 另一個（雖然不是服務分佈在多個節點上的場景的正確選擇，但考慮如果我們在單個節點上擁有所有服務並計劃快速上線，然後在下一個階段進行下去對微服務的發現/註冊，API網關，斷路器方法），其中我們開發所有服務作爲單獨的Web應用程序部署爲在tomcat（基於Spring的應用程序）中的單個戰爭，並讓tomcat處理基於URL的重定向，例如https://ip:port/產品服務/api/v1/products/{id}由tomcat重定向到productservice webapp等。

請問選項2將是一個可行的選擇與發展作爲一個單獨的Web應用程序不同的服務現場去，自力更生與部署在一個Tomcat實例它自己的架構和UI層被消耗和再下一階段使用個人和單獨服務的基本代碼，並轉向發現/註冊方法。

，但我在選項2其中每個服務是一個獨立的戰爭（沒有發現/註冊表）預見的挑戰是路由 - 爲每個請求如主入口https://ip:port/productservice/API/v1/products/{id}在去productservice webapp需要通過一個「認證服務」應用程序，然後被路由到適當的服務，並在單獨的戰爭機制中處理此路由（儘管在單個實例中）具有以下選項

1. 每個請求都需要登錄到認證服務應用程序（如何？可以是URL重定向），然後編寫一些路由邏輯將認證請求發送到基於REST的所需應用（服務）。此路由可以是基於駱駝的或基於數據庫的 - 分析字符串並調用所需服務的REST API。認證應用程序將作爲一個API網關。
2. 其他是你提到的那個（隊列丟失）。所有請求都登錄到身份驗證服務應用程序（如何？可以是URL重定向），然後寫入專用於每個服務的單個隊列，其中每個服務都訂閱了它的特定隊列。

Answer 1

選項2，所以在每個節點的單個tomcat實例上運行所有獨立的webapps是朝着全面的微服務架構邁出的非常好的第一步。實際上你無論如何都需要這一步來稍後實現服務發現/註冊。正如你寫的 - 它已經給你一定程度的隔離和執行獨立遷移的能力（單獨的戰爭）。

只要確保將用於獲取服務URL的代碼包裝到類中，以便只有在添加服務發現（與應用中多個位置的服務的硬編碼URL）時才能在一處進行更改。

在選項2上停留一段時間的缺點是您將失去在每個服務級別上擴展的能力。您需要回答這個問題，在您的特定情況下它有多重要。

我在你的文章中沒有看到你使用隊列的方法。老實說，如果你的解決方案可以使用異步通信，我會強烈鼓勵它（請注意，Netflix堆棧主要針對直接REST通信）。