業務網關之AK中心建設
- 2022 年 3 月 31 日
- 筆記
- javascript, node
啥是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中心
