幾種常見的架構模式

6.2.2 幾種常見架構模式

 

《不是三維——軟件項目的設計、開發與管理》從軟件與三維實物的本質性不一樣出發研究軟件生產方法論。第6章會從設計與開發的各個層面，抽象、總結並介紹目前實踐中實用的技術方法。本節說的是幾種常見架構模式。

AD：2013大數據全球技術峯會課程PPT下載

6.2.2  幾種常見架構模式

前文講過，在實踐中，人們總結出了一些經常使用的軟件系統結構高層模式，以供應用系統設計時參考。這些模式包括：單服務兩層/多層C/S；MVC結構；面向服務的SOA與多服務集合；數據交換總線等。

1. 單機應用系統（Standalone）

準確地講，單機應用系統是最簡單的軟件結構，是指運行在一臺物理機器上的獨立應用程序。固然，該應用能夠是多進程或多線程的。

在信息系統普及以前的時代，大多數軟件系統其實都是單機應用系統。這並不意味着它們簡單，實際狀況是，這樣的系統有時更加複雜。這是由於軟件技術最初普及時，多數行業只是將軟件技術當作輔助手段來解決本身專業領域的問題，其中大多都是較深刻的數學問題或圖形圖像處理算法的實現。

有些系統很是龐大：筆者早年曾經參與的一個大型純軟件系統開發，多達160萬行程序！要知道，這些程序當時可都是一行行寫出來的。這應該算是一個超大型的軟件系統了，共有十多個子系統集成在一個圖形界面上執行，並可在多行UNIX/DOS平臺下運行，其中不少算法的複雜困難程度，能夠說，若是講給今天這些所謂的架構高手與計算機高手聽，他們會感受如聽「天書」通常深奧；有些系統則算法很是複雜：個人一個同窗，在他們專業領域內編制的軟件程序，在當時最高級的專業工做站上（應該要比今天的最快的微機性能還好些），一敲回車鍵運行，就每每要等待一個星期的時間才能獲得結果。

而這些軟件系統，從今天的軟件架構上來說，卻很簡單，是標準的單機系統。即使是今天，複雜的單機系統也有不少，它們大多都是專業領域的產品，如CAD/CAM領域的CATIA、ProEngineer，Autodesk的AutoCAD，還有咱們熟悉的Photoshop、CoralDraw，等等（這些系統的高級版本可能提供了一些網絡化的功能，但改變不了其單機系統的實質）。

因此這裏筆者要說的是，軟件架構複雜並不表明軟件系統複雜，其實，軟件架構設計較爲重要的領域只有一個，那就是信息系統領域，即以數據處理（數據存儲，傳輸，安全，查詢，展現等）爲核心的軟件系統。其餘行業的軟件應用對該概念其實並非那麼強調。

因此，讀者應該明白，後面幾節介紹的所謂流行軟件架構，都是指在信息系統的領域內。

2. 客戶機/服務器（Client/Server）結構

客戶機/服務器結構是軟件系統中最多見的一種。筆者認爲該概念應該來源於基於TCP/IP協議的進程間通訊IPC編程的「發送」與「反射」程序結構，即Client方向Server方發送一個TCP或UDP包，而後Server方根據接收到的請求向Client方回送TCP或UDP數據包（這裏是指創建TCP/IP鏈接之後的應用程序邏輯，不涉及如TCP創建鏈接的三方握手過程），IPC編程的客戶端/服務器概念圖如圖6-2所示。

誠然，上述IPC編程中的客戶與服務，在過去只是一個再普通、傳統不過的標準程序結構與編程方法，不會有人將其提升到軟件架構的高度。但其實，現代流行的各類C/S架構，其本質卻正是如此：即TCP/IP IPC編程中的客戶機/服務器。目前爲止，尚未任何一種客戶機/服務器架構的軟件超出了這個範圍。

因此，準確地講，現代各類客戶機/服務器模式的軟件架構其實是對IPC編程中客戶/服務程序結構更加產品化與成熟化的結果。

讓咱們來看看幾種常見的客戶機/服務器的軟件結構。

● 兩層C/S

兩層C/S，其實徹底是IPC客戶端/服務器結構的應用系統體現。兩層C/S其實就是人們所說的「胖客戶端」模式。

在實際的系統設計中，該類結構主要是指前臺客戶端+後臺數據庫管理系統，如圖6-3所示。

