分布式服務架構

分布式服務架構一、     引言：

分布式服務在公司專屬應用程式之重，不再多說。本文主要介紹分布式服務架構涉及的基本網路通訊原理、應用級遠程通訊協定介紹和流行的分布式服務架構介紹，以達到對分布式服務架構的整體理解。

二、     網路通訊的基本原理：

從層面意思理解，網路通訊需要將資料從一台機器傳輸到另一台機器，達到多台機器通訊目的，具體的網路傳輸方式基於傳輸協議和網路IO。其中比較常見的傳輸協議有：HTTP、TCP、UDP等，HTTP、TCP、UDP協議也是基於SOCKET概念上為某類應用情境而拓展出來的傳輸協議。網路IO主要有BIO、NIO、AIO三種方式。所有的分布式通訊協定都應該基於這個原理而實現。

三、     應用級遠程通訊協定：

在網路通訊傳輸的基本原理中，需要將傳輸資料轉化成流，通過某種協議傳輸到另一台電腦，遠端電腦接收到流後，需要反轉化成正確資料，在對資料進行處理後，通過相同的方式響應調用端電腦。

那麼分布式服務架構的出現就是封裝繁雜的流轉換，替換成一種更加易用和理解的新的標準傳輸協議。但在學習分布式服務架構時，同樣需要按照如下問題進行思考：

1.      資料轉送的標準格式

2.      基本的資料轉送協議

3.      資料與流之間的轉化方式

4.      接受和處理流的方式

如下，對分布式服務架構使用的新標準協議進行討論。

1.     RMI

Java 遠程方法調用（Java Remote Method Invocation），一種用於實現遠端程序呼叫的API。它使客戶機上啟動並執行程式可以調用遠程伺服器上的對象。

下面來看基於RMI的遠程通訊過程和原理。

1.1    用戶端發起請求，請求轉交至RMI用戶端的Stub類；

1.2    Stub類將請求的介面、方法、參數等資訊進行序列化；

1.3    基於socket將序列化的物件流程傳輸到服務端；

1.4    服務端將接受到的序列化流轉化至相應的skelton類；

1.5    Skelton類將請求的資訊還原序列化後調用實際的處理類；

1.6    處理類處理完畢後將結果返回給skelton類；

1.7    Skelton將結果序列化，通過socket將流傳輸給用戶端stub類；

1.8    Stub類將結果還原序列化的對象返回給調用者。

下面是jboss-remoting對於此過程的示圖。

思考問題：

1.1    資料轉送的標準格式

Java ObjectStream,故請求參數需要進行序列化。

1.2    基本的資料轉送協議

Socket

1.3    資料與流之間的轉化方式

基於java的序列化機制將請求和響應對象轉化為流。

1.4    接受和處理流的方式

程式監聽響應的連接埠號碼，但有流進入後基於java序列化機制將流還原序列化，並根據RMI協議擷取相應的服務端處理對象，進行調用並處理，處理完成後同樣基於java序列化機制將資料返回給用戶端。

缺點：

1.1    不能跨語言，僅支援Java程式間的通訊。

1.2    RMI只能通過RMI協議進行通訊，無法通過HTTP協議進行訪問，無法穿透防火牆。

1.3    不支援分散式交易JTA。

1.4    RMI架構對於安全性、事務、可拓展性的支援非常有限。

2.     XML-RPC

XML-RPC(XML Remote Procedure Call即XML遠程方法調用)是一套運行運行在不同作業系統、不同環境的程式實現，基於Internet程序呼叫規範，這種遠端程序呼叫使用HTTP作為傳輸協議，XML作為傳輸資訊的編碼格式，可以實現跨平台和跨語言。

下面來看XML-RPC的遠程通訊過程。

1.1    用戶端發起請求，按照XML-PRC協議對請求資訊進行填充；

1.2    填充後，將xml轉化為流，通過HTTP協議進行傳輸；

1.3    服務端接收到流後將流轉化為xml，按照XML-RPC協議擷取請求資訊，並調用處理類進行處理；

1.4    服務端處理完畢後，將結果按照XML-RPC協議寫入XML並返回。

思考問題：

1.1    資料轉送的標準格式

標準XML格式。

