TWI728445B - 訊息轉導方法及應用程式介面閘道器 - Google Patents

Abstract

本發明提供一種訊息轉導方法及應用程式介面閘道器實 例，適於部署於微服務系統中的第一實例，其中第一實例為應用程式介面閘道器實例。所述方法包括：偵測微服務系統中訊息佇列的特定主題中是否出現第一訊息，其中第一訊息封裝有第一訊息內容及第一接收者身分；解封裝第一訊息以取得第一訊息內容及第一接收者身分；判斷對應於第一接收者身分的第一使用者是否已透過第一瀏覽器註冊於第一實例上；反應於判定第一使用者已註冊於第一實例上，透過第一實例與第一瀏覽器之間的第一Websocket連線將第一訊息內容轉導至第一瀏覽器。

Description

訊息轉導方法及應用程式介面閘道器

本發明是有關於一種微服務系統的運作方法，且特別是有關於一種微服務系統中的訊息轉導方法及應用程式介面(application programming interface，API)閘道器實例(instance)。

一般而言，瀏覽器與網頁伺服器所建立之WebSocket連線為一對一的連線。然而，在支援高可用性的微服務系統架構下，將架設有多個閘道器(例如API閘道器實例)。在此情況下，可能面臨每次的瀏覽器請求皆傳送到不同的API閘道器實例的問題。並且，其他微服務欲發送給瀏覽器的訊息也可能透過不同的API閘道器實例轉送，此時將面臨WebSocket訊息的同步問題。

有鑑於此，本發明提供一種訊息轉導方法及API閘道器，其可用以解決上述技術問題。

本發明提供一種訊息轉導方法，適於部署於一微服務系 統中的一第一實例，其中第一實例為一應用程式介面閘道器實例，包括：偵測微服務系統中一訊息佇列的一特定主題中是否出現一第一訊息，其中第一訊息封裝有一第一訊息內容及一第一接收者身分；解封裝第一訊息以取得第一訊息內容及第一接收者身分；判斷對應於第一接收者身分的一第一使用者是否已透過一第一瀏覽器註冊於第一實例上；反應於判定第一使用者已註冊於第一實例上，透過第一實例與第一瀏覽器之間的一第一Websocket連線將第一訊息內容轉導至第一瀏覽器。

本發明提供一種應用程式介面閘道器，其部署於一微服務系統中，包括訊息佇列模組、註冊模組及Websocket模組。訊息佇列模組經配置以：偵測微服務系統中一訊息佇列的一特定主題中是否出現一第一訊息，其中第一訊息封裝有一第一訊息內容及一第一接收者身分；解封裝第一訊息以取得第一訊息內容及第一接收者身分。註冊模組判斷對應於第一接收者身分的一第一使用者是否已透過一第一瀏覽器註冊於第一實例上。Websocket模組在註冊模組判定第一使用者已註冊於第一實例上後，透過第一實例與第一瀏覽器之間的一第一Websocket連線將第一訊息內容轉導至第一瀏覽器。

基於上述，本發明的API閘道器實例可在偵測到特定主題中出現新的封裝訊息之後，可將其解封裝以取得其中的接收者身分。接著，若某API閘道器實例判定此接收者身分的使用者已註冊於自身上，則此API閘道器實例可透過已建立的Websocket 連線將訊息內容予以轉導。

為讓本發明的上述特徵和優點能更明顯易懂，下文特舉實施例，並配合所附圖式作詳細說明如下。

100:微服務系統

11~1N:API閘道器實例

111:請求處理模組

112:訊息佇列模組

113:註冊模組

114:HTTP請求轉導模組

115:Websocket模組

120:訊息佇列

130:微服務

S210~S250:步驟

圖1是依據本發明之一實施例繪示的微服務系統示意圖。

圖2是依據本發明之一實施例繪示的訊息轉導方法。

概略而言，本發明提供一種基於訊息佇列實作微服務架構下的高可用性應用程式介面閘道器的系統與方法，解決瀏覽器與應用程式介面閘道器間透過WebSocket連線時的訊息同步問題、跨網域的WebSocket連線橋接問題以及跨網域超文本傳輸協定(HTTP)同步、非同步請求轉導問題。

