为啥需要RPC，而不是简单的HTTP？( 二 ) _RPC

比如那个卖水饺的，虽然每天几十个人来吃饭。那也是钱啊。你人这么多，想来我这吃饭的人都挤不进来了，
大概情景是这样的：

文章插图

这样能看懂吧？
遇到这种场景怎么办？不可能不让面馆开门营业啊，那最好的方式就是：
“你可不可以搬出去？”
你不搬我们搬也行！（哭泣脸，反正我们是再也不要和你家面馆开在一起了，必须给我们一个说法）
那么，搬家之后的样子可能是这样的。

文章插图

嗯啊。分是分开了，然后餐卡什么的还是在一起，还是和其他窗口一样，给大家提供就餐的功能。这就是分而治之，哪怕你面馆关门了，也不影响我，这又叫分布式。（“分布式”划重点）
说到分布式，就问题就来了。
可不可以互相调用？其实细分下去，买菜，切菜，结账这些都是独立的流程，我们能不能都把它们独立出来？
当然是可以的，但是带来的问题就是，如何通信？大家都不在一个进程里。
这种通信的方式，就叫做RPC ，在今天， RPC已经不仅仅是远程，这个远程，确切来说，就是指不在一个进程内，只能通过其他协议来完成，通常都是TCP或者是Http 。
好了， RPC讲清楚了，再看RPC的重点是什么。
不能太慢，对不对？如果太慢了，怎么办？
这种性能的要求，要做到什么程度？希望是和在同一个进程里，一致的体验。
Http能做到这种程度么？
不行。Http（TCP）本身的三次握手协议，就会带来大概1MS的延迟（emmm ，这个数据其实我有点不确定了，也可能是几微秒，很早之前做过测试）。
每发送一次请求，都会有一次建立连接的过程，加上Http报文本身的庞大，以及Json的庞大，都需要作一些优化。
一般的场景下，没什么问题，但是对于google这种级别的公司，他们接受不了。
几MS的延迟可能就导致多出来几万台服务器，所以他们想尽办法去优化，优化从哪方面入手？
1.减少传输量。
2.简化协议。
3.用长连接，不再每一个请求都重新走三次握手流程
Http的协议就注定了，在高性能要求的下，不适合用做线上分布式服务之间互相使用的通信协议。
五、总结RPC服务和HTTP服务还是存在很多的不同点的，一般来说， RPC服务主要是针对大型企业的，而HTTP服务主要是针对小企业的，因为RPC效率更高，而HTTP服务开发迭代会更快。总之，选用什么样的框架不是按照市场上流行什么而决定的，而是要对整个项目进行完整地评估，从而在仔细比较两种开发框架对于整个项目的影响，最后再决定什么才是最适合这个项目的。一定不要为了使用RPC而每个项目都用RPC ，而是要因地制宜，具体情况具体分析。