1.2    基本的資料轉送協議

HTTP

1.3    資料與流之間的轉化方式

將xml轉化為流。

1.4    接受和處理流的方式

通過監聽連接埠擷取xml流後轉化為xml，並根據協議擷取處理等資訊，調用處理類處理並將結果寫入xml中，採用同樣方式返回。

缺點：

1.1    XML-RPC可以發送的資料類型較少，而訊息的大小卻很龐大。

1.2    XML-RPC缺乏重要的安全機制和健壯的物件模型。

3.     Binary-RPC

二進位傳輸協議。看名字就知道和XML-RPC差不多，不同之處僅在傳輸的標準格式由XML轉為了二進位的格式。

思考問題：

1.1    資料轉送的標準格式

標準格式的二進位檔案。

1.2    基本的資料轉送協議

HTTP。

1.3    資料與流之間的轉化方式

將二進位格式檔案轉化為流傳輸。

1.4    接受和處理流的方式

伺服器通過監聽連接埠擷取請求流，轉化為二進位格式檔案，並根據協議擷取處理等資訊，調用處理類處理並將結果寫入xml返回。

缺點：

1.1    缺乏安全機制，傳輸沒有加密處理。

1.2    Hessian異常資訊定位麻煩。之前接觸時間類型(Timestamp，為資料庫完整保持時間資訊)傳輸時，用戶端有時拋異常，根據Hessian提示異常資訊，很難定位。後來尋找好長時間，才知道：Hessian jar中JavaSesrializier類中，對時間轉化時，沒有做空判斷，導致null 指標異常，經封裝後，原異常資訊丟失。

Try{

Java.util.Date date =(java.util.Date)in.readObject();

Value = newjava.util.Timestamp(date.getTime));

}

Catch(Exception e){….}

4.     SOAP

Soap(simple object access protocol 簡易物件存取通訊協定 (SOAP))是一個用於分布式環境的、輕量級的，基於XML進行資訊交換的通訊協定。一條SOAP訊息就是一個包含有一個必須的SOAP封裝包，一個可選的SOAP訊息頭和一個必需的SOAP訊息體的XML文檔。SOAP底層採用HTTP，可以跨平台和跨語言通訊。

5.     CORBA

CORBA（Common Object Request Broker Architecture 公用對象請求代理提醒結構）是一組用來定義“分布式對象系統”的標準。CORBA定義一套協議，符合該協議的對象可以互相互動，具有語言獨立性。

CORBA模型:

Object Services（物件服務）：物件服務被分布式對象使用。服務端發布一個可用的服務，需要提供用戶端可訪問的應用域。CORBA提供2中方式的域對象：The Naming Service和The Trading Service。The Naming Service是用戶端通過網域名稱來訪問服務。The Trading Services是用戶端根據自身的屬性來訪問服務。

Common Facilities（公用組件）：公用群組件能被多個應用共用的一系列服務。

Domain Interfaces（領域介面）：領域介面類似物件服務和公用組件，主要為特定的應用域而設計。

Application Interfaces（應用程式介面）：

CORBA ORB體繫結構圖：

缺點：

1.1    Corba不能穿透防火牆。Corba監聽連接埠動態變化，如果要穿透防火牆，配置比較複雜。

1.2    CORBA過於複雜。

6.     JMS

JMS(Java Message Service)的訊息模式

1.1    點對點模式（Point to Point Messaging）

該模型一條資訊僅傳遞給一個接收方。PTP訊息傳遞應用程式使用命名隊列發訊息。隊列發送方向特定的隊列發送訊息。隊列接收方從特定的隊列擷取訊息。一個隊列可以有多個發送方和接收方，但一條訊息僅傳遞給一個隊列接收方。如果多個隊列接受方監聽隊列上的訊息，不同實現採用不同演算法確認哪個接收方擷取訊息，如weblogic JMS採用“先來者優先”演算法。如果沒有隊列接收方監聽隊列，則訊息一直保留在訊息佇列中，直到隊列接收方擷取隊列為止。

隊列(Queue)：訊息提供方命名的訊息佇列，訊息接收方使用該命名擷取訊息。

