HackerNews中文版

简要概述：构建了一个RPC框架，采用多种方法解决现有的RPC问题。现提供文档预览，寻求反馈以便最终定稿。 在看到关于RPC的相同抱怨反复出现多年后，我花了一年时间构建了一个新的RPC框架，AtomicLinkRPC（ALR）。 同一篇文章每隔几年就会引发热烈讨论： https://reasonablypolymorphic.com/blog/protos-are-wrong/ 以及基于该文章的讨论： https://news.ycombinator.com/item?id=21871514 https://news.ycombinator.com/item?id=35281561 https://news.ycombinator.com/item?id=45139656 我已实现了一个具体的端到端解决方案，并发布了文档预览（C++优先）： https://atomiclinkrpc.github.io/alr-preview/ 简要示例： // service.h class Greeter : public alr::EndpointClass { public: static std::string sayHello(const std::string& name); }; // service.cpp std::string Greeter::sayHello(const std::string& name) { return "Hello " + name; } int main() { return alr::ConnectionInfo() .setListenAddress("0.0.0.0:55100") .listen(); } // client.cpp #include "alr/endpoint.h" #include "client_gen.h" int main() { alr::Endpoint ep = alr::ConnectionInfo() .setConnectAddress("service-host:55100") .connect(); auto result = Greeter::sayHello("World"); // 实际上是RPC printf("%s\n", result.c_str()); return 0; } 以下是上述讨论中提出的一些问题的简要列表，以及ALR如何解决每个问题的简要描述。我非常希望听到您对这些方法的批评意见，您认为它们可能出现的问题，以及缺失的部分（但请查看文档链接以获取更深入的细节）。 1) 阻抗不匹配：应用代码为了适应传输而扭曲 - 在ALR中，“消息”和其他RPC特定概念成为低级实现细节，永远不会出现在您的业务逻辑中。可远程调用的类、方法和结构保持干净，不受RPC噪音影响，并与您的业务逻辑1:1映射。无需再编写用户自定义的事件循环/反应器来使RPC工作。也不再需要生成以RPC为中心的数据传输对象（DTO）及其getter和setter。 - ALR使用环境变量系统（请参见文档），这是一组线程局部变量，提供执行RPC所需的所有上下文，而无需在业务逻辑中拖拽上下文变量。只有您自己的干净类、干净函数、干净结构和原生类型。没有噪音。 2) API演变在现实中是破碎的、脆弱的、不一致的或难以使用和维护 - ALR直接使用您的类、方法和结构作为模式，没有脆弱的标签。 - ALR在握手时协商模式和访问者布局映射，并创建交集映射以允许不同版本之间的互操作。 3) 理解和实现RPC框架的学习曲线陡峭 - 除了从ALR基类派生您的可远程调用类外，没有太多新的API需要学习。 - 请查看文档预览链接中的示例，以感受与其他框架相比使用的简便性。 4) 性能 - 基准测试结果显示，ALR的性能显著优于gRPC，具体结果请见文档。我很乐意讨论这些结果为何可能。 针对HN的问题 1. 您认为ALR解决这些问题的方法有哪些缺陷？ 2. 如果您有动态远程能力检查失败的反例，我想听听。 3. 我遗漏了哪些RPC痛点，ALR没有解决？ 4. 这里或文档中是否有需要更多细节的特定领域？ 状态与范围 - 这是一个仅限文档的预览。我在冻结接口之前寻求对立的反馈。 - 源代码尚未公开，正在最终确定开源许可证。 - C++是首个支持的语言，计划支持Python、Rust等其他语言。 感谢您抽出时间查看 - 欢迎直接反馈！

查看原文

TL;DR: Built an RPC framework that uses various approaches to solve existing RPC issues. Docs-only preview, seeking feedback before finalizing.After seeing the same complaints about RPCs resurface for years, I spent the last year building a new RPC framework, AtomicLinkRPC (ALR).The same article spawns heated discussions every few years: https://reasonablypolymorphic.com/blog/protos-are-wrong/And then the discussions based on that: https://news.ycombinator.com/item?id=21871514 https://news.ycombinator.com/item?id=35281561 https://news.ycombinator.com/item?id=45139656I've implemented a concrete, end-to-end answer to these issues and have published a docs-only preview (C++ first): https://atomiclinkrpc.github.io/alr-preview/Brief example:// service.h class Greeter : public alr::EndpointClass { public: static std::string sayHello(const std::string& name); };// service.cpp std::string Greeter::sayHello(const std::string& name) { return "Hello " + name; }int main() { return alr::ConnectionInfo() .setListenAddress("0.0.0.0:55100") .listen(); }// client.cpp #include "alr/endpoint.h" #include "client_gen.h"int main() { alr::Endpoint ep = alr::ConnectionInfo() .setConnectAddress("service-host:55100") .connect();<pre><code> auto result = Greeter::sayHello("World"); // Happens to be RPC printf("%s\n", result.c_str()); return 0;</code></pre> }Below is a short list of issues brought up by the above discussions, and a brief description of how ALR solves each. I'd love your critique on what you think about these approaches, where you believe they'll break, and what's missing (but see the docs link for more in-depth details).1) Impedance mismatch: App code contorts to fit the transport - In ALR, "messages" and other RPC specific concepts become low-level implementation details, never to be seen by your business logic. Remotable classes, methods and structs stay clean from RPC noise and map 1:1 to your business logic. No more user-written event loops/reactors just to make RPCs work. No more generated RPC-centric DTOs with their getters and setters. - ALR uses an ambient variable system (see the docs), which is a set of thread-local variables that together provide all the context needed to perform RPCs without dragging context variables throughout your business logic. Only your own clean classes, clean functions, clean structs, and native types. No noise.2) API evolution is broken, fragile, inconsistent or difficult to use and maintain in reality. - ALR directly uses your classes, methods and structs as the schema, with no fragile tags. - ALR negotiates schemas and visitor layout mapping at handshake time and creates an intersection map to allow different versions to interoperate.3) Steep learning curve to understand and implement RPC frameworks - Besides deriving your remotable class from an ALR base class, there isn't much new API to learn. - Please check out the examples in the docs-preview link to get a feel for how easy it is to use compared to other frameworks.4) Performance - Benchmark results show that ALR can significantly outperform gRPC, see the results in docs. I'll be happy to discuss how those results are even possible.Questions for HN 1. Do you see any flaws with ALR's approach to solving some of these issues? 2. If you have counterexamples where the dynamic remote capability check falls down, I want to hear them. 3. What RPC pain points am I missing that aren't addressed by ALR? 4. Any specific areas that need more detail here or in the docs?Status & scope - This is a docs-only preview. I'm seeking adversarial feedback before I freeze the interfaces. - The source is not public yet while I finalize the open-source license. - C++ is the first supported language, with plans for Python, Rust, and others.Thanks for taking a look - blunt feedback welcome!

请问HN：关于一个旨在解决经典RPC问题的新框架的反馈