本篇主要是為后文做鋪墊，所以理論的東西相對(duì)而言比較的多一點(diǎn)！

　　服務(wù)層的概述

　　首先解釋一下什么是”服務(wù)Service”，從廣義來(lái)講：只要是你使用了別人的東西，那么你就在使用別人提供的服務(wù)。在這里，服務(wù)就是指可能被一個(gè)或者多個(gè)系統(tǒng)使用的核心的業(yè)務(wù)邏輯，我們可以把服務(wù)簡(jiǎn)單的想象成為一些可供調(diào)用的API。

　　在之前的第四章中，我們講述了如何組織業(yè)務(wù)邏輯，第五章講述了在業(yè)務(wù)層的設(shè)計(jì)中可以采用的一些模式。但是還有一個(gè)問題需要大家考慮的是：如何把業(yè)務(wù)層提供給其他的層來(lái)調(diào)用？

　　可能認(rèn)為這個(gè)問題有莫名奇妙—不是只要引用業(yè)務(wù)層的組件就行了嗎。但是仔細(xì)想想，卻不盡然：因?yàn)樵诤芏嘞到y(tǒng)中，我們不是直接把業(yè)務(wù)層的組件引用就可以了的，特別是在分布式的系統(tǒng)中，我們往往在服務(wù)端暴露一些服務(wù)接口，讓其他的子系統(tǒng)或者外部系統(tǒng)來(lái)調(diào)用提供的服務(wù)。

　　一般來(lái)說，服務(wù)層處于業(yè)務(wù)層和顯示層之間(當(dāng)然服務(wù)層也可以處于系統(tǒng)和系統(tǒng)之間)。服務(wù)層往往提供了一些供外部調(diào)用的服務(wù)接口，這些接口往往是一些粗粒度，或者說提供了一些簡(jiǎn)單易用，功能強(qiáng)大的接口，當(dāng)客戶端調(diào)用這些接口服務(wù)之后，服務(wù)層那邊就開始處理比較復(fù)雜的一些業(yè)務(wù)邏輯，驗(yàn)證規(guī)則，以及持久化數(shù)據(jù)等。

　　服務(wù)層內(nèi)的邏輯的組織形式有點(diǎn)類似我們之前在第四章中講述的Transaction Script模式。

　　我們可以簡(jiǎn)單的把服務(wù)層看成是一個(gè)中介：從客戶端接收請(qǐng)求，通過一系列的步驟之后，請(qǐng)求就到了服務(wù)層，服務(wù)層就開始協(xié)調(diào)和組織所需要的業(yè)務(wù)類，把請(qǐng)求的的具體處理交給那些業(yè)務(wù)類來(lái)做，最后把結(jié)果返回給客戶端。

　　在服務(wù)層的邏輯組織往往是比較過程化的，但是和Transaction Script有一點(diǎn)不同的是：Transaction Script的每一個(gè)方法處理一個(gè)比較細(xì)（比較具體的，小的）的業(yè)務(wù)流程和邏輯。但是服務(wù)層的一個(gè)接口的方法往往是處理一個(gè)比較大的流程（這個(gè)大的流程可能包含很多的小的流程）。

　　下面我們就來(lái)就從一個(gè)例子來(lái)看看SOA。

　　SOA架構(gòu)講述

　　我們首先來(lái)看一個(gè)例子：

　　上面的圖就是一個(gè)電子網(wǎng)站的系統(tǒng)架構(gòu)圖。可以看出，在這個(gè)系統(tǒng)中，又包含很多其他的小的子系統(tǒng)，而且每一個(gè)子系統(tǒng)都有自己的業(yè)務(wù)邏輯。同時(shí)每一個(gè)系統(tǒng)都連接搭配同一個(gè)數(shù)據(jù)庫(kù)，所有的子系統(tǒng)也都同時(shí)使用一個(gè)SMTP服務(wù)器。而且還有一些系統(tǒng)，如Order Management還需要鏈接第三方的WebService(PayPal).