在兩層C/S結構中，圖6-3前臺界面+後臺數據庫服務的模式最爲典型，前文所說的不少數據庫前端開發工具（如PowerBuilder、Delphi、VB）等都是用來專門製做這種結構的軟件系統的。

有人也許要問，上述典型的兩層C/S模式應該沒有你所說的TCP/IP通訊呀？怎麼你前面講全部的C/S模式都脫離不了這個範圍呢？其實，每一種數據庫都提供了其專用的訪問API或通用的ODBC/JDBC接口，若是這個數據庫的開發支持從不一樣的機器上以網絡方式鏈接，則筆者相信其在客戶端與數據庫後臺的通訊大多狀況下是TCP/IP的客戶機/服務器模式！若是這個數據庫不支持網絡鏈接方式（如之前基於FoxBase的開發，或如今基於MS Access的開發），則咱們不能稱這個軟件是C/S模式。

另外，如圖6-3所示，兩層C/S其實是將前臺界面與相關的業務邏輯處理服務的內容集成在一個可運行單元中了。

● 三層C/S結構與B/S

三層C/S結構如圖6-4(a)所示，其前臺界面送日後臺的請求中，除了數據庫存取操做之外，還有不少其餘業務邏輯須要處理。三層C/S的前臺界面與後臺服務之間必須經過一種協議（自開發或採用標準協議）來通訊（包括請求、回覆、遠程函數調用等），一般包括如下幾種：

（1）基於TCP/IP協議，直接在底層socket api基礎上自行開發。這樣作通常只適合需求與功能簡單的小型系統；

（2）首先創建自定義的消息機制（封裝TCP/IP與socket編程），而後前臺與後臺之間的通訊經過該消息機制來開發。消息機制能夠基於XML，也能夠基於字節流（Stream）定義。雖然是自開發，但能夠基於此構建大型分佈式系統；

（3）基於RPC編程；

（4）基於CORBA/IIOP協議；

（5）基於Java RMI；

（6）基於J2EE JMS；

（7）基於HTTP協議。如瀏覽器與Web服務器之間的交流即是如此。須要指出的是，HTTP不是面向對象的，因此面向對象的應用數據會被首先平面化後進行傳輸。

目前最典型的基於三層C/S結構的應用模式即是咱們最熟悉、較流行的B/S（Brower/Server，瀏覽器/服務器）模式，如圖6-4（b）所示。

圖6-4（b）的B/S結構中，Web瀏覽器是一個用於文檔檢索和顯示的客戶應用程序，並經過超文本傳輸協議HTTP（HyperText Transfer Protocol）與Web服務器相連。該模式下，通用的、低成本的瀏覽器節省了兩層結構的C/S模式客戶端軟件的開發和維護費用。這些瀏覽器你們都很熟悉，包括MS Internet Explorer、Mozilla FireFox、NetScape等。

Web服務器是指駐留於因特網上某種類型計算機的程序。當Web瀏覽器（客戶端）連到服務器上並請求文件或數據時，服務器將處理該請求並將文件或數據發送到該瀏覽器上，附帶的信息會告訴瀏覽器如何查看該文件（即文件類型）。服務器使用HTTP（超文本傳輸協議）進行信息交流，這就是人們常把它們稱爲HTTPD服務器的緣由。

咱們天天都在Web瀏覽器上進行各類操做，這些操做中絕大多數其實都是在Web服務器上執行的，Web瀏覽器只是將咱們的請求以HTTP協議格式發送到Web服務器端或將返回的查詢結果顯示而已。固然，駐留Web瀏覽器與服務器的硬件設備能夠是位於Web網絡上的兩臺相距千里的計算機。

應該清楚，B/S模式的瀏覽器與Web服務器之間的通訊仍然是TCP/IP，只是將協議格式在應用層標準化了而已。實際上B/S是採用了通用客戶端界面的三層C/S結構。

● 多層C/S

多層C/S結構通常是指三層以上的結構，在實踐中主要是三層與四層，四層即前臺界面（如瀏覽器）、Web服務器、中間件（或應用服務器）及數據庫服務器，典型的客戶機/服務器軟件結構如圖6-5所示。

多層客戶機／服務器模式主要用於較有規模的企業信息系統建設，其中中間件一層主要完成如下幾個方面的工做：

