先說如下的結論。

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通訊的流程或者解決過的問題。