前言

前面我們對Web應用開發的底層技術做了一些串聯，也就是從應用程序的本質出發來理解為什么我們的應用程序架構的演變。

特別是Spring框架的出現，它在Web應用開發中扮演的角色，特別是Servlet規范主導了整個Web應用程序的演化全過程。

本文我們接著上面文章，繼續沿著Web應用程序底層數據流的處理和演變來串一下開發現代Web應用程序所需要的知識點和原理。

應用程序設計的隔離與通信

從我們開發應用程序的技術設計角度來說，由于計算機對于業務數據的呈現和業務邏輯的處理都是每次只能處理一部分的，這個過程中會后很多的處理頻次和中間的數據狀態需要保存如此以來，我們開發應用程序最基礎的需求就是對不同數據的隔離存儲和相互使用的通信聯系的建立和控制。

也就是說我們應用程序使用的對象實例是有區域限制的，也就是可見性限制。因為我們知道，我們編程的本質就是對數據進行隔離和通信。

而在我們使用類似Java的高級語言開發應用時，Java語言就為我們提供了很多規范的定義，讓我們能夠實現對數據的封裝分離，同時還能在某個特定的范圍內進行通信交換。

其本質就是為數據的存儲空間添加一個標記，使得引用和被引用的圈層之間相互隔離，同時又能通過某種地址表示獲取到該數據。

這些就是高級開發語言中各類關鍵字的作用。

Web應用層級開發內容

在Web應用程序層級，我們在開發一個應用程序時，其實只是開發了該應用程序的具體數據處理部分，而哪些網絡連接，數據解析以及跟操作系統交互部分都是web服務器應用來完成的。

所以嚴格來說，我們開發的應用程序只是涉及到業務的數據表達和邏輯的實現上，而沒有去關注更為基礎的網絡連接，數據接收和發送以及中間調用的系統資源等。

可以說Web應用程序只是整個應用的一部分，或者說我們開發人員之編寫了一個內容部分而外殼是有web服務器來負責提供的。這就要求我們在開發這類應用程序時，需要考慮web服務器為我們提供的環境接口以及web服務器對于能夠在它上面運行的應用程序的規范和要求。

這也是Servlet規范中的主要內容，最初我們會將這種規范形象化為JSP，后來到JSF再到JSFX等。

當然這是對于處理內容表現上一些規范，如果我們不需要展現，那么可以直接使用二進制數據流，也可以使用定義的任何數據類型。

這取決于具體的應用環境和遵循的協議。

我們這里只說常用的基于HTTP的服務和處理。HTTP協議規定了每次傳輸的數據結構，以及在控制傳輸過程中常用的命令和回復代碼以及內容表現形式，而它會抽象為我們編程的具體函數和方法，將其植入到Servlet規范的service()業務處理的入口方法里，這些可以具體看Servlet規范對于HttpServletXXX等的說明。

有了Servlet規范實現的Web服務器，我們就可以將具體的Web應用部署到該服務器上運行了。

為了讓Web服務器知道它要管理和運行的應用程序，我們必須通過一個指定格式的文件web.xml來告訴它，該文件被稱為應用程序在web服務器上的部署描述文件。

我們只需要將編寫的應用程序內容按照該文件描述的格式去進行描述，Web服務器就能夠識別它們，并將我們編寫的內容跟服務器本身無縫連接成一個完整的web應用。

Web應用部署規范實現

跟我們電器跟電源之間的連接都需要有符合標準的電源插槽和插頭一樣，我們編寫的應用程序跟Web服務器應用的連接也是標準的，在Spring MVC這個框架里，我們可以通過xml，annotation以及編程等方式來描述這些接口。

這里的注解(annotation)是高級語言編譯器的一個新功能，它能夠獨立的讀取和編譯這些注解的內容，以便在具體編碼過程中一些非業務邏輯的內容無法表現在程序的邏輯代碼中，而以標注的形式提供。在Spring MVC 2.5以后的版本里，這被稱為注解編程方式。

我們可以使用這種方式將一些對組件的說明和定義分布到整個應用程序的代碼中，而不需要集中的按照XML格式寫到一個列表里。

