業務閘道器之AK中心建設
啥是AK
AK（Access Key）是一種身份證明，它解決了“資源的使用者是誰”這個問題，比如在生活中，身份證可以證明你是你，而在雲端計算或程式中，AK能證明你是這個應用的擁有者。
AK和密碼的有啥區別呢，密碼面對的主體是人，人可以使用密碼登入系統證明身份；AK的主體是程式或服務，程式或服務可以使用AK作為身份證明呼叫開放介面。
AK分類
AK分類主要和密碼學的加密方式相關，常見的有兩類：
- 對稱AK（包括AKId、AKSecret）。AKId、AKSecret是成對出現的，由AK中心提供給使用者，採用基於共享金鑰的認證方式。每次呼叫相關介面時，使用者會採用儲存的AKSecret針對某些引數做簽名，開放閘道器接收到請求後會用AKId查詢儲存的AKSecret做簽名，驗籤通過後在通過認證。
- 非對稱AK（AKId、AKPrivateKey和AKPublicKey），其中AKPrivateKey和AKPublicKey是一對公私鑰，使用者需將AKId、AKPublicKey上傳給AK中心，在呼叫介面時用私鑰做簽名，開放閘道器收到請求後呼叫AK中心的服務，用公鑰驗籤，通過後則認證通過。
綜上來看，無論採用何種加密方式，AK中心始終儲存一個金鑰對，而且使用者側需嚴格儲存金鑰對，不要明文硬編碼，需藉助工具對敏感資訊加密，儘可能避免敏感資料洩露。
AK中心
AK中心不是孤立存在的，在整個開放閘道器體系下AK中心是流量必經之地，因此它的重要性不言而喻。
閘道器AK中心建設的意義在於滿足更多租戶、服務的定製化需求，如服務許可權管控、呼叫方管理等，更是為了統一當前 開放體系中“散落在各個系統的各自定製的開放認證機制”，此後所有的服務開放認證體系可收斂於AK中心。
AK中心架構圖
為了統一集團前端的開放認證體系，AK中心提供了適配層解決存量應用的client_token認證體系，同時相容BUC認證，支援使用者在服務端及瀏覽器端的呼叫認證，需要注意的是瀏覽器端僅支援BUC認證（AK需要簽名，不能在前端做簽名）
許可權體系
許可權體系由“開放服務、介面管控、使用者體系、呼叫方體系和黑名單體系”構成。呼叫方可設定管理員與開發者，同時呼叫方在申請時需指定呼叫的開放服務，審批通過後呼叫方使用該AK金鑰對指定呼叫對應的開放服務；開放服務管理員可設定開放介面的呼叫許可權，目前分為“內部介面與開放介面”，僅開放介面可被呼叫方呼叫；黑名單可由具體開放服務管理員設定某個黑名單的呼叫方，禁止其呼叫。
穩定性建設
AK中心作為閘道器之後的第一道基礎設施，它的穩定性與效能必須得到保障，其中穩定性要求AK中心執行時要足夠穩定可靠，不因依賴的系統故障而崩潰。當前計劃從幾個方面做穩定性建設：
- 依賴解耦與降級
- 錯誤兜底資料
- 閘道器層流量攔截
關於依賴解耦，主要是DB。當前AK中心使用DB儲存AK金鑰對、使用者、呼叫方以及服務方等基礎資訊與許可權資訊，其中與執行時相關的是“AK金鑰對與許可權資料”，且這部分資料的特點是不易改變（設計的初衷是許可權資料僅支援增加）。因此對這部分熱點資料做二級快取策略（加速層），在記憶體建立LRU快取，同時建立分散式快取（當前未實現），並制定資料重新整理策略（DB回源後重新整理二級快取），若DB故障，可採用二級快取的資料，不影響存量業務。
若依賴的分散式快取Tair發生故障時，自動降級為 “L1 LRU記憶體快取+DB”的策略，若此時DB也發生故障則降級為 L1記憶體快取，支撐熱點資料與請求。
AK中心設計之初是有預估請求量的，若某些開放介面被攻擊或大量呼叫導致AK中心的計算資源（加密與簽名）被耗盡造成不可用，需在閘道器接入層進行流量過濾，針對預設的QPS進行限流，防止AK中心被搞掛。
效能優化
所有呼叫開放介面的請求都會經過AK中心，因此AK處理效能直接影響開放介面的效能。優化的策略根據不同的認證方式也有所不同：
- AK認證與client_token認證優化策略：L1 RLU記憶體快取 + 三方快取，其中記憶體快取需要重點建設，由於AK及token等熱點資料命中率非常高，因此記憶體快取使用率非常高。由於Node多程序模型的特點，若要在每個業務程序中單獨做快取，命中率會非常差，因此需要基於Agent模型建設Work程序間共享的全域性記憶體快取。
- BUC認證優化策略：通過持久化到Cookie進行快取，當SSO_TOKEN未超時直接從Cookie反序列化，避免呼叫到BUC中心