請參照圖1，其是依據本發明之一實施例繪示的微服務系統示意圖。如圖1所示，微服務系統100包括部署於其中的一或多個API閘道器實例11~1N、訊息佇列120及微服務。在本發明的實施例中，一個API閘道器實例可對應於一或多個微服務。以API閘道器實例11為例，其可對應於一或多個微服務130。在一些實施例中，API閘道器實例11可用於協助將來自微服務130的訊息轉導至特定的使用者，其相關細節將在之後詳述。

在本發明的實施例中，各API閘道器實例的結構類似，故以下將暫以API閘道器實例11為例進行說明。如圖1所示，API閘道器實例11可包括請求處理模組111、訊息佇列模組112、註冊模組113、HTTP請求轉導模組114及Websocket模組115。概略而言，請求處理模組111係負責處理所有HTTP請求的收發，訊息佇列模組112可全時間聆聽訊息佇列120，負責收發訊息。請求處理模組111與訊息佇列模組112為API閘道器實例11的統一介面。對外，系統使用者可使用瀏覽器並透過HTTP請求觸及API閘道器實例11。對內，同個微服務系統100架構下之其他微服務則可透過HTTP請求與訊息佇列120與API閘道器實例11通訊。

在一些實施例中，在使用者透過所使用的瀏覽器連線至以微服務架構部署高可用性API閘道器的微服務系統100後，每個瀏覽器請求將隨機與微服務系統100中的任一API閘道器實例連線。為便於說明，以下假設使用者的瀏覽器係連線至API閘道器實例11。在此情況下，請求處理模組111會先從使用者的瀏覽器收到HTTP連線請求，之後將據以與使用者的瀏覽器建立Websocket連線。同時，請求處理模組111還可依據HTTP連線請求呼叫註冊模組113。相應地，註冊模組113將根據HTTP連線請求中的使用者識別碼(userId)欄位組成註冊資訊，並暫存於API閘道器實例11的記憶體中，進而完成一次連線註冊動作。在一實施例中，API閘道器實例11的記憶體中可儲存有用於記錄註冊於API閘道器實例11上的各使用者的註冊資訊(例如包括使用者識 別碼)，但本發明可不限於此。

之後，若微服務系統11中有某微服務需要發送訊息給連線至微服務系統100的特定使用者時，可採用以下的第一、第二實施例所提供的機制來進行。

在第一實施例中，假設微服務130欲發送訊息給某個使用者，則微服務130可在將此使用者的使用者識別碼作為接收者身分之後，將其與相關的訊息內容一併以HTTP請求(下稱第一HTTP請求)發送至對應於微服務130的API閘道器實例11。

在API閘道器實例11的請求處理模組111接收上述第一HTTP請求之後，可由註冊模組113確認API閘道器實例11(的記憶體)中是否儲存有對應於此使用者識別碼的註冊資訊。在一實施例中，若註冊模組113在API閘道器實例11中查到匹配於接收者身分的註冊資訊，即代表此使用者已向API閘道器實例11註冊，且此使用者的瀏覽器與API閘道器實例11之間已存在Websocket連線。因此，Websocket模組115即可透過前述Websocket連線將相關的訊息內容轉導至使用者所使用的瀏覽器。

在另一實施例中，若註冊模組113未能在API閘道器實例11中查到匹配於接收者身分的註冊資訊，即代表此使用者並未註冊於API閘道器實例11(即，尚未與API閘道器實例11建立Websocket連線)。在此情況下，訊息佇列模組112可將相關的訊息內容及接收者身分封裝為一封裝訊息，並發送至訊息佇列120中進行儲存。

在本發明的實施例中，訊息佇列120中可包括不同的主題，而各主題可視為是可用於儲存特定類型訊息的子佇列，但本發明可不限於此。在第一實施例中，訊息佇列120中可包括一「MessageSyncEvent」主題，其可用於儲存由API閘道器實例封裝而得的封裝訊息，但本發明可不限於此。