Spring MVC框架組件

關于Spring MVC框架，其實就是對于一個應用程序的編寫來說，我們需要涉及到跟容器的交互，接收數據，業務邏輯處理實現，將數據以某種數據格式發送展現給請求者等。

根據工程學的知識，要想能夠便于管理，我們不能將這些功能性內容實現和非功能性內容實現混合在一起，同時為了便于管理有人就提出了一個實現模型，就是模型-視圖-控制器，有控制器C負責非功能性流程控制，而模型M來處理數據實現，視圖V來提供處理結果的展現，這就是著名的MVC模型。

它的使用無法就是為我們的應用程序編寫在不同作用組件管理上做一下分類，將類似功能的組件內容定義到同一分類里，便于管理，同時能夠很好的進行分類管理，不至于太混亂。

其實這些所有的MVC組件都是一樣的東西，只是功能不同而已。為了劃分這些分類我們需要為它們定義標識符，也就是做個標記。

最開始的思路是按照工程目錄的文件夾路徑來分類管理，后來引入了描述文件，比如xml或者YAML格式等，現在流行的是注解模式，跟所有的注解定義一樣只是定義了一個標記。

所以我們可以為MVC三類組件分別定義不同的標記，只為了便于管理。

說起Spring容器和Spring MVC模式的關系，簡單說MVC是對應用程序組件的功能性分類標識，在Spring容器看來他們都是多了個標簽符合的容器管理組件而已。

一樣遵循相關的受Spring容器管理組件的規范。

Servlet規范在Spring MVC框架中的實現

從Web服務器級別來看Spring容器，其實就是一個特定的Servlet實現。

最初的時候，我們直接通過編寫一個個Servlet組件來為應用程序提供數據處理服務，現在我們將Spring容器定義成一個特定的Servlet，并且結合統一資源定位符和Servlet組件要處理的目標資源路徑

一起來定位最終的請求處理組件。我們從Web應用程序的部署描述文件Web.xml的Servlet描述可以看到，我們可以定義多個Servlet組件來處理不同的路徑上的請求。

這是Web服務器級別的Servlet組件，現在由于Spring容器和Spring MVC框架的引入，我們不再直接基于Web服務器來編寫一個個Servlet組件提供服務了，而是通過預定義一個服務器路徑，然后在該路徑下提供多個后續不同資源定位符的邏輯處理組件。

從而使得我們可以將特定目錄內容交給一個復雜應用程序來處理。這個復雜應用就是基于Spring容器管理的多個組件實現。

DispatcherServlet組件

要做到這一點，我們首先要在Web應用程序的部署描述中定義這個入口Servlet，而這個Servlet一般由Spring框架提供的特殊實現，DispatcherServlet組件。

它的任務就是作為一個Servlet組件部署到Web服務器中，在服務器啟動時將它跟Web服務器連接起來，從而能夠成為為其映射的路徑請求提供處理。

如果按照傳統的Servlet組件處理具體應用方式，這里只有一個Servlet組件實現顯然是無法提供多種請求處理服務的。所以，我們在這里引入了一種前端控制模式實現。

即在該DispatcherServlet的實現邏輯中增加了統一資源定位列表和對應請求處理器Handler定義列表，對每個訪問該路徑的請求截取其所訪問的資源定位符進行比較和路由處理。

從而將該請求數據發送給綁定了該資源定位URL部分的處理器組件上，從而將請求路由給它處理。這就是一個路由器的實現，當然它還包括很多過濾和數據轉換處理，以及對于資源定位部分的匹配規則和算法實現等。

Spring容器管理組件

總體上使用Spring容器和Spring MVC來實現一個Web應用程序來說，需要將我們應用程序的所有組件都定義和聲明為遵循Spring容器組件管理規范的類定義，然后在Web服務器需要讀取的每個Web應用程序的部署描述文件web.xml中提供的定義聲明，這個Servlet應該是DispatcherServlet，并將其綁定在我們的應用程序的根路徑上。

