設計與開發(fā)應用服務器相關技術

1、設計與開發(fā)應用服務器（二）-相關技術服務器的設計與開發(fā)涉及到諸多技術和問題，歸納一下大致可以分為以下幾種：· 服務器啟動和接收數(shù)據(jù)過程· 多線程策略· NIO· 長連接· 同步與異步· 配置化支持· 責任鏈模式· 集群與負載均衡· 數(shù)據(jù)包設計· 服務端連接協(xié)議· 客戶端連接技術服務器啟動和數(shù)據(jù)請求過程 各種服務器所提供的功能和實現(xiàn)機制都不盡相同，但在啟動和數(shù)據(jù)請求這塊都長得差不多，遵循固定的一些流程和模式，啟動過程一般按一下流程：1）以main方法的形式提供由外部腳本觸發(fā)的入口2）載入

2、配置文件，解析并構(gòu)建上下文3）初始化各個組件和資源4）注冊和啟動監(jiān)控和管理組件5）啟動連接監(jiān)聽數(shù)據(jù)請求過程一般按一下流程：1）偵聽Socket2）包裝Connection3）解析并包裝數(shù)據(jù)4）請求處理5）向client發(fā)送處理結(jié)果多線程策略 多線程的策略一般可以采取兩種方式，一種是每一個線程負責監(jiān)聽、處理和返回結(jié)果所有事情，另外一種是把監(jiān)聽、接收、處理分開，各自都有獨立的線程去處理。第一種策略比較簡單，適用于處理不復雜的場景，圖示如下：第二種方式把一個較長的請求處理過程分割開，區(qū)分對待，這樣能提高系統(tǒng)的吞吐量，比較適用與較為復雜的請求處理場景，圖示如下：apache perfork在此基礎上還

3、有個main進程對這些work子進程進行管理，會根據(jù)請求的繁忙程度來調(diào)整work進程的數(shù)目，這也是可以借鑒的。NIO NIO的特性非常適用于網(wǎng)絡服務器的接收數(shù)據(jù)這塊，因為不是每時每刻都有數(shù)據(jù)請求，因此沒必要搞一堆Accept線程在那里監(jiān)聽等待，以Tomcat6的NIO接收數(shù)據(jù)為例：Amoeba也是采用NIO來接收數(shù)據(jù)流：長連接 長連接顧名思義就是客戶端與服務端保持連接，而不是每次請求都新建連接并在請求完后關閉連接，好處有以下幾點：· 減少新建和銷毀線程所帶來的代價· 減少線程上下文切換帶來的代價· 適用與服務端需要監(jiān)控客戶端狀態(tài)的場景，不需要通過客戶端定時輪詢來完

4、成· 建立了服務器主動向客戶端推的通道性能上與短連接的差異可以見以前的博文 構(gòu)建高性能web之路-web服務器長連接 同步與異步 一般的情況下服務器端處理客戶端請求都是同步的，客戶端請求提交后會在一定的超時時間里等待服務器的response，這比較適用于短時間里能處理 完的請求，但如果一些請求，比如文件上傳，在規(guī)定的超時時間里沒法處理完，這樣異步的處理就比較合適了，所謂異步就是客戶端的請求提交后就可以結(jié)束這次請 求，不用等待response返回，在服務端處理完后主動把結(jié)果通知給客戶端。Tomcat6推出的Comet技術即就是異步處理的典型，通過Comet 技術，客戶端所需要的resp

5、onse信息不再需要主動的去索取，而是在服務器端以event的形式推至客戶端。更多Comet的信息可見Tomcat官方文檔 配置化支持 服務器的各種參數(shù)，比如線程池大小、連接協(xié)議等等，需要暴露出來可以配置，因此需要有配置管理機制。一般說來配置文件多以xml或 properties形式提供。對于properties比較簡單，只是很難體現(xiàn)層次化結(jié)構(gòu)，解析起來比較簡單，通過Properties類就能很方便地 進行解析。而xml體現(xiàn)的信息更友好、更清晰，解析xml的方法比較多，一般用以下幾種：· SAX· DOM· JDOM、DOM4j、Digester等前面兩種比較原生

6、態(tài)，SAX和DOM的區(qū)別就不再累述，JDOM、DOM4j和Digester都是基于前兩種以上的開源框架，可以更加方便地調(diào)用。個人感覺如果xml不夠復雜，不必使用太多的框架，原生態(tài)的東西就夠用了。解析完配置文件后，一般可以用更加有語義化的java bean來存儲這些配置信息，這樣可以更加方便其他模塊的調(diào)用責任鏈模式 責任鏈模式在服務器設計開發(fā)中比較常用，責任鏈模式的類圖如下所示：責任鏈模式使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。Tomcat主要的架構(gòu)pipeline-valve就是基于責任鏈模