在第二實施例中，在其餘各API閘道器實例中的訊息佇列模組偵測到「MessageSyncEvent」主題中出現新的封裝訊息之後，即可透過本發明提出的訊息轉導方法來進行後續處理。相似地，若有其他API閘道器實例將所封裝的訊息佇存至「MessageSyncEvent」主題，則佇列訊息模組112亦可在偵測到「MessageSyncEvent」主題中出現新的封裝訊息後，透過本發明提出的訊息轉導方法來進行後續處理，而其相關細節將在之後搭配圖2作進一步說明。

此外，在第二實施例中，假設微服務130欲發送訊息給某個使用者，則微服務130可自行將相關的訊息內容及此訊息的接收者身分封裝為一封裝訊息，並將此封裝訊息轉發至訊息佇列120。在第二實施例中，訊息佇列120中可包括一「ApiGwRequest」主題，其可用於儲存由微服務自行封裝而得的封裝訊息，但本發明可不限於此。

之後，當各API閘道器實例中的訊息佇列模組(例如訊息佇列模組112)偵測到「ApiGwRequest」主題中出現新的封裝訊息之後，亦可透過本發明圖2提出的訊息轉導方法來進行後續 處理。

請參照圖2，其是依據本發明之一實施例繪示的訊息轉導方法。本實施例的方法可由圖1的API閘道器實例11執行，以下即搭配圖1的內容說明各步驟的細節。

首先，在步驟S210中，佇列訊息模組112可偵測微服務系統100中訊息佇列120的特定主題中是否出現第一訊息。在本實施例中，前述特定主題可以是第一實施例中的「MessageSyncEvent」主題或是第二實施例中的「ApiGwRequest」主題，但本發明可不限於此。

假設特定主題為第一實施例中的「MessageSyncEvent」主題，則所考慮的第一訊息可以是其他API閘道器實例為所對應的微服務所產生的封裝訊息，其可封裝有第一訊息內容及第一接收者身分。另一方面，若上述特定主題為第二實施例中的「ApiGwRequest」主題，則所考慮的第一訊息則可以由某個微服務自行將第一訊息內容及第一接收者身分封裝而得。

之後，在步驟S220中，佇列訊息模組112可解封裝第一訊息以取得第一訊息內容及第一接收者身分。接著，在步驟S220中，註冊模組113可判斷對應於第一接收者身分的第一使用者是否已透過第一瀏覽器註冊於API閘道器實例11上。例如，註冊模組113可確認API閘道器實例11(的記憶體)中是否儲存有對應於第一接收者身分的使用者識別碼。若是，即代表第一使用者已向API閘道器實例11註冊，且第一使用者的瀏覽器(下稱第一瀏 覽器)與API閘道器實例11之間已存在Websocket連線(下稱第一Websocket連線)。因此，Websocket模組115可接著在步驟S240中透過API閘道器實例11與第一瀏覽器之間的第一Websocket通道將第一訊息內容轉導至第一瀏覽器。

相反地，若對應於第一接收者身分的第一使用者未透過第一瀏覽器註冊於API閘道器實例11上，即代表第一使用者並未註冊於API閘道器實例11(即，尚未與API閘道器實例11建立Websocket連線)。因此，Websocket模組115可執行步驟S250以忽略第一訊息。

由上可知，在本發明的實施例中，當微服務欲發送訊息給特定的使用者，但此使用者未註冊於此微服務對應的API閘道器實例時，可由對應的API閘道器實例將相關的訊息內容及接收者身分封裝為封裝訊息(即，第一實施例的作法)，或是由微服務自行將相關的訊息內容及接收者身分封裝為封裝訊息(即，第二實施例的作法)。之後，上述封裝訊息可被儲存至訊息佇列中的對應的特定主題，而各API閘道器實例可在偵測到特定主題中出現新的封裝訊息之後，可將其解封裝以取得其中的接收者身分。接著，若某API閘道器實例判定此接收者身分的使用者已註冊於自身上，則此API閘道器實例可透過已建立的Websocket連線將訊息內容予以轉導，反之則可予以忽略。

