brpc初探
因为最近在看一个内部开源代码，看到了braft。braft又依赖于brpc。于是就看了相关的文档，打算接下来试一把。
这里引用下gejun大佬在知乎上的回答（https://www.zhihu.com/question/65370268/answer/231801580）。
RPC是个老概念，五花八门的实现非常多。在14年我刚转到基础架构部时，其实是不想做RPC框架的。我的想法可能和很多工程师一样：之前做了那么多系统，现在就让我来搞个编程框架？而且这能做出什么花头？但事实很快证明我错了，编程上的事真的需要实践，否则看问题就很浅。像搞深度学习，vgg rcnn gan嘴上可以说得不停，但只要你没在真正严肃的项目中调过参数，你就是门外汉。
RPC的深度在于现代的互联网公司中几乎所有服务都是使用RPC的，大部分工程师和它打交道。如果你能看到其中的痛点，提高了效率，那么整个公司的开发效率都会有明显的提升。大家都是从学生时代过来的，心里清楚一个东西在正确的条件下正确运行很容易，但要在所有情况下能正确运行就非常困难。前两天我修了个问题：brpc在fedora 26下一个weak function莫名其妙地没有被tcmalloc中的对应版本覆盖，导致heap profiler启用不了，ubuntu，centos下都是好的。这种问题往往和系统或ld有关，要精确定位很麻烦，最后我找到了一个workaround。但这个事情耗了我几个小时，因为需要在很多系统上验证没有regression。RPC里大量此类东西，虽然麻烦但能提高用户体验。那个问题其实和brpc对tcmalloc的支持方式有关，brpc默认不链接tcmalloc，但用户在程序中链接tcmalloc后，我们希望cpu和heap profiler要自动开启（这两个功能依赖tcmalloc的API），同时用户不用重编brpc。所以我们得在brpc中动态判定是否链接了tcmalloc，这就没那么容易了。对我们很麻烦，但用户的体验更好了，甚至用户会觉得理所当然。
知识是需要大量实践的，你也许可以在正确的条件下用dlsym有效地覆盖一个glibc中的函数，但你可能不知道dlsym在有多版本符号存在时可能无效，或dlsym和一些库合用时（比如用于展开栈的libunwind）会死锁，或dlsym对静态链接是无效的除非编译加了-rdynamic。你也许可以基于一些上下文切换库三下五除二搞出个libcoroutine，但你可能不知道的是JNI会检查stack layout而不能使用自定义栈，或程序运行在valgrind中需要注册栈地址才不会报错，或一个栈跑到另一个LWP上展开时会触发gcc4以上版本的thread-local误优化。这些知识，成千上万条这种知识，通过实践才会深深地刻画在脑中，构成一个工程师真正的竞争力。
我一直坚信所有的用户体验都是端到端的，只有站在用户的角度，把整个流程以既高效又不失扩展性的方式走通，才是最好的选择。良好的文档正是这种理念的体现：给新用户铺好路能快速上手，让老用户知其所以然更上一层楼。这种想法也体现在代码中的方方面面：每个选项都有合理的默认值，用户不设也能用；在注释中提示best practice，避免用户走弯路；用户界面、日志内容不啰嗦，让用户一眼看清楚问题的全貌。不做并不意味着我们没能力做，而是早已被事实证明可能出现非常subtle的bug而被淘汰掉的选择。知道的越多，你就越会有一种责任感，需要帮助用户修一条好路，避免陷到你已经踩过的成百上千个坑中。
说到性能，RPC的性能评估其实很像VC投资初创公司：每家都在说自己的东西好，并能拿出数据，可真的好不好天晓得。所以VC只能看团队，查背景，凭感觉，这钱花出去了能不能拿回来心里都慌的很。RPC其实也这样，每个实现都有大量独特的设计和接口，用户不太可能轻易地从一个RPC切换到另一个RPC，并在完全相同的环境下进行对比。每个RPC实现都在说自己高性能，轻量级。这是个自卖自夸的游戏，用户只能看脸。但就像我们奇怪古人连那么简单的东西都不知道一样，人的认知就是这样，内行的常识可能对外行非常困难，甚至这个常识非常简单。在很多年以前，我们对“高性能”的认识还停留在“极限QPS”和“延时”两个维度的时候，被一个复杂系统中的拥塞问题搞的焦头烂额，大家就觉得莫名其妙啊，每个环节都很快，这延时怎么就哗哗哗地涨上去了。最后在反反复复的思考和分析后才发现，QPS和延时的乘积与程序的最大服务能力紧密相连。我们搞了个概念叫volume，发现串行系统的volume可以相加，并行系统的volume可以求min，然后一层层地迭代上去从而计算出复杂系统同时能处理的最大请求数，并解决了拥塞问题。
不过就是个乘法。
今天我们知道这个原理是little’s law，tcp中的BDP也是类似的道理。我们在文档中描述了相关的知识。但即使是这样，根据我们在百度内的支持经验（没人会否认百度研发的整体素质吧），大部分RPC的用户对这个乘法理解还是有困难的，更别提理解串行相加，并行求min，在系统设计中活学活用了。一个乘法尚且同此，更深入的可想而知。普通用户是很难看明白性能测试的道道的。我们团队里有个老梗：“处处是热点，处处不是瓶颈”。这说的是如果整个程序写的都很粗暴，不考虑性能，最后用profiler一跑，发现每个点都只有1%，2%，然后得出结论，“性能非常好，优化空间已经不大”。但实际上你去分析下hot path，会发现有太多可以大幅提高的点了。性能就是这样，设计确保了流程是最优化的，但实现也非常重要，细节全靠抠。brpc上关键路径上的代码多一次new都需要讨论，最热的路径上甚至不允许出现申明一个可能无用的空std::string，因为glibc中的空string是要加引用计数的，对cache有影响。
抠细节的背后需要工程师对性能的深入理解。一个函数的性能是可以估算出来的，测试只是验证。如果不符合预期，你就要深入地去看，最终理解背后的原因。为什么一次激烈的cacheline同步大约是700ns？或是一次调度延时至少是3us，99%以内是20us？或是linux下的timed condition有60us的延时？或是一次上下文切换可以在200ns内做完？或是无竞争的mutex可以实现为两条20ns左右wait-free的原子指令？掌握了这些知识，你才能抓大放小，把精力放在最关键的事情上，并把它做到世界上最好的水平。
也推荐一下这个问题下面的其他回答。一看就知道是一直处在工程第一线的人写出来的答案。
当一个框架得到较大规模的应用之后，没有足够的业务需求推动，往往自身缺乏前进的动力， 如果框架本身质量不是非常solid，开发者又换过一拨人之后，整体会更加保守。
但是brpc有一点在开始就做的非常好，能非常简单的获取系统的内部状态，brpc提供了bvar和buiting service这类工具， 内部几乎所有的环节都有相应的bvar， online profiling能非常轻松的分析热点。 即使我们今天仍然没法回答brpc理论极限在哪，也能非常方便的找出当前系统的瓶颈所在.
https://www.zhihu.com/question/65370268/answer/232090356
因为前阵子刚好也在看我们内部的 某kit rpc框架，也仔细地研究了源码以及内部相关的文档，主要问题：
1. 基于protobuf2.3，所以比如像tensorflow这些用了新版本的库就没办法整合进来；
2. 现网微服务之间都是通过rpc互联，但是还有一些离线系统、docker环境里等等就不能直接访问，需要自己再做一层http包装；
3. 由于rpc服务都用的c++，没有其他语言的client，再加上没有http接口，因此基本上限制了线上的服务也只能用c++以及该rpc框架来写；
4. 我们的rpc框架，很难做内存profile。没有集成像tcmalloc、jemalloc这些，也没有对应工具，之前试过用valgrind也是打印出太多信息，干扰性大；这些在定位内存泄漏时很麻烦；
5. rpc框架是个黑盒，内部状态只能知道一些很粗的统计。比如我某次上线导致请求队列满，但是我无从得知，我知道总耗时上升了，不过也很难定位到是什么原因导致的，只能分析刚上线的代码有没问题；
虽然还没试用过brpc，不过看了下文档，以上的问题可能可以得到解决，这个后续再来对比一下。
总的来讲，rpc框架说简单也简单，功能就是接受请求，处理完塞回去，性能虽然重要，但也不是最为重要的一点。说复杂也很复杂，这里作为业务应用的基础，需要有相应的基础监控、熔断、负载均衡等支持；还要有方便定位问题的基础能力。虽然现在一直在吐槽内部的框架，但是现在大部分bug也能根据经验快速地定位出来，不过想起刚来那会的阻力，深感工具是否便利，是它能够推动的非常重要原因之一。哪怕现在能比较快定位bug了，更多的是因为一些防御性编程的技巧，和框架倒是关系不大。
