微服务什么状况下用Http协定通讯 什么时刻要用Lrpc

1 Spring cloud微服务，以落第二代微服务，spring cloud alibaba，可以用openfeign来调用，即走的是http或https协定，也可以经过dubbo，dubbo就是所谓的rpc，rpc叫远程方法调用，是一种成功方式，底层成功普通是得靠tcp或udp等通讯协定。

2 http协定因为会蕴含恳求头之类的信息，所以效率相对tcp协定来说有些慢，但假设并发量不高，http所谓的低效可以疏忽不计，而https协定因为多了基于SSL的安保验证举措，所以通讯效率比http还略低，但假设并发量不高的话，这也是可以接受的。

3 在微服务架构，也可以用resttemplate的方式来远程调用，或许是用restful的方式，但restful也是调用方式，底层成功是用http或https。

4 可以这样说，在大少数的场景，尤其是中小公司所开发的名目场景，用spring cloud+http协定，足以应答名目的并发恳求。而且一旦并发量高的话，可以经过基于nacos的扩容和基于redis的缓存等手腕来应答，假设再要进一步开掘性能后劲，那么再用基于tcp的通讯协定，比如用dubbo或netty，但这对程序员就有要求，而用spring cloud+基于http的openfeign，基本上大少数初级开发也能用。

1 各微服务模块间交互，当下普通是基于http协定，或许是rpc（tcp），比如是dubbo，但两者的性能差异不大，再者比如要应答高并发，比如是支付场景，普通是启3个实例，用nacos治理，外面再用gateway等网关来做负载平衡。

这样的话，2个实例（热备，防止单点失效），应答个一秒几百并发量疑问不大，理想上大少数名目，真达不到一秒100的并发量。换句话说，spring cloud alibaba+nacos+gateway+2个实例，哪怕用http协定，甚至再引入有ssl安保性验证的https，真能满足大少数名目的并发需求。

2 假构想要性能调优，比如要到达一秒2k甚至更高的并发量，最间接的方法就是用机器叠， 比如把一个实例部署多个机器上，一个机器应答一秒500的并发量，那么就部个4台机器。普通有高并发需求的名目或许公司都不怎样差钱，部署4个实例也是常事。

而且应答高并发，其实更在于数据库层面和业务交互层面，假设在名目里引入redis或许redis集群，或许分库组件，或许再引入kafka做业务异步处置，外带3，4个实例，哪怕用的是基于http协定的openfeign，应答个2，3k并发量没太大疑问。

3 还有一点大家须要留意，spring cloud alibaba组件是开箱即用的，所以用基于http协定的openfeign成功组件间的调用，普通有半年名目阅历的初级开发都能做到，或许再引入SSL，用https协定通讯，开发难度也不大。

4 微服务模块间通讯，除了http，其实也可以用tcp，tcp的效率是要高于http，自己之前在高并发名目里做过这方面的调优，等同条件，用tcp协定通讯，效率普通比https和http协定高出大略1/3。

然而假设用tcp交互，只管不用在通讯环节中传输业务有关的http恳求头和前往头信息，但开发交互环节中，得自己确保数据的完整性，比如用md5，得自己编写数据报文的协定，普通还须要用netty或其它组件的线程模型来处置高并发状况下的tcp恳求，这些上班的难度就不是初级开发能做的。

所以，哪怕是微服务模块间交互用http协定，其实性能不慢，能应答大少数名目的需求，而且开动员来相当便利，所以很多小公司在做利润普通的名目时，优先思考用基于http的组件。

当然假设对性能有更高要求的话，其实要在协定层做改良，比如用tcp，这曾经是很前面的事件了，必定是在穷尽扩容，引入redis和kafka等组件的措施之后再用tcp等协定，但这对程序员的要求就比拟高了。

假设有人面试时说，自己用http或rpc，其实疑问都不大，但大少数人普通仅限于是经常使用api，比如dubbo或openfeign或resttemplate的api。再要进一步，可以说，用到http或rpc，但经过性能测试，发现要在名目里再引入redis等组件来确保业务所需的并发量。

再初级一些的话，可以是联合dubbo或netty底层，说rpc的细节，这还不算，更可以联合自身名目的调优场景说rpc的细节，对比成功tcp通讯的流程或许处置过的疑问。