此外，在其他實施例中，本發明更提出在瀏覽器之間的同步/非同步轉導機制。具體而言，在一實施例中，假設一第二使 用者已透過第二瀏覽器註冊於API閘道器實例11，而API閘道器實例11已相應地與第二瀏覽器建立第二Websocket連線。在此情況下，第二瀏覽器可發送一第二HTTP請求至請求處理模組111，其中此HTTP請求可包括標頭欄位，而此標頭欄位可夾帶有目的位址與認證令牌(token)。

在非同步轉導機制中，在從第二瀏覽器接收上述第二HTTP請求之後，請求處理模組111可從標頭欄位解析出上述目的位址，並可由HTTP請求轉導模組114產生對應的唯一通用識別碼(UUID)。之後，HTTP請求轉導模組114可透過第二Websocket連線將上述唯一通用識別碼回傳至第二瀏覽器。接著，HTTP請求轉導模組114可基於目的位址透過執行緒呼叫對應的目的端。並且，反應於從目的端收到回應，執行緒可將此回應及上述唯一通用識別碼封裝為封裝訊息，並由Websocket模組115透過第二Websocket連線回傳至第二瀏覽器。

在一實施例中，若第二瀏覽器意圖透過第二HTTP請求呼叫多個目的端，則HTTP請求轉導模組114可對各目的端指派專用的執行緒，而每個執行緒可用於呼叫一個目的端。並且，各執行緒在收到各自目的端的回應之後，可獨立地將回應及上述唯一通用識別碼封裝為封裝訊息，並由Websocket模組115透過第二Websocket連線回傳至第二瀏覽器。

此外，在同步轉導機制中，在從第二瀏覽器接收上述第二HTTP請求之後，請求處理模組111可從標頭欄位解析出上述 目的位址。之後，HTTP請求轉導模組114可基於此目的位址同步地呼叫位於目的位址的多個特定微服務。之後，反應於從各特定微服務接收對應於上述第二HTTP請求的一特定回應，HTTP請求轉導模組114可將各特定微服務的特定回應合併為一JSON格式，並將此JSON格式回覆予第二瀏覽器。

綜上所述，本發明可提供一種支援一個瀏覽器同時與多個WebSocket伺服端連線之方法以及提供一種在高可用性微服務架構下，支援同步與非同步的HTTP請求轉導機制。

透過RabbitMQ訊息佇列實作多個應用程式介面閘道器間的通訊機制，內含註冊模組以支援使用者識別，使用者於瀏覽器以帳號登入並與高可用性微服務架構下的任一應用程式介面閘道器連線後，該閘道器會根據使用者帳號產生使用者識別碼並儲存至記憶體，只要使用者以相同帳號登入，即便於不同瀏覽器也可同時收到訊息，也可做訊息轉導，經設定後以應用程式介面閘道器為入口同時訂閱多個位於不同網域下的WebSocket伺服器。

並且，本發明也支援瀏覽器之同步與非同步請求轉導，可依呼叫端發送之HTTP請求內的Header欄位中夾帶的目的網域，將該請求導向該網域，同步請求則直接同步呼叫，若為非同步請求則以WebSocket形式回傳至瀏覽器。此項技術特色可用於大型系統有多個內部子系統時，統一由對外的應用程式閘道器進行請求轉導，以避免子系統暴露於網際網路環境下造成資訊安全漏洞。當微服務架構部署多個應用程式閘道器實例時，由於呼叫 端每次呼叫的實例皆不同，本發明支援使用者識別與自動訊息同步，因此能正確將訊息同步至已和使用者瀏覽器建立連線的應用程式閘道器實例，由該實例轉導回使用者瀏覽器。

當大型系統只有一個對外接口時，本發明提供HTTP請求的同步與非同步轉導機制，統一由對外開放的應用程式閘道器將請求轉導至內部子系統，非同步請求則以WebSocket訊息回傳至使用者，以避免系統暴露造成資安漏洞。

雖然本發明已以實施例揭露如上，然其並非用以限定本發明，任何所屬技術領域中具有通常知識者，在不脫離本發明的精神和範圍內，當可作些許的更動與潤飾，故本發明的保護範圍當視後附的申請專利範圍所界定者為準。

