如何用Java實現(xiàn)簡單的HTTP服務(wù)器

關(guān)于SpringCloud遠(yuǎn)程調(diào)用采用HTTP而非RPC。

首先SpringCloud開啟Web服務(wù)依賴于內(nèi)部封裝的Tomcat容器，而今信息飛速發(fā)展，適應(yīng)大流量的微服務(wù)，采用Tomcat處理HTTP請求，開發(fā)者編寫Json作為資源傳輸，服務(wù)器做出相應(yīng)的響應(yīng)，可以更加的靈活處理業(yè)務(wù)數(shù)據(jù)，而HTTP協(xié)議是跨平臺的，符合微服務(wù)B/C數(shù)據(jù)交互的方式，可以的一套服務(wù)器對應(yīng)移動H5、App、小程序提供服務(wù)。

RPC基于TCP協(xié)議，客服端與服務(wù)端需要進(jìn)行三次握手完成可靠連接，第四步進(jìn)行數(shù)據(jù)傳輸。因為TCP是數(shù)據(jù)傳輸層，傳輸協(xié)議需要服務(wù)器統(tǒng)一編寫，進(jìn)行二進(jìn)制傳輸，依賴序列化和反序列化規(guī)則，對于大部分應(yīng)用需要靈活變動數(shù)據(jù)則不適用，RPC常用于Socket連接或一些基本不變動的傳輸格式數(shù)據(jù)，減少數(shù)據(jù)變動帶來的開發(fā)成本

建立Socket連接至少需要一對套接字，其中一個運行于客戶端，稱為ClientSocket ，另一個運行于服務(wù)器端，稱為ServerSocket ，套接字之間的連接過程分為三個步驟：服務(wù)器監(jiān)聽，客戶端請求，連接確認(rèn)。

一個簡單HTTP請求處理

在Web應(yīng)用中，瀏覽器請求一個URL，服務(wù)器就把生成的HTML網(wǎng)頁發(fā)送給瀏覽器，而瀏覽器和服務(wù)器之間的傳輸協(xié)議是HTTP,那么接下來我們看下如何用Java來實現(xiàn)一個簡單的HTTP服務(wù)器。

RPC

RPC(Remote Procedure Call：遠(yuǎn)程過程調(diào)用)：是一種進(jìn)程間通信方式，是一種技術(shù)的思想，而不是規(guī)范。它允許程序調(diào)用另一個地址空間（通常是共享網(wǎng)絡(luò)的另一臺機(jī)器上）的過程或函數(shù)，而不用程序員顯式編碼這個遠(yuǎn)程調(diào)用的細(xì)節(jié)。即程序員無論是調(diào)用本地的還是遠(yuǎn)程的函數(shù)，本質(zhì)上編寫的調(diào)用代碼基本相同。

通俗的說法就是：比如說現(xiàn)在有兩臺服務(wù)器A和B，一個應(yīng)用部署在A服務(wù)器上，另一個應(yīng)用部署在B服務(wù)器上，如果A應(yīng)用想要調(diào)用B應(yīng)用提供的方法，由于他們不在一臺機(jī)器下，也就是說它們不在一個JVM內(nèi)存空間中，是無法直接調(diào)用的，需要通過網(wǎng)絡(luò)進(jìn)行調(diào)用，那這個調(diào)用過程就叫做RPC。

RPC兩個核心模塊：通訊，序列化。

注意：無論是何種類型的數(shù)據(jù)，最終都需要序列化轉(zhuǎn)換成二進(jìn)制流在網(wǎng)絡(luò)上進(jìn)行傳輸，數(shù)據(jù)的發(fā)送方需要將對象序列化轉(zhuǎn)換為二進(jìn)制流，而數(shù)據(jù)的接收方則需要把二進(jìn)制流反序列化為對象。

Restful（HTTP）

Restful 指的是一組架構(gòu)約束條件和原則。" 如果一個架構(gòu)符合 Restful 的約束條件和原則，就稱它為 Restful 架構(gòu)。隱藏在 Restful 背后的理念就是使用 Web的現(xiàn)有特征和能力，更好地使用現(xiàn)有 Web 標(biāo)準(zhǔn)中的一些準(zhǔn)則和約束。

雖然 Restful 本身受 Web技術(shù)的影響很深， 但是理論上 Restful 架構(gòu)風(fēng)格并不是綁定在 HTTP 上，只不過目前 HTTP 是唯一與 Restful 相關(guān)的實例。所以我們這里描述的 Restful 也是通過 HTTP 實現(xiàn)的 Restful。

RPC和HTTP的區(qū)別

首先，兩者十分相似，有請求有響應(yīng)。

不同：

RPC需要滿足像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)，也就是對調(diào)用過程在API層面進(jìn)行封裝。

Http協(xié)議沒有這樣的要求，因此請求、響應(yīng)等細(xì)節(jié)需要我們自己去實現(xiàn)。

優(yōu)點

RPC更加透明，對用戶方便。

HTTP方式更加靈活，沒有規(guī)定API和語言，跨語言，跨平臺。

缺點

RPC需要在API層面進(jìn)行封裝，限制了開發(fā)的語言環(huán)境。

選擇

速度方面：RPC速度比HTTP快，底層都是TCP，HTTP消息往往比較臃腫，但是可以采用gzip壓縮。

難度方面：RPC實現(xiàn)有點兒復(fù)雜，HTTP相對比較簡單。

靈活性方面：HTTP更靈活，不需要關(guān)系實現(xiàn)的細(xì)節(jié)，可以跨平臺，跨語言。

未來發(fā)展方向

微服務(wù)，強(qiáng)調(diào)獨立，自治，靈活。RPC限制較多，因此微服務(wù)框架中，一般都會采用基于HTTP的rest風(fēng)格服務(wù)。

審核編輯：湯梓紅