先说如下的结论。
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通讯的流程或者解决过的问题。
