Http  API閘道器服務模組設計方案

1. 概述                          

閘道器作為服務生產者和服務消費者之間的介面，一方面通過“服務路由”為服務消費找到所需服務的具體位置並呼叫；另一方面為後臺伺服器提供負載均衡、安全、流量控制、身份認證等相關功能。

2. 模組需求描述

3. 整體架構

圖1

4. 模組設計

4.1 服務路由模組

4.1.1 業務功能請求、應答流程

客戶端的所有請求都首先經過服務閘道器，然後由它將請求路由到合適的微服務，閘道器經常會通過呼叫多個微服務併合並結果來處理一個請求。

圖2

4.1.2 業務服務請求流程的剖析

1. 在（1）、（2）過程中，閘道器收到消費者的服務請求後，需要解析消費者所請求的具體服務，因此需要定義一個訊息結構，如：

Request struct {                                  

//如果請求多個服務，對服務進行組裝，

//閘道器拿到後對其解析，這對每個服務做出請求

Service_name  string; //服務名稱，唯一

Service_ID     float;  // 服務ID,唯一

Service_Position  url/ip;//服務所在的地址、url

Service_request  requester;  //服務請求者

Service_load  param_data;  //服務呼叫所需的引數

}

閘道器通過解析這個Request結構體找到服務ID 、服務所在的具體位置，解析過程需要用到一個服務登錄檔，結構大體如下：

Service_Table   {

Service_name : “add_service

Service_version：版本

Sevice_position:  “.../path/add.html”或者可以直接是一個IP地址

Service_descrition:   服務描述

Service_creator  :   責任人

}

服務登錄檔來自於服務註冊模組，當後臺需要新增一個服務時，需要向服務註冊模組註冊，服務註冊模組將其新增到服務登錄檔中，在之後的服務呼叫中通過讀取服務登錄檔找到服務所在的具體位置。服務登錄檔的儲存、讀取實現通過資料庫模組來實現。

2、在（2）中的協議解析完成後，在第三步（3）中根據獲取到的服務地址與具體的服務通訊，不關心所提交的Service_load 裡面的具體內容，這個內容由服務自己進行解析，服務端根據服務功能提供服務結果（第4步），請求可以失敗，無論如何會提供一個服務的返回結果。

3、在5、6、7步中，閘道器收到各個服務請求的返回結果後，進行合併，將結果返回給服務消費者。

服務請求與返回結果的結構體格式定義可以分開來做，閘道器只負責服務路由，請求的內容和返回結果由服務消費者和服務提供者自己來封裝、解析，事先二者做好協議定義。

4.1.3 微服務訪問結果的合併

每個業務請求內可能包含對多個微服務的請求，API 閘道器收到服務請求後，對請求服務進行解析，併發對每個服務進行請求，每個服務的請求結果返回後，API閘道器對服務結果進行合併，將其返回給服務請求者。

如果每個業務請求只包含一個對後臺服務的請求，可以通過Nginx配置檔案的方式將請求路由到後臺伺服器；如果每個業務請求包含對多個微服務的請求，則需要定義請求結構體和結果返回結構體，以完成服務請求者和服務提供者間的通訊。圖3展示了，請求中包含多個微服務時，API閘道器的響應流程。

圖3

(1) 服務請求Request A 向 API閘道器傳送服務請求資訊，裡面包括對三個服務的請求，及請求服務的名字和每個請求要用到的引數；

(2、3)閘道器收到服務請求後通過服務的名字，在服務登錄檔中找到服務所在的伺服器位置；

(4、5)後臺服務收到請求後對服務進行處理，並將結果返回

(6) 閘道器將請求的結果合併返回給服務請求者，並不是請求的每個微服務都會正確迴應，但是閘道器會把所有的微服務結果都返回

4.2 服務管理模組

4.2.1 服務註冊

後臺伺服器提供很多微服務，服務管理模組對這些微服務進行統一的管理，主要是服務的註冊、登出、修改。圖4為服務註冊流程，後臺微服務較多，並且服務內容不會經常變動，從開發角度講，不可能針對每個微服務提供服務註冊方法，因此服務註冊由服務提供商發起，服務註冊模組提供兩方面的介面：

1.與服務註冊商互動的介面。接收請求，返回請求操作結果。

2.操作資料庫的介面。（本質上就是，服務註冊商通過服務註冊模組實現服務登錄檔的操作）

圖4

目前未涉及到服務提供商的問題，可以由管理員直接將服務登錄檔寫入到資料庫中，管理員對其進行運維，如圖5。對於資料庫的選擇，遵循以下原則：資料一致性、冗餘備份策略

圖 5

4.2.2 服務可用性的週期性檢測

服務註冊模組可以實現對服務登錄檔的操作，方式是讀取服務登錄檔所在的資料庫資料，獲得所有服務所在的位置，建立服務測試請求（定義服務測試請求規範），如果服務能夠正常訪問則跳過；如果服務不能正常訪問，則告知管理員。

4.3 訪問日誌記錄模組與訪問控制模組（具體細節參考實際業務場景）

訪問日誌記錄：

記錄對API閘道器訪問的日誌，通過分析日誌獲得一些有用的資訊，如通過流量監控判斷是否存在類似ddos的攻擊，判斷是否存在安全測試行為

訪問控制模組：

訪問合法性的檢查，無論是對內網還是外網的介面都需要做身份認證，而認證在一些規模大點的公司都會有統一的單點登入系統，如果每個微服務系統都是做對接單點登入系統的工作，那麼顯然比較浪費資源，開發效率低。可以將認證的部分抽取到閘道器層，然後微服務系統無需關注認證的邏輯只關注自身業務即可。
    對一些特定的介面設定白名單，訪問次數，訪問頻率等各類設定，這些非業務功能的配置以及變更不會影響微服務的實現可以在閘道器層單獨做操作。

4.4 心跳模組（具體細節參考實際業務場景）