7、式。通過責任鏈模式可以比較方便擴展對每次請求的處理，并且能很清新地明確各種處理之間的順序和依賴關系集群與負載均衡 為了保持集群實現(xiàn)簡單，并更容易地實現(xiàn)橫向擴展，盡量做到服務器之間無狀態(tài)性，若需要狀態(tài)可以參考Darkstar用集中式的Data service來抽象，保持邏輯處理的服務器是獨立和平等的。在負載均衡這塊可以采用硬負載（如F5）或軟負載（LVS），這些都是比較成熟的方案，但如 果負載均衡仍然是系統(tǒng)的瓶頸，可以采用客戶端負載均衡的做法，客戶端做路由的機理如下圖所示：1）當服務端ready后，會和配置中心建立連接，把自身狀態(tài)信息發(fā)送到配置中心2）當客戶端ready后，會和配置中心建立連接，

8、把所需要服務的相關信息和路由策略同步到本地3）服務端有變動時，比如有機器宕機或遷移，配置中心會感知，并把改動立刻同步到客戶端4）客戶端依據(jù)本地的路由信息直接與服務端通信這種機制的最大優(yōu)點就是客戶端與服務端直接通信，消除了loadBalance單點，但也具有明顯的缺點，也就是很難做到按照服務器空閑情況進行很智能的均衡負載，并且服務端的變動也很難立刻同步到客戶端。一般有以下實現(xiàn)措施：1）客戶端、服務端和配置中心彼此之間保持長連接，保障通信的即時性2）路由策略以業(yè)務為維度，如按方法、接口或者參數(shù)來路由。或者就是簡單的隨機和輪詢3）通過配置中心做一些監(jiān)控的工作，保障服務端的可用性4）在客戶端做容錯，比

9、如連接不上服務端（服務端狀態(tài)同步延遲）時，做重試處理數(shù)據(jù)包設計 Tomcat是基于HTTP的服務器，因此它接收和發(fā)送的數(shù)據(jù)都是基于HTTP協(xié)議的。如果自己設計的服務器不是基于HTTP，比如是原始的socket，那么就需要設計一套數(shù)據(jù)協(xié)議，例如：數(shù)據(jù)協(xié)議的設計關鍵在于簡單方便并容易擴展，數(shù)據(jù)協(xié)議就是客戶端和服務器端交流的手段，功能越復雜數(shù)據(jù)協(xié)議就越復雜，數(shù)據(jù)包就會越來越大，因此在設計上需要有所權(quán)衡服務端連接協(xié)議 當客戶端多樣化后就會有多種連接協(xié)議共存的需求，比如activeMQ和tomcat就支持多種connector，以activeMQ為例就支持 openwire、ssl、stomp、xmpp

10、等不同協(xié)議。支持多種協(xié)議無非就是在連接模塊多開啟幾個端口的監(jiān)聽和相應協(xié)議的解析，做得更好的話最好是 插件的模式，實現(xiàn)可插拔，這樣就不會因為多種協(xié)議搞得整個系統(tǒng)實現(xiàn)過于復雜和混亂客戶端連接技術 客戶端連接方案可以有多種選擇，如果支持http協(xié)議，可以使用jdk提供的HttpClient工具，也可以直接使用網(wǎng)頁。如果是socket， 使用java net里TCP或UDP相關的類即可。這里需要提一下，最近看到很多人采用flash作為客戶端來和服務端通信，并取得很不錯的效果，flash提供了這 么一些工具和API來支持網(wǎng)絡連接和數(shù)據(jù)傳送：· Flash Socket API：通過這類API，

11、使ActionScript代碼可以建立套接字連接并讀取和寫入原始的二進制數(shù)據(jù)，其沒有指定接收或發(fā)送的數(shù)據(jù)格式。· External Interface API：通過這類API，可以實現(xiàn)javascript與actionscript之間的通信，當然這里還有安全沙箱的存在。· Shared Object API：通過這類API，可以實現(xiàn)在本地或服務器上面存儲數(shù)據(jù)。當數(shù)據(jù)保存在本地的時候，其默認的可以存儲的數(shù)據(jù)是每個域名100K，其與cookie還是有很大的不同點的。· LocalConnection API：通過這類API，可以實現(xiàn)swf文件之間的通信，這種通信是可以跨瀏覽器的。以上API的具體使用可以參考一下Flash的文檔，這里想說一下flash做為客戶端的好處：