获得徽章 25
- 最近在写一篇rpc的文章。有几个疑惑一直没想清楚。rpc要通过字符串函数名去进程中找到这个函数，匹配的技术手段是动态代理。但go没有动态代理，只有反射。翻了翻net/rpc、gRPC、go- micro的源码，清一色都是用反射实现的。但好像都选择性忽略了一个东西，go generate，类似静态代理的概念。如果有办法解决go generate代码维护问题，是不是要比反射更有优势？毕竟大家都对反射嗤之以鼻，但是又不经意间偷偷摸摸的用它。就像当年高斯林们抨击不应该像IPC那样理解RPC，可是二三十年后我们的RPC终极目标还是远程调用无感知。网络IO、数据流传输、二进制编解码的成本才不会有人管，毕竟工业界业务优先嘛，学术界未雨绸缪的理论得朝后站站。毕竟还没宕机，就算宕机，继续加节点怼机器就好了。就像工期不够，怼人怼工时就好了。又愤青了。回到rpc，这个道理好像就是在说，map比switch case/if else好用，策略模式+map更好用，策略模式+工厂模式+map更更好用，还有人说状态机...但放眼望去，99%的代码仍然是if else。然后有人发现这个现象，开始质疑学术界大牛是来炫技的还是来解决问题的？争论一旦开始，所有东西就全部是错的，无论最后谁赢了，都是谬论，都是一言之谈。多数人认为对就不一定对，极少数人认为对，同样不一定对。对程序的理解和认知都不一样，非要扯到一块争辩技术的优劣。还是韦青说的对，技术的终极都是落地、是为人所用。九霄之上的晚霞很美，但比不上路边小摊上1块钱的包子实在。可还是有些大牛宁愿饿着肚子也要去追求完美。在他们眼里，现实和虚幻的边界已经模糊。完美的理论好像就在不远处，可是如泡沫般一碰即破。因为那是简单质朴的本质、亘古不变的本源、虚无缥缈的道，凡人碰不得。又扯远了...继续怼rpc。展开评论点赞