隊列連結工廠(QueueConnectionFactory)：接收方使用該隊列連結工廠建立連結隊列（ConnectionQueue），連結隊列來擷取與JSM點對點訊息發送方的連結。

連結隊列(ConnectionQueue)：活動的連結隊列存在訊息提供方和訊息接收方之間，接收方使用它建立一個或多個JMS訊息佇列回話(QueueSession)。

隊列回話(QueueSession)：用來建立訊息佇列的發送方(QueueSender)和接收方(QueueReceiver)。

訊息發送方(QueueSender或MessageProducer)：發送訊息到已聲明隊列。

訊息接收方(QueueReceiver或MessageConsumer)：接受已經被發送到指定隊列的訊息。

 

1.2    發布訂閱模式(publish – subscribe mode)

該模型支援一條訊息傳遞給多個訂閱者。該模型運行多個主題訂閱者接受同一條訊息。JMS一直保留訊息，直到所有主題訂閱者都接收訊息為止。

主題(Topic)：一個訊息發送方命名的主題對象，訂閱者根據這個主題命名擷取主題對象。

主題連結工廠(TopicConnectionFactory)：訂閱者根據主題連結工廠建立連結主題(ConnectionTopic)來擷取與JMS訊息pub/sub發行者的連結。

連結主題(ConnectionTopic)：一個活動的連結主題存在於發行者和訂閱者之間。

主題會話(TopicSession)：用於建立主題訊息的發行者(TopicPublisher)和訂閱者(TopicSubscriber)。

訊息發行者(MessageProducer)：發送訊息到已聲明的主題。

訊息訂閱者(MessageCustomer)：接受已經被發送到已指定主題的訊息。

缺點:

會遇到安全、交易處理、延展性問題。對於一個簡單JMS客戶機，您只能選擇將安全性和交易處理外包給某個供應商，也就是說，這些問題將是以一種特定於供應商的方式來處理的。如果您的簡單JMS客戶機既要處理傳進來的訊息，又要發送訊息，那麼就會碰到延展性問題。JMS沒有能夠一次處理多於一個傳進來的請求的內建機制。為了支援並發請求，您需要擴充JMS客戶機，使其產生多個線程，或者啟動多個JVM執行個體，讓這些線程或執行個體各自運行應用。此外，還需要將JMS提供者配置為在一些適當的目的地上可以有多個訂閱者。這時，您就會質疑簡單JMS客戶機解決方案是否真的具有簡單性。

 

四、     分布式服務架構：1.     RMI

以上已做介紹，具體代碼實現請參見《分布式服務架構之RMI》。

2.     CORBA

以上已做介紹，具體代碼實現請參見《分布式服務架構之CORBA》。

3.     Hessian

Hessian將網路傳輸對象轉化為二進位流通過HTTP協議進行傳遞，採用Binary-PRC協議。可以穿透防火牆。Hessian是輕量級的Remoting on HTTP工具，使用比較簡單，與Spring相結合，更加完美。

缺點：

由於Hessian使用自己的序列化機制實現資料的編組(Marshaller)和反編組(UnMarshaller)，所以支援的資料類型有限制，不支援複雜類型。

Hessian的代碼實現請參見《分布式服務架構之Hessian》。

4.     HTTPInvoker

HTTPInvoker是Spring提供的遠程通訊協定。使用Java序列化機制處理對象的傳輸。

缺點：

1.1    只能用於Java程式間通訊。

1.2    服務端和用戶端必須使用SpringFramework。

Spring HTTPInvoker的代碼實現參見《分布式服務架構之HttpInvoker》。

5.     AXIS

Apache AXIS是一個開源的、基於SOAP的WebService服務架構。

具體代碼實現請參見《分布式服務架構之Axis》。

6.     Active MQ

Apache ActiveMQ就是基於JMS的實現。

具體代碼實現將參見《分布式服務架構之ActiveMQ》。

五、     結尾：

1.        在分布式服務架構的服務端經常需要對用戶端發送請求參數進行合法性校正，是否可以抽象介面校正通用方法。比如通過java泛型對參數進行必填項校正、數字型校正、時間類型校正、依賴性校正、合法值集合校正等。

2. 常見的分布式服務架構代碼實現介紹正在總結之中，請稍等。