S210~S250:步驟

Claims (7)

1. 一種訊息轉導方法，適於部署於一微服務系統中的一第一實例，其中該第一實例為一應用程式介面閘道器實例，包括：偵測該微服務系統中一訊息佇列的一特定主題中是否出現一第一訊息，其中該第一訊息係由該微服務系統中的一微服務封裝一第一訊息內容及一第一接收者身分而產生並轉發至該訊息佇列的該特定主題；解封裝該第一訊息以取得該第一訊息內容及該第一接收者身分；判斷對應於該第一接收者身分的一第一使用者是否已透過一第一瀏覽器註冊於該第一實例上；反應於判定該第一使用者已註冊於該第一實例上，透過與該第一瀏覽器之間的一第一Websocket連線將該第一訊息內容轉導至該第一瀏覽器。
2. 如申請專利範圍第1項所述的方法，更包括：反應於判定該第一使用者未註冊於該第一實例上，忽略該第一訊息。
3. 如申請專利範圍第1項所述的方法，更包括：反應於一第二使用者透過一第二瀏覽器連接至該微服務系統，從該第二瀏覽器接收一瀏覽器請求，並據以與該第二瀏覽器建立一第二Websocket連線，其中該瀏覽器請求包括該第二使用者的一使用者識別； 基於該第二使用者的該使用者識別組成一註冊資訊，並儲存於該第一實例中。
4. 如申請專利範圍第3項所述的方法，其中該第一實例對應於一微服務，且該第一實例上註冊有至少一使用者，且所述方法更包括：從該微服務接收一第一超文本傳輸協定請求，其中該第一超文本傳輸協定請求包括一第二訊息內容及一第二接收者身分；判斷該第二接收者身分是否匹配於該至少一使用者的其中之一；反應於該第二接收者身分匹配於該至少一使用者中的該第二使用者的該註冊資訊，透過該第二Websocket連線將該第二訊息內容轉導至該第二瀏覽器；反應於該第二接收者身分未匹配於該至少一使用者中的任一，將該第二訊息內容及該第二接收者身分封裝為一第二訊息，並將該第二訊息轉發至該訊息佇列的該特定主題。
5. 如申請專利範圍第3項所述的方法，更包括：從該第二瀏覽器接收一第二超文本傳輸協定請求，其中該第二超文本傳輸協定請求包括一標頭欄位，其夾帶有一目的位址與一認證令牌；從該標頭欄位解析出該目的位址，並產生對應的一唯一通用識別碼； 透過該第二Websocket連線將該唯一通用識別碼回傳至該第二瀏覽器；基於該目的位址透過一執行緒呼叫對應的一目的端；反應於從該目的端收到一回應，將該回應及該唯一通用識別碼封裝為一封裝訊息，並透過該第二Websocket連線回傳至該第二瀏覽器。
6. 如申請專利範圍第1項所述的方法，更包括：反應於從一第二瀏覽器接收一第二超文本傳輸協定請求，從該第二超文本傳輸協定訊息的一標頭欄位解析出一目的位址；基於該目的位址同步地呼叫位於該目的位址的多個特定微服務；反應於從各該特定微服務接收對應於該第二超文本傳輸協定請求的一特定回應，將各該特定微服務的該特定回應合併為一JSON格式，並將該JSON格式回覆予該第二瀏覽器。
7. 一種應用程式介面閘道器，其部署於一微服務系統中，包括：一訊息佇列模組，其經配置以：偵測該微服務系統中一訊息佇列的一特定主題中是否出現一第一訊息，其中該第一訊息係由該微服務系統中的一微服務封裝一第一訊息內容及一第一接收者身分而產生並轉發至該訊息佇列的該特定主題； 解封裝該第一訊息以取得該第一訊息內容及該第一接收者身分；一註冊模組，其判斷對應於該第一接收者身分的一第一使用者是否已透過一第一瀏覽器註冊於該第一實例上；一Websocket模組，其在該註冊模組判定該第一使用者已註冊於該第一實例上後，透過與該第一瀏覽器之間的一第一Websocket連線將該第一訊息內容轉導至該第一瀏覽器。

Images