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

　　服務層的概述

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

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

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

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

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

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

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

　　下面我們就來就從一個例子來看看SOA。

　　SOA架構(gòu)講述

　　我們首先來看一個例子：

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

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

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

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

　　3． 審計跟蹤比較的麻煩。因為很多的子系統(tǒng)各自可以操作數(shù)據(jù)庫，所以記錄操作系統(tǒng)比較麻煩。

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

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

　　1． 系統(tǒng)的業(yè)務邏輯等的維護變得容易，因為改變只是發(fā)生在一個地方。

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

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

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

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

　　SOA的基本原則

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

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

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

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

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