系统与数据库2024dl.acm.org
迈向云应用的现代开发方式
Towards Modern Development of Cloud Applications (2023)
进阶 · 约 30 分钟读完前置知识：分布式系统基础、RPC 与序列化、云应用部署
导读
这篇论文（ServiceWeaver）研究如何简化云应用的开发与部署：让开发者把应用写成单个模块化程序，再由框架自动决定组件的部署位置（同进程或跨机器分布），组件间调用看起来像普通方法调用。其性能提升主要来自为非版本化数据交换设计的自定义序列化格式。
HN 关注点：是因为'把分布式调用伪装成本地方法调用'这一抽象触及了分布式系统设计的老争论：隐藏分布性是否注定是泄漏的抽象。
HN 评论精选
这几条评论里：质疑 4
质疑透明 RPC 是历史多次失败的老路，隐藏分布性的抽象本质上是泄漏的
移动代码和'代理系统'20年前就很流行。Java 内置了带自动 stub 下载的 RMI，1998 年 Sun 又发布了 Jini，还衍生出 JavaSpaces 等框架。读这篇论文让我想到：'旧事重演'，以及'不吸取历史教训的人注定重蹈覆辙'。历史上多次尝试实现透明 RPC，全都因'分布式计算的谬误'而失败。任何试图隐藏分布性的抽象似乎天生就太泄漏。
mkleczek查看英文原文
Mobile code and "agent systems" were very fashionable 20 years ago. Java introduced built-in RMI with automatic stub downloading. In 1998 Sun published https://en.wikipedia.org/wiki/Jini that was an extension of this idea. Several higher level frameworks emerged (JavaSpaces among the most prolific). Reading the paper two thoughts come to mind: - "What's old is new again" - "those who do not learn from history are doomed to repeat it" There were several attempts in history to implement transparent RPC (new again). All failed due to https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing (learn from history) Looks like any abstraction trying to hide distribution is inherently too leaky.
质疑把 RPC 伪装成本地调用有风险，且本地调用仍需序列化这点存疑
看起来有意思。'hello.Greet 调用看起来像普通方法调用'这与 boq（一个内部广泛使用的生产平台，具备论文的部分特性）不同——那里组件接口就是 RPC 接口（Stubby/gRPC + protobuf），调用点能明确看出是 RPC。RPC 看起来像普通方法调用有点吓人（code review 容易漏掉）。不过似乎需要传 context 对象以免误认为本地调用。另外论文称大部分性能收益来自非版本化序列化格式，但我不明白本地 RPC 调用为何还要序列化 protobuf——直接传给本地 handler 不行吗？（免责声明：我是 Google 员工，但无 ServiceWeaver 内部信息）
dti查看英文原文
Looks interesting. > The call to hello.Greet looks like a regular method call That’s a departure from how components interact in boq — an internal and widely used production platform that has _some_ of the features from the paper. There component interfaces _are_ RPC interfaces (e.g., Stubby / gRPC + protocol buffers), and interaction between them is possible exclusively through the component interfaces. Hence it’s very explicit at the call site that an RPC is being made (which could happen to execute locally with all the standard RPC functionality — context and deadline propagation, etc.). RPCs looking like regular method calls sound a bit scary (easy to miss in code reviews); I wonder if enforced naming conventions + IDE + code review tool support would be enough. Edit: it seems to require to pass a context object, so the readers won't confuse it with a local call (from https://serviceweaver.dev/): sum, err := adder.Add(ctx, 1, 2) --- Also, the paper claims that most benefits come from a non-versioned serialization format: > Most of the performance benefits of our prototype come from its use of a custom serialization format designed for non-versioned data exchange [...] However, I don’t understand why local RPC calls have to serialize protocol buffer messages — can’t they already pass them as-is to the local handler? (disclaimer: a googler, no internal knowledge on ServiceWeaver)
质疑性能评估样本单一，9 倍提升来自合并部署，未必普遍适用
大胆的声明……性能评估只针对一个示例实现（6.1 节），合并到单进程后获得 9 倍提升。平心而论，如果应用效率足够高，这样做是合理的——但很多应用可能有很好的理由不这么做。
sgt101查看英文原文
Bold claims... Performance is evaluated against a single example implementation (section 6.1) and 9x improvement was achieved when co-locating into a single process. To be fair this seems a reasonable thing to do if you can get the application to be efficient enough to allow it - but there may be very good reasons not to do it in many applications.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖159 分 · 63 评
同领域还值得读
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 分钟编辑精选