（1）提升系統可伸縮性，增長併發性能。在大量併發訪問發生的狀況下，Web服務器可處理的併發請求數能夠在中間件一層獲得更進一步的擴展，從而提升系統總體併發鏈接數；

（2）中間件/應用層一層專門完成請求轉發或一些與應用邏輯相關的處理，具備這一做用的中間件通常能夠做爲請求代理，也可做爲應用服務器。中間件的這種做用在J2EE的多層結構中比較經常使用，如BEA WebLogic、IBM WebSphere等提供的EJB容器，就是專門用以處理複雜企業邏輯的中間件技術組成部分。

（3）增長數據安全性。在網絡結構設計中，Web服務器通常都處於非軍事區，即直接能夠被前端用戶訪問到，若是是一些在公網上提供服務的應用，則Web服務器通常均可以被全部能訪問與聯網的用戶直接訪問。所以，若是在軟件結構設計上從Web服務器就能夠直接訪問企業數據庫是不安全的。所以，中間件的存在，能夠隔離Web服務器對企業數據庫的訪問請求：Web服務器將請求先發給中間件，而後由中間件完成數據庫訪問處理後返回。

● MVC

MVC的概念在目前信息系統設計很是流行，嚴格來說，MVC（Model-View-Controller）其實是上述多層C/S結構的一種經常使用的標準化模式，或者能夠說是從另外一個角度去抽象這種多層C/S結構。

在J2EE架構中，View表示層指瀏覽器層，用於圖形化展現請求結果；Controller控制器指Web服務器層，Model模型層指應用邏輯實現及數據持久化的部分。目前流行的J2EE開發框架，如JSF、Struts、Spring、Hibernate等及它們之間的組合，如Struts+Spring+Hibernate（SSH）、JSP+Spring+Hibernate等都是面向MVC架構的；另外，PHP、Perl、MFC等語言都有MVC的實現模式。

在之前傳統JSP程序中網頁與數據訪問是混合在一塊兒的，在MVC中強制要求表示層（視圖）與數據層（模型）代碼分開，而控制器（如Servlet）則能夠用來鏈接不一樣的模型和視圖去完成用戶的需求。

從分層體系的角度來說，MVC的層次結構如圖6-6所示，控制器與視圖一般處於Web服務器一層，而根據「模型「有沒有將業務邏輯處理分離成單獨服務處理，MVC能夠分爲三層或四層體系。

● 對分層標準的探討

以上所講各類C/S結構，包括兩層、三層、四層甚至多層的概念，在IT界目前很是流行，絕大多數的信息處理系統與門戶網站，都會將本身應用的結構宣傳爲多少多少層C/S架構。但究竟應該是屬於多少層，兩層仍是三層？目前的實際情況是比較混亂的。

例如上面所說B/S結構，有人說是三層，也有很多人說是兩層，各有道理；又好比MVC，有人說是四層，又有人說是三層，同時在不少宣傳中它確實被歸結到J2EE宣傳的四層架構中；另外，還有許多應用系統在某一層採用主從模式的集羣服務器結構，有時也會使分層的概念混淆。

本書在這裏給出一個分層問題的判斷標準，即應該將應用系統的分層與服務分級區別開來。即某個應用架構到底分多少層，應該由其縱向深度上有多少個不一樣種類的（服務器集羣顯然排除在外）、兩兩相互通訊的獨立運行單元組成來決定；而服務分級應該由其縱向深度上以其由多少個不一樣類型的服務實例以兩兩雙向通訊的模式組成？也就是說，一共由多少對簡單客戶機/服務器組成。

因而，B/S應該是三層架構，可是由兩級不一樣類型的服務組成：Web服務與數據庫服務；而四層架構則一般應該是由三級服務組成的。還有，在有些J2EE框架（如JSF+Spring+Hibernate），除了Web服務器與瀏覽器的通訊之外，再沒有其餘的分佈式應用了（沒有用到EJB，RMI或JMS），而有些人將HibernateDAO等的數據持久化層單獨算作一層，稱之爲四層，這也是不穩當的，由於數據持久化層與數據層畢竟不是一組客戶機/服務器的關係，所以，統一算作數據層，因此應該仍是歸爲三層架構；

前面所說「服務」的概念，不管在Windows平臺仍是UNIX平臺，都應該是很清楚的：服務是主機提供的功能，它以被動等待信號或按期啓動的方式來實現。在UNIX-LIKE的系統中，服務通常是由Daemon來實現的。

