2. 路由更新和熱過載
1.1 如何實現身份認證？
最簡單的場景，使用者輸入使用者名稱密碼登入，閘道器讀庫或者請求使用者服務http介面，驗證成功後，返回使用者乙個token。每次使用者請求資源介面都要帶著這個token。
如何校驗這個token呢？
把token放在記憶體資料庫（如redis），每次請求從cookie解析出來token讀庫進行token驗證。
使用jwt,通過簽名計算認證。
都可以實現會話保持，集群線性擴充套件條件下，會話不會過期
第一種方式實現明顯每次請求認證都會產生一次讀取redis的請求。
第二種方式解決了第一種方式的問題，但是不能靈活控制token的過期時間。
第二種方式如何解決了第一種方式的問題，首先需要理解為什麼jwt方案下，服務端可以是無狀態的，因為jwt通過簽名來驗證資訊的有效性。
先介紹jwt token的生成規則，分成三個部分，header.payload.signature,。將 base64 加密後的 header 和 base64 加密後的 payload 使用.連線組成的字串，通過 header 中宣告的加密方式進行進行加密。
左邊的是token，右邊的是明文。驗證token有效性時和生成token時是一樣的，把自己必要放進去，生成token和使用者傳過來的token進行值比對，如果相等，說明token有效。
jwt token依靠客戶端儲存，就不需要讀庫了。這是用計算代替儲存的典型例子。
1.2 會話的過期策略？
使用者的session一般放在redis快取中，必然要設定過期時間的。
從使用者的角度考慮，前一秒還在使用後一秒因為session過期要重新登入肯定是不合理的。
但是也會產生另外乙個問題。token過期怎麼辦？
自然的解決辦法是往token裡加過期時間。但是過期時間一旦設定，無法提前銷毀。
set-cookie
session是基於cookie的，http因為沒有狀態，請求之間要保持記憶性只能在客戶端存點資訊。
關於httpset-cookie與瀏覽器的約定，參考set-cookie。
關於單點登入如何在閘道器實現
按照這位仁兄的說法,我覺得如果是閘道器情況下，完全不需要ticket傳送給子系統，因為請求都是通過閘道器，閘道器就能完成許可權認證。
知乎千萬級高效能長連線閘道器揭秘
可以使用lua vm儲存路由資訊，nginx啟動會將lua指令碼載入進去。
1. 路由如何更新及初始化
我實現了乙個簡單的路由curd和初始化邏輯，可以參考我的實驗筆記。
核心思想就是nginx程序一啟動，就將路由資訊載入到從redis更新到記憶體。然後每次路由更新，也是法發http請求去呼叫lua實現的curd介面，這些介面會更新本地路由同時，也會放到redis上面。
缺點： 沒有事務，無法保證原子性，我對redis也不太熟。redis需要開啟持久化。
優點： 可以實現路由熱過載。
2. 如何進行(快速)路由匹配？
lua table
字首樹
按照資料結構來說，字首樹快一點。但是實際上，lua table查詢路由資訊也挺快，我上面的介面就是使用的lua table.
路由查詢到了以後，服務有哪些例項，有什麼規則就都知道了，可以使用resty.http將請求傳送到下游伺服器。我簡單實現了一波，看這裡。
3. 閘道器集群化
集群化方案怎麼做到？ 就是如果乙個閘道器例項qps是1w，那麼增加乙個閘道器例項qps可以到2w。
apisix的做法是將閘道器變成無狀態的，路由都儲存在分布式資料庫etcd中，初始化乙份路由資料，然後路由增量更新就可以了。
OpenResty api閘道器設計
本文講述openresty api閘道器設計，主要涉及api閘道器介紹 openresty api閘道器 請求路由 路由判斷 路由重寫 服務判斷 限流 授權驗證 統一認證 動態upstream 以及這三部分理論簡單實現的api閘道器和api閘道器admin。1 什麼是api閘道器 在這個微服務這麼火...
Gateway閘道器設計 一
閘道器gateway，它負責與客戶端建立連線，接收客戶端傳送過來的訊息，並對訊息進行驗證，等。1，閘道器的功能 1.1 與客戶端建立連線 這個應該是閘道器最基本的網功了，乙個服務做為閘道器，所有客戶端來的訊息都必須先到達這裡。客戶端與閘道器採用tcp長連線。1.2 訊息過濾 客戶端可能給伺服器傳送任...
使用閘道器設計流程
1 使用閘道器設計流程路徑 2 基於資料的專用閘道器 某些事情只能在某些情況下才能完成，所以很少有過程總是走同一條路。圖2.1 xor閘道器。在我們的簡單示例 圖2.1 中，我們希望深入烹飪的細節。在飢餓的驅使下，我們思考今天要做什麼。我們只知道三種食譜，所以我們選擇一種。我們要麼做義大利面，要麼做...