惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
GbyAI
GbyAI
Stack Overflow Blog
Stack Overflow Blog
Recent Announcements
Recent Announcements
D
DataBreaches.Net
量子位
C
Cybersecurity and Infrastructure Security Agency CISA
G
Google Developers Blog
小众软件
小众软件
Application and Cybersecurity Blog
Application and Cybersecurity Blog
MyScale Blog
MyScale Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Cisco Talos Blog
Cisco Talos Blog
P
Proofpoint News Feed
V
Vulnerabilities – Threatpost
Security Latest
Security Latest
T
Tenable Blog
Vercel News
Vercel News
AWS News Blog
AWS News Blog
Forbes - Security
Forbes - Security
M
MIT News - Artificial intelligence
S
Security Affairs
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Hacker News - Newest:
Hacker News - Newest: "LLM"
美团技术团队
L
Lohrmann on Cybersecurity
博客园 - 司徒正美
Last Week in AI
Last Week in AI
罗磊的独立博客
Project Zero
Project Zero
Cyberwarzone
Cyberwarzone
S
Schneier on Security
S
Secure Thoughts
T
Threatpost
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
Google DeepMind News
Google DeepMind News
B
Blog RSS Feed
Y
Y Combinator Blog
F
Full Disclosure
N
Netflix TechBlog - Medium
博客园 - 叶小钗
A
Arctic Wolf
腾讯CDC
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
T
The Exploit Database - CXSecurity.com
Jina AI
Jina AI
Apple Machine Learning Research
Apple Machine Learning Research
C
Check Point Blog
C
CERT Recently Published Vulnerability Notes
www.infosecurity-magazine.com
www.infosecurity-magazine.com

博客园 - royalrover

How LLMs Actually Work(翻译) 微调LLM前你需要了解的一些概念-- 反向传播解析 微调LLM前你需要了解的一些概念-- 基于 Qwen3 配置文件的实践 微调LLM前你需要了解的一些概念2--多头注意力机制 微调LLM前你需要了解的一些概念1 -- 综述 从控制论看 Harness Engineering:当反馈回路终于能在"重要的地方"闭合 快速搭建你的数据智能分析 Agent 5分钟Mac本地跑通32B Qwen!免费GPT-4o替代,还能5分钟造个会开浏览器+执行Shell的AI Agent 深入剖析 nanobot:轻量级 AI Agent 框架的架构之道 k8s上手 iOS MDM(监管锁)入门 SRE中的SLA/SLO/SLI 开放网关统一认证服务 Feature Police导致iframe页面无法使用粘贴功能 页面异步请求canceled 或 network中接口请求成功但无法查看返回值 我在阿里云做云开发平台 阿里云云开发平台助力企业Serverless架构升级实战 随心一笔 nodejs中的并发编程 基于Unix Socket的可靠Node.js HTTP代理实现(支持WebSocket协议) cluster模块设置子进程的stdio - royalrover - 博客园 nginx(tengine)访问日志分片 serverless在微店node领域的探索应用 node应用远程调试教程 Node EE方案 -- Rockerjs在微店的建设与发展
业务网关之AK中心建设
royalrover · 2022-03-31 · via 博客园 - royalrover

啥是AK

AK(Access Key)是一种身份证明,它解决了“资源的使用者是谁”这个问题,比如在生活中,身份证可以证明你是你,而在云计算或程序中,AK能证明你是这个应用的拥有者。

AK和密码的有啥区别呢,密码面对的主体是人,人可以使用密码登录系统证明身份;AK的主体是程序或服务,程序或服务可以使用AK作为身份证明调用开放接口。

AK分类

