如何评价百度开源的RPC框架rpc？
我是rpc作者之一。本想在刊出InfoQ的报道后再把类似的内容贴到知乎，里面会谈到rpc研发的前因后果，但考虑到知乎上关注这个问题大都是战斗在一线的工程师朋友，我决定说点不一样的。
RPC是个老概念，五花八门的实现非常多。在14年我刚转到基础架构部时，其实是不想做RPC框架的。我的想法可能和很多工程师一样：之前做了那么多，现在就让我来搞个编程框架？而且这能做出什么花头？但事实很快证明我错了，编程上的事的需要实践，否则看问题就很浅。像搞深度学习，vggrcnngan嘴上可以说得不停，但只要你没在正严肃的项目中调过参数，你就是门外汉。
RPC的深度在于现代的互联网公司中几乎所有服务都是使用RPC的，大部分工程师和它打交道。如果你能看到其中的痛点，提高了效率，那么整个公司的开发效率都会有明显的提升。大家都是从学生时代过来的，心里清楚一个东西在正确的条件下正确运行很容易，但要在所有情况下能正确运行就非常困难。前两天我修了个问题：rpc在fedora26下一个weakfunction莫名其妙地没有被tcmalloc中的对应版本覆盖，导致heapprofiler启用不了，uuntu，centos下都是好的。这种问题往往和或ld有关，要精确定位很麻烦，最后我找到了一个workaround。但这个事情耗了我几个小时，因为需要在很多上验证没有regression。RPC里大量此类东西，虽然麻烦但能提高用户体验。那个问题其实和rpc对tcmalloc的支持方式有关，rpc默认不链接tcmalloc，但用户在程序中链接tcmalloc后，我们希望cpu和heapprofiler要自动开启（这两个功能依赖tcmalloc的API），同时用户不用重编rpc。所以我们得在rpc中动态判定是否链接了tcmalloc，这就没那么容易了。对我们很麻烦，但用户的体验更好了，甚至用户会觉得理所当然。
知识是需要大量实践的，你也许可以在正确的条件下用dlsym有效地覆盖一个glic中的函数，但你可能不知道dlsym在有多版本符号存在时可能无效，或dlsym和一些库合用时（如用于展开栈的liunwind）会死锁，或dlsym对静态链接是无效的除非编译加了-rdynamic。你也许可以基于一些上下文切换库三下五除二搞出个licoroutine，但你可能不知道的是JNI会检查stacklayout而不能使用自定义栈，或程序运行在valgrind中需要注册栈才不会报错，或一个栈跑到另一个LWP上展开时会触发gcc4以上版本的thread-local误优化。这些知识，成千上万条这种知识，通过实践才会深深地刻画在脑中，构成一个工程师正的竞争力。
我一直坚信所有的用户体验都是端到端的，只有站在用户的角度，把整个流程以既高效又不失扩展性的方式走通，才是最好的选择。良好的文档正是这种理念的体现：给新用户铺好路能快速上手，让老用户知其所以然更上一层楼。这种想法也体现在代码中的方方面面：每个选项都有合理的默认值，用户不设也能用；在注释中提示estpract，避免用户走弯路；用户界面、志内容不啰嗦，让用户一眼看清楚问题的全貌。不做并不意味着我们没能力做，而是早已被事实证明可能出现非常sutle的ug而被淘汰掉的选择。知道的越多，你就越会有一种责任感，需要帮助用户修一条好路，避免陷到你已经踩过的成百上千个坑中。
说到性能，RPC的性能评估其实很像VC投资初创公司：每家都在说自己的东西好，并能拿出数据，可的好不好天晓得。所以VC只能看团队，查背景，凭感觉，这钱花出去了能不能拿回来心里都慌的很。RPC其实也这样，每个实现都有大量特的设计和接口，用户不太可能轻易地从一个RPC切换到另一个RPC，并在完全相同的环境下进行对。每个RPC实现都在说自己高性能，轻量级。这是个自自夸的游戏，用户只能看脸。但就像我们奇怪古人连那么简单的东西都不知道一样，人的认知就是这样，内行的常识可能对外行非常困难，甚至这个常识非常简单。在很多年以前，我们对“高性能”的认识还停留在“极限QPS”和“延时”两个维度的时候，被一个复杂中的拥塞问题搞的焦头烂额，大家就觉得莫名其妙啊，每个环节都很快，这延时怎么就哗哗哗地涨上去了。最后在反反复复的思考和分析后才发现，QPS和延时的乘积与程序的最大服务能力紧密相连。我们搞了个概念叫volume，发现串行的volume可以相加，并行的volume可以求min，然后一层层地迭代上去从而计算出复杂同时能处理的最大请求数，并解决了拥塞问题。
不过就是个乘法。
今天我们知道这个原理是little’slaw，tcp中的DP也是类似的道理。我们在文档中描述了相关的知识。但即使是这样，根据我们在百度内的支持经验（没人会否认百度研发的整体素质吧），大部分RPC的用户对这个乘法理解还是有困难的，更别提理解串行相加，并行求min，在设计中活学活用了。一个乘法尚且同此，更深入的可想而知。普通用户是很难看明白性能的道道的。我们团队里有个老梗：“处处是热点，处处不是瓶颈”。这说的是如果整个程序写的都很粗暴，不考虑性能，最后用profiler一跑，发现每个点都只有1%，2%，然后得出结论，“性能非常好，优化空间已经不大”。但实际去分析下hotpath，会发现有太多可以大幅提高的点了。性能就是这样，设计确保了流程是最优化的，但实现也非常重要，细节全抠。rpc上关键路径上的代码多一次new都需要讨论，最热的路径上甚至不允许出现申明一个可能无用的空std::string，因为glic中的空string是要加引用计数的，对cache有影响。
抠细节的背后需要工程师对性能的深入理解。一个函数的性能是可以估算出来的，只是验证。如果不符合预期，你就要深入地去看，最终理解背后的原因。为什么一次激烈的cacheline同步大约是700ns？或是一次调度延时至少是3us，99%以内是20us？或是linux下的timedcondition有60us的延时？或是一次上下文切换可以在200ns内做完？或是无竞争的mutex可以实现为两条20ns左右wait-free的原子指令？掌握了这些知识，你才能抓大放小，把精力放在最关键的事情上，并把它做到世界上最好的水平。
但即使到现在，rpc中仍然有一些极具挑战性的问题，如thread的调度如何能更好地保持cachelocality，如何在NUMA机器上跑得更好，如何尽量消除内核调度的延时，如何更高效率地重用栈...如此种种。我们把rpc开源出来，正是为了让感兴趣的伙伴一起加入进来，做出一个更上一层楼的RPC框架。与大家共勉。