而這裏須要指出的是，上面所說的「服務」與6.2.2.3節要講的「多服務結構SOA」中提出的「服務」涵義是不一樣的：多層結構的軟件系統，不管其自己由多少層級的服務組成，對外都是一個完整的單點應用系統，對應SOA中的一個「服務」。

3. 多服務結構（SOA）

以上所講，不管多少層的C/S軟件結構，對外來說，都只是一個單結點應用（不管它由多個不一樣層的「服務」相互配合來完成其功能），具體表現爲一個門戶網站、一個應用系統等。下面咱們講多個單點應用相互通訊的多服務結構。

● 多服務結構

若是兩個多層C/S結構的應用系統之間須要相互進行通訊，那麼，就產生了多服務結構，稱爲Service Oriented Architecture。如圖6-7所示：

在SOA的概念中，將由多層服務組成的一個結點應用看做是一個單一的服務。在SOA的定義裏，對「服務」的概念進行的廣義化，即它不是指計算機層面的一個Daemon，而是指向外提供一組總體功能的獨立應用系統。所謂獨立應用系統是指：不管該應用系統由多少層服務組成，去掉任何一層，它都將不能正常工做，對外能夠是一個提供完整功能的獨立應用。這個特徵即可以將多服務體系與多層單服務體系徹底區分開來。

兩個應用之間通常經過消息來進行通訊，能夠互相調用對方的內部服務、模塊或數據交換、驅動交易，等等。在實踐中，一般藉助中間件來實現SOA的需求，如消息中間件、交易中間件，等等。

多服務結構能夠在實踐中又能夠具體分爲異構系統集成、同構系統聚合、聯邦體系結構等，在下面咱們對此會做一介紹。

● Web Service

多服務結構體如今Web應用之間，就成爲了Web Service，即兩個互聯網應用（如門戶網站）之間能夠相互向對方開放一些內部「服務」（能夠理解爲功能模塊、函數、過程等）。現階段，一個Web應用對外開放其內部服務的協議主要是SOAP與WSDL，其資料不少，本書不對其作詳細介紹。

Web Service是多服務體系結構的一個最典型、最流行的應用模式，但除了其由Web應用爲主而組成的特色之外，Web Service最主要的應用是一個Web應用向外提供內部服務，而不像傳統意義上SOA那樣有更加豐富的應用類型。

● 多服務結構的實質

多服務結構的實質是消息機制或遠程過程調用（RPC）。雖然其具體的實現底層並不必定是採用了咱們所熟悉的RPC編程技術，但兩個應用之間的相互配合確實是經過某種預約義的協議來調用對方的「過程」實現的，這與咱們6.2.2.2節所講多層架構的單點應用系統中，兩個處於不一樣層的運行實例相互之間通訊的協議類型基本是相同的。

4. 企業數據交換總線

實踐中，還有一種較經常使用的架構，即企業數據交換總線，即不一樣的企業應用之間進行信息交換的公共通道，如圖6-8所示：

這種架構在大型企業不一樣應用系統進行信息交換時使用較廣泛，在國內，主要發生在銀行或電信等信息化程度較高的行業。其餘的許多行業雖然也有相似的需求，但大多都是手工或半自動化來實現該項需求的，並無達到「企業數據交換總線」的層次。

關於數據總線自己，其實質應該是一個可稱之爲鏈接器的軟件系統（Connector），它能夠基於中間件（如消息中間件或交易中間件）構建，也能夠基於CORBA/IIOP協議開發，主要功能是按照預約義的配置或消息頭定義，進行數據（data）、請求(request)或回覆(response)的接收與分發。

從理論上來說，企業數據交換總線能夠同時具備實時交易與大數據量傳輸的功能，但在實踐中，成熟的企業數據交換總線主要是爲實時交易而設計的，而對可靠的大數據量傳輸需求每每要單獨設計。若是採用CORBA爲通訊協議，交換總線就是對象請求代理（ORB），也有一些資料中將這種架構稱爲「代理體系」。另外，在交換總線上掛接的軟件系統，有些也能夠實現代理的功能，各代理之間能夠並行或串行的方式進行工做，經過掛接在同一交換總線上的控制器來協調各代理之間的活動。

 

原文地址：http://book.51cto.com/art/201004/195732.htm