使用過Spring MVC框架的人都知道Spring還提供一個符合Servlet規范的ContextLoaderListener實現，它用來在服務器啟動過程中加載資源內容。

我們會將Spring容器的內容通過這個監聽器接口來導入到Web服務器中使之成為該Web應用程序的可用資源。

而在DispatcherServlet被調用后，它會將Spring容器的配置信息讀入并初始化以提供各類實例依賴項。也就是說在Web服務一啟動這些資源內容就會被放入到某個應用程序上下文中，然后DispatcherServlet會用這些資源來初始化Spring容器定義組件實例，完成Spring MVC框架的實現。

當然現代應用程序開發的內容相當復雜，需要使用到很多外部系統資源或者第三方軟件資源，比如數據庫連接，Java的目錄和接口資源等。

我們過去傳統開發會將它根據Servlet規范實現成有狀態，無狀態，會話等組件，現在有了Spring容器，我們完全可以將它們按照Spring容器能夠管理組件的規范來封裝和定義。

從而讓這些資源能夠作為Spring 容器管理的組件使用，并受到Spring容器的全生命周期管理。

而Spring MVC整體會嵌入到一個Servlet實現中，從而在一個特定的目錄下對其所有請求進行分類處理。也就是我們前面所說的通過路由器的實現，將不同的網絡請求根據資源定位符來映射到具體的處理組件控制器部分。

由它負責協調數據處理，結果展示模板解析，以及相關的數據持久化處理等。總之MVC框架之上一個功能意義上的分類，在技術上只是對眾多不同的應用程序專用組件進行標簽化分類而已。

Web應用開發與微服務

使得這些功能類似的組件受到統一的管理，我們開發人員在工程目錄組織和編譯器處理時方便，其實它們本質上都是裝在容器化的依賴注入的組件。

隨著應用程序架構的不斷演變，現在由于云計算和分布式存儲技術的發展，微服務架構成為了主流，它能很好的克服過去我們開發的傳統的巨型化應用的很多弊端，比如可靠性，可維護性，容錯性等方面的缺陷。

就是將原來的應用程序從功能進行分類封裝，同時在架構上做垂直化分解，特別是虛擬機容器化技術的發展，為在同一臺主機上運行多個容器提供了可能，也就是說同樣的服務組件可以在同一臺機器上獨立運行多個而由于容器化的隔離相互不會產生干擾。

如此依賴過去傳統開發的應用程序構成組件是運行在同一個Web服務器上，各個功能之間的相互依賴和調用都是在同一個依賴管理容器中，比如同一個Spring 容器，所以它們是運行在同一個進程中的多個線程之間的調用和訪問。

而到了微服務時代，不同功能的組件可能會垂直化成一個獨立的應用程序，功能單一的服務程序，它會以獨立進程的形式運行在主機上，如此以來我們在去組織這些獨立的進程構建綜合型應用服務時，其相互之間的依賴調用就成了跨進程之間的或者跨網絡之間的通信了。

這種通信需要依靠進程間調用IPC或者網絡對等機器之間的連接和訪問最常用的是基于HTTP的調用。

從傳統的Web應用程序到現在流行的微服務架構的變化其實就是一個從線程間調用到進程間或者跨網絡之間通信的實現轉變，這樣帶來的好處是我們的服務的彈性和可用性以及彈性大大增強。

而缺點在于開發的復雜程度極度的增大，因為它需要的技術支持更加細化和龐雜，比如網絡通信知識，容器化和管理編排知識，進程間調用的協議以及編解碼，跨網絡調用的穩定性處理，安全以及數據分布式存儲等一些列的技術。

總結

雖然微服務涉及到的新技術很多，但是其底層的核心邏輯還是對于網絡數據流的處理，以及如何在對等點之間建立穩定的連接，在服務器不穩定時如何通過熔斷或者快速中斷機制來保證服務的穩定提供等。

后面我將另找時間來逐步說一下微服務架構底層實現的東西。

總結

以上是生活随笔為你收集整理的指定应用程序网络连接_总结Java开发Web应用程序应该理解的几个知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。