在當今的技術環境下，微服務架構已經廣泛流行并深刻地改變了應用程序的構建和交互方式。

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

傳統架構

圖片

從傳統的單體應用架構來看，指定端口是實現網絡通信的關鍵步驟。

例如，一個基于 Java 的 Web 應用程序部署在服務器上，開發人員需要為其指定一個特定的端口，如 8080，這樣客戶端才能通過訪問服務器的 IP 地址加上該端口號來請求相應的資源。

在這種模式下，端口的指定明確了應用程序在網絡中的接入點，就如同給一座房子確定了一個獨一無二的門牌號，方便外界與之進行交互。它使得網絡請求能夠準確地找到對應的應用程序實例，從而實現數據的傳輸與處理。

然而，微服務架構帶來了全新的思路。在微服務架構中，眾多小型的、獨立的服務相互協作以構建復雜的應用系統。如果依然采用傳統的 IP + 端口的調用方式，會面臨諸多問題。

首先，微服務的數量眾多且動態變化，服務的啟動、停止、更新以及擴展都可能頻繁發生。這意味著需要不斷地管理和協調大量的端口分配，以避免端口沖突，這無疑是一項復雜且容易出錯的任務。

其次，在一個復雜的微服務集群中，服務的 IP 地址可能由于容器編排、自動伸縮等機制而動態變化，依賴固定的 IP + 端口進行調用會使整個系統變得脆弱且難以維護。

微服務架構

圖片

隨著系統架構升級進化，當大家來到微服務的時代中，服務名稱調用機制就展現出了諸多優勢。

借助于服務發現組件，如 Consul、Eureka 、Nacos 等，每個微服務在注冊中心注冊自身時，使用一個具有語義的服務名稱而非具體的 IP 和端口。

當一個服務需要調用另一個服務時，它只需向服務發現組件查詢目標服務的名稱，服務發現組件就會返回可用的服務實例的實際網絡地址信息（包括 IP 和端口），然后進行調用。

這種方式將服務的網絡細節進行了抽象和封裝，使得服務之間的調用更加靈活和可靠。開發人員無需關注具體的端口分配情況，降低了系統的復雜性和維護成本，提高了系統的可擴展性和彈性。

但這并不意味著端口在當今的應用程序中就完全失去了作用。盡管在微服務內部的服務間調用可以通過服務名稱來實現，但是端口仍然不可或缺。

例如，在微服務架構中，我們通常都會有一個網關服務對外提供服務，而這個網關服務通常跟流量入口綁定，比如 Nginx、K8s 里的 Ingress、阿里云的 SLB 等。而這些流量入口將流量轉到網關服務時，就需要網關服務提供明確的端口了。

在 SpringBoot 應用中如何啟動隨機端口？

其實很簡單，大家都知道 SpringBoot 中可以通過 server.port 指定端口，如果要啟動隨機端口，將 server.port 設置為 0 即可。

server.port 設置為 0 后，可以讓操作系統為我們動態分配一個可用的端口無需我們在手動指定。

最后

OK，傳統架構中，大家可能還需要用服務的 ip + 端口來進行通信，在微服務架構中，除了網關應用還需要提供明確的端口號外，業務應用的 ip + 端口號已經被服務發現、注冊組件所隱去，大家基本已經不再關心業務應用的端口號了。

在這里也是做一個投票，問一下大家是否愿意在自己的項目中將 server.port設置為0。