AK分类主要和密码学的加密方式相关,常见的有两类:

  1. 对称AK(包括AKId、AKSecret)。AKId、AKSecret是成对出现的,由AK中心提供给用户,采用基于共享密钥的认证方式。每次调用相关接口时,用户会采用保存的AKSecret针对某些参数做签名,开放网关接收到请求后会用AKId查找存储的AKSecret做签名,验签通过后在通过认证。
  2. 非对称AK(AKId、AKPrivateKey和AKPublicKey),其中AKPrivateKey和AKPublicKey是一对公私钥,用户需将AKId、AKPublicKey上传给AK中心,在调用接口时用私钥做签名,开放网关收到请求后调用AK中心的服务,用公钥验签,通过后则认证通过。

综上来看,无论采用何种加密方式,AK中心始终存储一个密钥对,而且用户侧需严格保存密钥对,不要明文硬编码,需借助工具对敏感信息加密,尽可能避免敏感数据泄露。

AK中心

AK中心不是孤立存在的,在整个开放网关体系下AK中心是流量必经之地,因此它的重要性不言而喻。
网关AK中心建设的意义在于满足更多租户、服务的定制化需求,如服务权限管控、调用方管理等,更是为了统一当前 开放体系中“散落在各个系统的各自定制的开放认证机制”,此后所有的服务开放认证体系可收敛于AK中心。

AK中心架构图
image.png

为了统一集团前端的开放认证体系,AK中心提供了适配层解决存量应用的client_token认证体系,同时兼容BUC认证,支持用户在服务端及浏览器端的调用认证,需要注意的是浏览器端仅支持BUC认证(AK需要签名,不能在前端做签名)

权限体系

权限体系由“开放服务、接口管控、用户体系、调用方体系和黑名单体系”构成。调用方可设置管理员与开发者,同时调用方在申请时需指定调用的开放服务,审批通过后调用方使用该AK密钥对指定调用对应的开放服务;开放服务管理员可设置开放接口的调用权限,目前分为“内部接口与开放接口”,仅开放接口可被调用方调用;黑名单可由具体开放服务管理员设置某个黑名单的调用方,禁止其调用。

稳定性建设

AK中心作为网关之后的第一道基础设施,它的稳定性与性能必须得到保障,其中稳定性要求AK中心运行时要足够稳定可靠,不因依赖的系统故障而崩溃。当前计划从几个方面做稳定性建设:

  1. 依赖解耦与降级
  2. 错误兜底数据
  3. 网关层流量拦截

关于依赖解耦,主要是DB。当前AK中心使用DB存储AK密钥对、用户、调用方以及服务方等基础信息与权限信息,其中与运行时相关的是“AK密钥对与权限数据”,且这部分数据的特点是不易改变(设计的初衷是权限数据仅支持增加)。因此对这部分热点数据做二级缓存策略(加速层),在内存建立LRU缓存,同时建立分布式缓存(当前未实现),并制定数据刷新策略(DB回源后刷新二级缓存),若DB故障,可采用二级缓存的数据,不影响存量业务。

若依赖的分布式缓存Tair发生故障时,自动降级为 “L1 LRU内存缓存+DB”的策略,若此时DB也发生故障则降级为 L1内存缓存,支撑热点数据与请求。

AK中心设计之初是有预估请求量的,若某些开放接口被攻击或大量调用导致AK中心的计算资源(加密与签名)被耗尽造成不可用,需在网关接入层进行流量过滤,针对预设的QPS进行限流,防止AK中心被搞挂。

性能优化

所有调用开放接口的请求都会经过AK中心,因此AK处理性能直接影响开放接口的性能。优化的策略根据不同的认证方式也有所不同:

  1. AK认证与client_token认证优化策略:L1 RLU内存缓存 + 三方缓存,其中内存缓存需要重点建设,由于AK及token等热点数据命中率非常高,因此内存缓存使用率非常高。由于Node多进程模型的特点,若要在每个业务进程中单独做缓存,命中率会非常差,因此需要基于Agent模型建设Work进程间共享的全局内存缓存。
  2. BUC认证优化策略:通过持久化到Cookie进行缓存,当SSO_TOKEN未超时直接从Cookie反序列化,避免调用到BUC中心