在當(dāng)今的技術(shù)環(huán)境下，微服務(wù)架構(gòu)已經(jīng)廣泛流行并深刻地改變了應(yīng)用程序的構(gòu)建和交互方式。

傳統(tǒng)上，應(yīng)用程序之間的通信往往依賴于明確指定 IP 地址與端口號(hào)的組合，然而隨著微服務(wù)理念的推進(jìn)，服務(wù)名稱調(diào)用逐漸成為主流，這使得我們不得不重新審視應(yīng)用程序是否還需要指定端口這一問(wèn)題。

傳統(tǒng)架構(gòu)

圖片

從傳統(tǒng)的單體應(yīng)用架構(gòu)來(lái)看，指定端口是實(shí)現(xiàn)網(wǎng)絡(luò)通信的關(guān)鍵步驟。

例如，一個(gè)基于 Java 的 Web 應(yīng)用程序部署在服務(wù)器上，開發(fā)人員需要為其指定一個(gè)特定的端口，如 8080，這樣客戶端才能通過(guò)訪問(wèn)服務(wù)器的 IP 地址加上該端口號(hào)來(lái)請(qǐng)求相應(yīng)的資源。

在這種模式下，端口的指定明確了應(yīng)用程序在網(wǎng)絡(luò)中的接入點(diǎn)，就如同給一座房子確定了一個(gè)獨(dú)一無(wú)二的門牌號(hào)，方便外界與之進(jìn)行交互。它使得網(wǎng)絡(luò)請(qǐng)求能夠準(zhǔn)確地找到對(duì)應(yīng)的應(yīng)用程序?qū)嵗?，從而?shí)現(xiàn)數(shù)據(jù)的傳輸與處理。

然而，微服務(wù)架構(gòu)帶來(lái)了全新的思路。在微服務(wù)架構(gòu)中，眾多小型的、獨(dú)立的服務(wù)相互協(xié)作以構(gòu)建復(fù)雜的應(yīng)用系統(tǒng)。如果依然采用傳統(tǒng)的 IP + 端口的調(diào)用方式，會(huì)面臨諸多問(wèn)題。

首先，微服務(wù)的數(shù)量眾多且動(dòng)態(tài)變化，服務(wù)的啟動(dòng)、停止、更新以及擴(kuò)展都可能頻繁發(fā)生。這意味著需要不斷地管理和協(xié)調(diào)大量的端口分配，以避免端口沖突，這無(wú)疑是一項(xiàng)復(fù)雜且容易出錯(cuò)的任務(wù)。

其次，在一個(gè)復(fù)雜的微服務(wù)集群中，服務(wù)的 IP 地址可能由于容器編排、自動(dòng)伸縮等機(jī)制而動(dòng)態(tài)變化，依賴固定的 IP + 端口進(jìn)行調(diào)用會(huì)使整個(gè)系統(tǒng)變得脆弱且難以維護(hù)。

微服務(wù)架構(gòu)

圖片

隨著系統(tǒng)架構(gòu)升級(jí)進(jìn)化，當(dāng)大家來(lái)到微服務(wù)的時(shí)代中，服務(wù)名稱調(diào)用機(jī)制就展現(xiàn)出了諸多優(yōu)勢(shì)。

借助于服務(wù)發(fā)現(xiàn)組件，如 Consul、Eureka 、Nacos 等，每個(gè)微服務(wù)在注冊(cè)中心注冊(cè)自身時(shí)，使用一個(gè)具有語(yǔ)義的服務(wù)名稱而非具體的 IP 和端口。

當(dāng)一個(gè)服務(wù)需要調(diào)用另一個(gè)服務(wù)時(shí)，它只需向服務(wù)發(fā)現(xiàn)組件查詢目標(biāo)服務(wù)的名稱，服務(wù)發(fā)現(xiàn)組件就會(huì)返回可用的服務(wù)實(shí)例的實(shí)際網(wǎng)絡(luò)地址信息（包括 IP 和端口），然后進(jìn)行調(diào)用。

這種方式將服務(wù)的網(wǎng)絡(luò)細(xì)節(jié)進(jìn)行了抽象和封裝，使得服務(wù)之間的調(diào)用更加靈活和可靠。開發(fā)人員無(wú)需關(guān)注具體的端口分配情況，降低了系統(tǒng)的復(fù)雜性和維護(hù)成本，提高了系統(tǒng)的可擴(kuò)展性和彈性。

但這并不意味著端口在當(dāng)今的應(yīng)用程序中就完全失去了作用。盡管在微服務(wù)內(nèi)部的服務(wù)間調(diào)用可以通過(guò)服務(wù)名稱來(lái)實(shí)現(xiàn)，但是端口仍然不可或缺。

例如，在微服務(wù)架構(gòu)中，我們通常都會(huì)有一個(gè)網(wǎng)關(guān)服務(wù)對(duì)外提供服務(wù)，而這個(gè)網(wǎng)關(guān)服務(wù)通常跟流量入口綁定，比如 Nginx、K8s 里的 Ingress、阿里云的 SLB 等。而這些流量入口將流量轉(zhuǎn)到網(wǎng)關(guān)服務(wù)時(shí)，就需要網(wǎng)關(guān)服務(wù)提供明確的端口了。

在 SpringBoot 應(yīng)用中如何啟動(dòng)隨機(jī)端口？

其實(shí)很簡(jiǎn)單，大家都知道 SpringBoot 中可以通過(guò) server.port 指定端口，如果要啟動(dòng)隨機(jī)端口，將 server.port 設(shè)置為 0 即可。

server.port 設(shè)置為 0 后，可以讓操作系統(tǒng)為我們動(dòng)態(tài)分配一個(gè)可用的端口無(wú)需我們?cè)谑謩?dòng)指定。

最后

OK，傳統(tǒng)架構(gòu)中，大家可能還需要用服務(wù)的 ip + 端口來(lái)進(jìn)行通信，在微服務(wù)架構(gòu)中，除了網(wǎng)關(guān)應(yīng)用還需要提供明確的端口號(hào)外，業(yè)務(wù)應(yīng)用的 ip + 端口號(hào)已經(jīng)被服務(wù)發(fā)現(xiàn)、注冊(cè)組件所隱去，大家基本已經(jīng)不再關(guān)心業(yè)務(wù)應(yīng)用的端口號(hào)了。

在這里也是做一個(gè)投票，問(wèn)一下大家是否愿意在自己的項(xiàng)目中將 server.port設(shè)置為0。