先說如下的結(jié)論。

1 Spring cloud微服務(wù)，以及第二代微服務(wù)，spring cloud alibaba，可以用openfeign來調(diào)用，即走的是http或https協(xié)議，也可以通過dubbo，dubbo就是所謂的rpc，rpc叫遠(yuǎn)程方法調(diào)用，是一種實(shí)現(xiàn)方式，底層實(shí)現(xiàn)一般是得靠tcp或udp等通訊協(xié)議。

2 http協(xié)議由于會(huì)包含請求頭之類的信息，所以效率相對tcp協(xié)議來說有些慢，但如果并發(fā)量不高，http所謂的低效可以忽略不計(jì)，而https協(xié)議由于多了基于SSL的安全驗(yàn)證動(dòng)作，所以通訊效率比http還略低，但如果并發(fā)量不高的話，這也是可以接受的。

3 在微服務(wù)架構(gòu)，也可以用resttemplate的方式來遠(yuǎn)程調(diào)用，或者是用restful的方式，但restful也是調(diào)用方式，底層實(shí)現(xiàn)是用http或https。

4 可以這樣說，在大多數(shù)的場景，尤其是中小公司所開發(fā)的項(xiàng)目場景，用spring cloud+http協(xié)議，足以應(yīng)對項(xiàng)目的并發(fā)請求。而且一旦并發(fā)量高的話，可以通過基于nacos的擴(kuò)容和基于redis的緩存等手段來應(yīng)對，如果再要進(jìn)一步挖掘性能潛力，那么再用基于tcp的通訊協(xié)議，比如用dubbo或netty，但這對程序員就有要求，而用spring cloud+基于http的openfeign，基本上大多數(shù)初級(jí)開發(fā)也能用。

如下具體展開說明。

1 各微服務(wù)模塊間交互，當(dāng)下一般是基于http協(xié)議，或者是rpc（tcp），比如是dubbo，但兩者的性能差別不大，再者比如要應(yīng)對高并發(fā)，比如是支付場景，一般是啟3個(gè)實(shí)例，用nacos管理，外面再用gateway等網(wǎng)關(guān)來做負(fù)載均衡。

這樣的話，2個(gè)實(shí)例（熱備，避免單點(diǎn)失效），應(yīng)對個(gè)一秒幾百并發(fā)量問題不大，事實(shí)上大多數(shù)項(xiàng)目，真達(dá)不到一秒100的并發(fā)量。換句話說，spring cloud alibaba+nacos+gateway+2個(gè)實(shí)例，哪怕用http協(xié)議，甚至再引入有ssl安全性驗(yàn)證的https，真能滿足大多數(shù)項(xiàng)目的并發(fā)需求。

2 如果想要性能調(diào)優(yōu)，比如要達(dá)到一秒2k甚至更高的并發(fā)量，最直接的方法就是用機(jī)器疊， 比如把一個(gè)實(shí)例部署多個(gè)機(jī)器上，一個(gè)機(jī)器應(yīng)對一秒500的并發(fā)量，那么就部個(gè)4臺(tái)機(jī)器。一般有高并發(fā)需求的項(xiàng)目或者公司都不怎么差錢，部署4個(gè)實(shí)例也是常事。

而且應(yīng)對高并發(fā)，其實(shí)更在于數(shù)據(jù)庫層面和業(yè)務(wù)交互層面，如果在項(xiàng)目里引入redis或者redis集群，或者分庫組件，或者再引入kafka做業(yè)務(wù)異步處理，外帶3，4個(gè)實(shí)例，哪怕用的是基于http協(xié)議的openfeign，應(yīng)對個(gè)2，3k并發(fā)量沒太大問題。

3 還有一點(diǎn)大家需要注意，spring cloud alibaba組件是開箱即用的，所以用基于http協(xié)議的openfeign實(shí)現(xiàn)組件間的調(diào)用，一般有半年項(xiàng)目經(jīng)驗(yàn)的初級(jí)開發(fā)都能做到，或者再引入SSL，用https協(xié)議通訊，開發(fā)難度也不大。

4 微服務(wù)模塊間通訊，除了http，其實(shí)也可以用tcp，tcp的效率是要高于http，本人之前在高并發(fā)項(xiàng)目里做過這方面的調(diào)優(yōu)，同等條件，用tcp協(xié)議通訊，效率一般比https和http協(xié)議高出大概1/3。

但是如果用tcp交互，雖然不用在通訊過程中傳輸業(yè)務(wù)無關(guān)的http請求頭和返回頭信息，但開發(fā)交互過程中，得自己確保數(shù)據(jù)的完整性，比如用md5，得自己編寫數(shù)據(jù)報(bào)文的協(xié)議，一般還需要用netty或其它組件的線程模型來處理高并發(fā)情況下的tcp請求，這些工作的難度就不是初級(jí)開發(fā)能做的。

所以，哪怕是微服務(wù)模塊間交互用http協(xié)議，其實(shí)性能不慢，能應(yīng)對大多數(shù)項(xiàng)目的需求，而且開發(fā)起來相當(dāng)便利，所以很多小公司在做利潤一般的項(xiàng)目時(shí)，優(yōu)先考慮用基于http的組件。

當(dāng)然如果對性能有更高要求的話，其實(shí)要在協(xié)議層做改進(jìn)，比如用tcp，這已經(jīng)是很后面的事情了，一定是在窮盡擴(kuò)容，引入redis和kafka等組件的措施之后再用tcp等協(xié)議，但這對程序員的要求就比較高了。

如果有人面試時(shí)說，自己用http或rpc，其實(shí)問題都不大，但大多數(shù)人一般僅限于是使用api，比如dubbo或openfeign或resttemplate的api。再要進(jìn)一步，可以說，用到http或rpc，但通過性能測試，發(fā)現(xiàn)要在項(xiàng)目里再引入redis等組件來確保業(yè)務(wù)所需的并發(fā)量。

再高級(jí)一些的話，可以是結(jié)合dubbo或netty底層，說rpc的細(xì)節(jié)，這還不算，更可以結(jié)合自身項(xiàng)目的調(diào)優(yōu)場景說rpc的細(xì)節(jié)，比如實(shí)現(xiàn)tcp通訊的流程或者解決過的問題。