　　這種錯(cuò)綜復(fù)雜的系統(tǒng)架構(gòu)存在一些問題：

　　1． 因?yàn)檎麄€(gè)大的系統(tǒng)中存在很多的子系統(tǒng)，而且這些子系統(tǒng)都有自己的業(yè)務(wù)邏輯層，這樣就導(dǎo)致了相同的業(yè)務(wù)邏輯在很多的其他子系統(tǒng)中重復(fù)，維護(hù)起來(lái)很困難。而且相同的業(yè)務(wù)流程在一些子系統(tǒng)中重復(fù)出現(xiàn)。例如，在Customer Management中，需要查看一個(gè)客戶的所有的訂單，那么這個(gè)邏輯和Order Management中的一些邏輯重復(fù)。

　　2． 各個(gè)系統(tǒng)和底層的數(shù)據(jù)結(jié)構(gòu)緊耦合。因?yàn)檫@些系統(tǒng)都是用的是同一個(gè)數(shù)據(jù)庫(kù)，有著各自的業(yè)務(wù)邏輯和數(shù)據(jù)訪問層，那么一旦要對(duì)數(shù)據(jù)庫(kù)做一點(diǎn)點(diǎn)的改動(dòng)，那么就會(huì)牽連很多的子系統(tǒng)做相應(yīng)的改變。

　　3． 審計(jì)跟蹤比較的麻煩。因?yàn)楹芏嗟淖酉到y(tǒng)各自可以操作數(shù)據(jù)庫(kù)，所以記錄操作系統(tǒng)比較麻煩。

　　通過SOA可以解決上面提到的一些問題(當(dāng)然，不僅僅只是上面提到的一些問題)：把所有的業(yè)務(wù)處理放在一起，進(jìn)行統(tǒng)一管理和控制（而不是像上面的設(shè)計(jì)那樣—零散的到處分布），并把業(yè)務(wù)邏輯的通過服務(wù)的形式暴露會(huì)給外界，讓其他的子系統(tǒng)調(diào)用。

　　上面改良后的系統(tǒng)的好處如下：

　　1． 系統(tǒng)的業(yè)務(wù)邏輯等的維護(hù)變得容易，因?yàn)楦淖冎皇前l(fā)生在一個(gè)地方。

　　2． 并且服務(wù)都是通過接口的形式暴露給外界的，那么這就為以后的擴(kuò)展提供了可能。例如我們可以在接口不變的前提下，替換現(xiàn)有的一些業(yè)務(wù)流程處理方式。

　　3． 日志，審計(jì)跟蹤容易實(shí)現(xiàn)。

　　4． 對(duì)外界隱藏了數(shù)據(jù)層的實(shí)現(xiàn)。只要接口之前定義的數(shù)據(jù)的scheme，或者說數(shù)據(jù)契約不變，服務(wù)層可以任意替換數(shù)據(jù)存儲(chǔ)設(shè)備和方式。

　　5． 各個(gè)系統(tǒng)與服務(wù)層的交互是基于粗粒度的接口，避免了系統(tǒng)直接和數(shù)據(jù)庫(kù)頻繁的交互，減小了通信的成本，也減輕了數(shù)據(jù)庫(kù)的壓力。

　　SOA的基本原則

　　SOA架構(gòu)中，繼承了來(lái)自對(duì)象和組件設(shè)計(jì)的各種原則，如封裝、自我包含等。那些保證服務(wù)的靈活性、松散耦合和重用能力的設(shè)計(jì)原則，對(duì)SOA架構(gòu)來(lái)說同樣是非常重要的。

    結(jié)構(gòu)上，服務(wù)總線是SOA的架構(gòu)模式之一。關(guān)于服務(wù)，一些常見和討論的設(shè)計(jì)原則如下。 

　　1) 無(wú)狀態(tài)。以避免服務(wù)請(qǐng)求者依賴于服務(wù)提供者的狀態(tài)。

NET技術(shù)：走向ASP.NET架構(gòu)設(shè)計(jì)——第六章：服務(wù)層設(shè)計(jì)（前篇），轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。