系统与数据库2021research.google编辑精选
Zanzibar：Google 的一致性全球授权系统（2019）
Zanzibar: Google’s Consistent, Global Authorization System (2019)
专业 · 约 75 分钟读完前置知识：分布式系统基础、一致性模型、访问控制（ACL/ReBAC）
导读
这篇论文介绍 Google 的 Zanzibar——一个全球分布式授权系统，研究如何用统一服务为各类产品提供一致、低延迟的授权检查。其核心做法是用关系元组（relationship tuples）表达访问控制关系，支持关系型访问控制（ReBAC），并在全球部署下处理一致性与规模问题。
HN 关注点：集中式授权服务是否会成为微服务架构中的瓶颈，以及 Zanzibar 的开源实现和授权基础设施近年来的再度流行。
后来怎么样
Zanzibar 的关系元组/ReBAC 模型成为后续授权系统的重要参考，直接启发了 Ory Keto、SpiceDB、OpenFGA 等实现，并推动了关系型授权服务的普及。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
质疑质疑独立授权服务需为所有对象建模并可能成为瓶颈，询问 sidecar/进程内方案及对象注册边界。
关于独立授权服务有个可能很蠢的问题：授权服务最终是否要为其他所有数据存储中的每个对象都保存一份表示，比如每篇文档、每个存储块、每个组织中的每个用户？如果是，这会不会在分布式微服务架构中成为瓶颈？还是可以通过进程内或 sidecar 架构避免，让某个微服务的对象不在授权持久化中单独引用？如果不行，大家如何决定哪些对象注册到授权服务、哪些独立处理？
aaronharnly查看英文原文
Maybe a dumb question on standalone authorization services: does the authorization service end up having a representation for every single object in all of the rest of your datastores? (e.g. every document, every blob of storage, every user in every org). If so, does that become a chokepoint in a distributed microservice architecture? Or can that be avoided with an in-process or sidecar architecture in which a given microservice's objects are not separately referenced in auth persistence? If not, how do folks determine which objects to register with the auth service and which to handle independently?
补充补充往期 HN 讨论，并指出 Ory Keto 基于 Zanzibar。
这个话题两年前在 HN 上讨论过[0]。这个服务也在 Ory Keto 的讨论[1]中被提到，因为 Keto 基于 Zanzibar。
kyrra查看英文原文
This was talked about 2 years ago on here[0]. This service was also brought up in the discussion[1] of Ory Keto, as it's based on Zanzibar. [0] https://news.ycombinator.com/item?id=20132520 [1] https://news.ycombinator.com/item?id=26738344
亲历推荐开源 Go 实现 Ory Keto，并称实际测试效果很好。
有一个用 Go 写的开源 Zanzibar 实现叫 Keto[0]，它与 Ory 生态的其他部分集成。我们实际在测试它，目前看起来很棒。
merqurio查看英文原文
There is an Open Source (Go) implementation of "Zanzibar" called Keto [0] that integrates with the rest of the Ory ecosystem. We are actually testing it and looks great so far. [0]: https://github.com/ory/keto
补充作为授权创业公司创始人，关注授权基础设施兴趣回升的驱动因素。
我很好奇是什么推动了授权基础设施、尤其是 Zanzibar 论文的兴趣复苏。作为 Oso（https://www.osohq.com/）的创始人，我有自己的看法，并认为这是好事，但很想听听其他人的观点。
gneray查看英文原文
I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso (https://www.osohq.com/), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖20 分 · 2 评
- 2021Hacker News 讨论帖238 分 · 95 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选