架构 (IT)系统架构师

构思一个全球分布、低延迟的授权决策引擎,该引擎能够评估数十亿个对象和主体的基于关系的访问控制(ReBAC)策略,通过分布式缓存在99百分位维持低于10毫秒的评估延迟,确保在级联权限撤销期间保持因果一致性,并在缓存失效风暴期间防止雷鸣般的拥挤,而不引入集中协调瓶颈?

用 Hintsage AI 助手通过面试

对问题的回答

该架构集中于一个受Zanzibar启发的分布式授权服务,由三个层次组成:无状态的检查引擎评估节点、全球分布的图存储快照数据库,以及用于缓存失效的事件驱动的观察管道。该设计将读负载重的授权检查与写负载重的权限更新分离,允许评估能力的独立扩展,同时保持关系变更的强一致性保证。该系统采用Google的zookie模式来限制陈旧性,而不牺牲边缘缓存的性能优势。

在边缘位置部署的检查引擎节点使用本地内存缓存和紧凑的权限位图评估授权查询。这些节点从一个复制的etcd集群加载命名空间配置,并从一个地理分区的CockroachDBSpanner实例解析关系元组,该实例通过TrueTime或混合逻辑时钟提供外部一致性。每个节点维护布隆过滤器以防止缓存未命中导致数据库查询,特别是在关系确实不存在时。

为了处理"新敌人问题",最近的撤销可能在边缘缓存中不可见,系统实现了zookie令牌—一种编码快照一致性的模糊时间戳—强制敏感操作在可配置的不确定窗口内出现缓存未命中。客户端在初始检查时接收这些令牌,并在访问高价值资源时必须重新播放它们,确保最近撤销的权限立即可见,而无需全局缓存失效。该机制平衡了低延迟的需求与立即撤销可见性的安全要求。

缓存失效利用一个Apache Kafka支持的观察管道,该管道使用一致哈希将元组变更传播到所有边缘检查引擎,确保撤销风暴引发分散的缓存刷新的同时而不是同步数据库攻击。该管道采用抖动的指数退避来防止在广泛共享对象权限变更时造成雷鸣般的拥挤。该架构确保系统在缓存命中时维持低于10毫秒的延迟,同时确保地理分布节点间权限更新的因果一致性。

生活中的情况

一个全球文档协作平台为5000万企业用户服务,在高峰时段,当评估复杂的共享层次结构时,经历了灾难性的延迟峰值。每次文档访问都需要遍历嵌套的组成员关系和存储在单一PostgreSQL集群中的继承权限,导致查询时间超过500毫秒,并且在员工更改部门或项目期间频繁超时。工程团队需要一个能够在维持级联撤销期间提供低于10毫秒延迟的解决方案。

第一个方法评估维护一个集中式PostgreSQL集群,使用激进的Redis物化视图缓存权限路径。优点包括强大的ACID保证,确保撤销的即时可见性,以及对复杂多表更新的直接事务语义。缺点是在大规模权限更改期间出现严重的写瓶颈,流行文档更新时不可避免的缓存 stampede风险,以及在没有复杂的读副本的情况下地理扩展读取吞吐量的根本能力不足,这引入了不可接受的复制延迟,可能影响到安全关键的决策。

第二个方法建议使用完全非规范化的Apache Cassandra部署,应用程序侧权限解析和平局基于TTL的缓存到期。优点包括关系变更的出色写入吞吐量和固有的多区域可用性,没有单点故障。缺点是显著的最终一致性权衡,撤销的权限由于寒暄协议延迟而可见数分钟,以及缺乏原子级联删除导致的安全漏洞,使得用户在被移出父组后仍然可以访问资源,违反了最小权限原则。

团队最终选择了一种Zanzibar风格的架构,利用CockroachDB进行关系元组存储,使用Envoy边车作为政策执行点,以及水平扩展的检查引擎节点,采用最近最少使用缓存和布隆过滤器前端。这一选择在权限写入中保持强一致性的需求与通过本地评估缓存和Apache Kafka驱动的失效流的边缘性能需求之间取得了平衡。结果将p99授权延迟从500毫秒减至4毫秒,全球支持每秒1500万次检查,并确保权限撤销在150毫秒内传播到所有边缘节点,同时保持99.99%的可用性。

候选人常常遗漏的内容

如何防止授权检查在权限撤销后立即返回陈旧的"允许"决策,而不牺牲分布式缓存的性能优势?

候选人经常忽略zookie模式或版本向量,而提出在每次检查时进行全局缓存失效或数据库读取。该解决方案要求授权服务为每个决策返回一个一致性令牌,编码所使用数据的快照时间戳。对于敏感操作或最近的撤销事件,客户端必须出示此令牌,强制检查引擎在其本地缓存时间戳早于该令牌时验证中央存储。这确保了因果一致性,而不需要全局缓存失效或牺牲大多数请求的读取性能。

如何设计缓存失效机制来避免雷鸣般的拥挤,当一个广泛共享的对象的权限被修改时,可能触发数百万次同时的缓存刷新?

关键技术涉及缓存键一致哈希与抖动的指数退避和边缘节点请求合并。当观察管道广播元组变更时,边缘节点并不会立即失效,而是使用对象ID的哈希计划失效,将更新刷新分散到时间窗口内。此外,每个检查引擎维护一个正在进行检查的航班组,确保对同一对象的并发请求共享单一的后端查询结果,防止在流行对象更新期间数据库过载。

为什么使用简单的有向图遍历不足以建模ReBAC策略,并且如何在分布评估环境中处理交集和排除约束?

简单的图遍历未能捕捉到执行复杂策略(如“仅当用户在组A中并且不在组B中时允许”)所需的集合操作。解决方案实现了一种重写系统,将命名空间配置编译为用于反向索引查找的决策树,显式存储正负关系元组。对于交集约束,系统查询两个集合并计算在检查引擎中的交集,而排除则采用短路评估并提前终止。这种方法确保复杂布尔逻辑高效评估,而不需要多次往返数据库。