基于.NET的快速開發(fā)框架的設(shè)計

趙英俠　吳永波

摘要：應(yīng)用框架強(qiáng)調(diào)的是軟件的可重用性和系統(tǒng)的可擴(kuò)充性，可以縮短大型應(yīng)用系統(tǒng)開發(fā)周期，提高開發(fā)質(zhì)量?？梢詾榭焖贅?gòu)建企業(yè)級的應(yīng)用提供強(qiáng)有力的支持。該文根據(jù)面向?qū)ο笤O(shè)計理念及分層架構(gòu)設(shè)計模式在.net平臺上設(shè)計開發(fā)了一個框架。并對此框架進(jìn)行了分析總結(jié)。

關(guān)鍵詞：軟件工程；框架；架構(gòu)

中圖分類號：TP301 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2014）13-2996-05

1 背景

軟件架構(gòu)設(shè)計是軟件開發(fā)中至關(guān)重要的一環(huán)，良好的軟件架構(gòu)是一個軟件開發(fā)項目成功的保證。系統(tǒng)的設(shè)計必須能在一系列變化之后仍然盡可能簡單。所以必須為變化而設(shè)計。從而設(shè)計的目標(biāo)應(yīng)該是：靈活性，可擴(kuò)充性，可移植性。隨著系統(tǒng)越來越龐大，特別是企業(yè)級的系統(tǒng)，要實現(xiàn)上述的目標(biāo)越來越困難。分層架構(gòu)的提出，在很大程度上解決了軟件開發(fā)中的強(qiáng)耦合問題，也為編寫代碼清晰、可維護(hù)性良好的系統(tǒng)提供了理論基礎(chǔ)。目前，典型的分層架構(gòu)是三層架構(gòu)，即自底向上依次是數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表示層，這種經(jīng)典架構(gòu)經(jīng)歷了時間和實踐的檢驗，被認(rèn)為是合理、有效的分層設(shè)計。實際的項目中，對上述三層會做出進(jìn)一步的擴(kuò)展，將原有的三層擴(kuò)展到七層，即數(shù)據(jù)訪問組件基礎(chǔ)層、SQL Server（ Oracle） 數(shù)據(jù)訪問層、數(shù)據(jù)訪問抽象工廠層、數(shù)據(jù)訪問接口定義層、業(yè)務(wù)實體層、業(yè)務(wù)邏輯層、表示層。在這些層級中真正變化的是表示層即客戶端UI和業(yè)務(wù)邏輯層，而數(shù)據(jù)庫訪問層和其它擴(kuò)充層在本質(zhì)上沒有很大的差別?？蚣苁钦麄€或部分系統(tǒng)的可重用設(shè)計，表現(xiàn)為一組抽象構(gòu)件及構(gòu)件實例間交互的方法。框架通過把一些通用的方法例如發(fā)送E-mail，壓縮文件，提供報表展示，導(dǎo)入導(dǎo)出Excel等做成一個基礎(chǔ)類庫，提高軟件的易用性。通過框架的設(shè)計可以建立更加開放的系統(tǒng)，增加代碼的重用性，提高了軟件的生產(chǎn)效率和質(zhì)量，使軟件設(shè)計人員更專注于對領(lǐng)域的了解，可以讓那些經(jīng)驗豐富的人員去設(shè)計框架和領(lǐng)域構(gòu)件，而不必限于底層編程。該文正是在此基礎(chǔ)提出的一個開發(fā)框架。

2 整體架構(gòu)

圖1 快速開發(fā)框架 通信圖

整個通信過程是請求從，如果有返回值的話，原路返回。通信技術(shù)采用的是.net 4.0 WCF，簡單高效，可以輕松適應(yīng)廣域網(wǎng)和局域網(wǎng)，一個服務(wù)可以同時暴露多個協(xié)議給不同的客戶端請求。

客戶端包括C版winform客戶端和B版瀏覽器，發(fā)送請求給中心服務(wù)器，中心服務(wù)器根據(jù)自身的路由表，把請求轉(zhuǎn)發(fā)到相應(yīng)的應(yīng)用服務(wù)器中，同時還做身份驗證，緩存管理，日志管理等。應(yīng)用服務(wù)器是具體業(yè)務(wù)組件的容器，它是一個windows服務(wù)，在啟動的時候，根據(jù)配置文件加載配置中的業(yè)務(wù)組件到內(nèi)存中，同時把自己的地址發(fā)送給中心服務(wù)器緩存。當(dāng)請求來的時候，在內(nèi)存中直接調(diào)用業(yè)務(wù)組件，加快了響應(yīng)速度。業(yè)務(wù)組件實現(xiàn)了具體的業(yè)務(wù)邏輯，經(jīng)過處理后返回給客戶端。緩存服務(wù)器也是一個業(yè)務(wù)組件，和一般的業(yè)務(wù)組件一樣配置，在服務(wù)啟動的時候加載，非常靈活，無需特殊處理。

通信層比一般的3層架構(gòu)多了一層中心服務(wù)器，這樣的好處在于截獲所有的客戶端調(diào)用，做一些AOP的處理，還可以做路由。如果某個應(yīng)用服務(wù)器壓力過大，部署另外一臺應(yīng)用服務(wù)器指向中心服務(wù)器，服務(wù)啟動后就會在中心服務(wù)器路由表中添加一條記錄，這樣當(dāng)新的請求到來，通過路由算法，就會路由到壓力較輕的應(yīng)用服務(wù)器，這樣應(yīng)用服務(wù)器可以橫向擴(kuò)展，充分利用硬件的性能。

每一層都有緩存服務(wù)器，加快了響應(yīng)速度，緩存服務(wù)器還可以持久化，這樣把一些狀態(tài)在重新啟動后保持原樣，對一些公共上下文可以保持在不同會話間，不同的進(jìn)程間同步，即使服務(wù)重啟后仍然是同步的。

圖2是層次圖，展示了框架的各種不同層次之間的關(guān)系。

圖2 框架層次圖

3 客戶端

客戶端提供了一個高內(nèi)聚低耦合的架構(gòu)，客戶界面的類只需要實現(xiàn)指定的接口，在數(shù)據(jù)庫中配置好菜單，就可以運(yùn)行?？蛻舳酥鹘缑媸且粋€樹形結(jié)構(gòu)，多級菜單形成樹。菜單是可以在動態(tài)修改的，非常靈活。另外，還可以接入舊的系統(tǒng)，只需要實現(xiàn)制定的適配器并在數(shù)據(jù)庫中配置。圖3是客戶端調(diào)用界面。

圖3 客戶端調(diào)用界面

4 中心服務(wù)器

中心服務(wù)器是一個特殊的角色，客戶端的請求都通過中心服務(wù)器來轉(zhuǎn)發(fā)，同時還處理請求的身份驗證，日志管理，緩存管理，權(quán)限管理，性能監(jiān)視的功能。圖4中心服務(wù)器內(nèi)部功能。

所有外部的請求來到中心服務(wù)器時，首先需要身份認(rèn)證。它需要一個令牌，這個令牌是客戶端合法用戶登陸后生成的，中心服務(wù)器維護(hù)了所有在線用戶的信息，外部請求如果沒有令牌，則拒絕服務(wù)。

合法用戶發(fā)生請求，還必須通過權(quán)限認(rèn)證。每個合法用戶都會賦予一定的權(quán)限，客戶在登錄時候，中心服務(wù)器就會過濾客戶的權(quán)限，只返回給賦予的權(quán)限合集給客戶端。當(dāng)請求到來時，還會第二次檢測客戶是否在授權(quán)范圍內(nèi)，如果不是，也拒絕服務(wù)。

分布式緩存可以配置為本地緩存或者是分布式緩存。具體緩存的內(nèi)容在配置文件中配置。過期策略又分為：

表1 分布式緩存過期策略

[序號＼&策略名稱＼&描述＼&1＼&方法觸發(fā)＼&調(diào)用某個方法的時候結(jié)果從緩存獲取，同時會清除依賴的緩存＼&2＼&絕對過期時間觸發(fā)＼&用某個方法的結(jié)果有一個絕對過期時間，到點就過期了，清除緩存＼&3＼&滑動過期時間觸發(fā)＼&用某個方法的結(jié)果有一個滑動時間，每調(diào)用一次過期時間就會順延，如果間隔時間超過了順延期，則清除緩存＼&4＼&文件變動觸發(fā)＼&調(diào)用某個方法的結(jié)果，依賴某個文件的內(nèi)容，如果文件變動，則清除緩存＼&5＼&SQL變動觸發(fā)＼&調(diào)用某個方法的結(jié)果依賴數(shù)據(jù)庫中的表，如果表記錄變動則清除緩存＼&]

緩存策略配置好后，中心服務(wù)器第一次使用緩存是就會初始化策略，每個請求到來時，會進(jìn)行如下流程處理（圖5所示）。

圖5 分布式緩存獲取流程圖

流程是根據(jù)緩存的配置文件確定當(dāng)前請求是否有配置緩存，如果是，則根據(jù)傳遞的參數(shù)獲取緩存的鍵值，根據(jù)鍵值獲取緩存，如果緩存為空，則去持久層獲取，再更新緩存，如果不為空，則直接返回，減少了與持久層的交互，提升了性能。

路由與負(fù)載均衡管理是客戶端的請求到來時，請求會自動轉(zhuǎn)發(fā)到負(fù)載較輕的應(yīng)用服務(wù)器上。由于在應(yīng)用服務(wù)器啟動的時候，會向中心服務(wù)器注冊，報告自己的地址和承載的服務(wù)，所以中心服務(wù)器會有一份詳細(xì)的關(guān)于所有應(yīng)用服務(wù)器的信息。當(dāng)請求到來時，會根據(jù)負(fù)載均衡算法，選擇一個負(fù)載較輕的應(yīng)用服務(wù)器。這樣的結(jié)構(gòu)使得應(yīng)用服務(wù)器可以水平擴(kuò)展，如果某個應(yīng)用服務(wù)器負(fù)擔(dān)很重，再部署一臺新的應(yīng)用服務(wù)器，承載相同的業(yè)務(wù)，向中心服務(wù)器注冊即可承載應(yīng)用，減輕另外一臺的壓力。負(fù)載均衡算法采用2種，最少連接數(shù)法和基于CPU，內(nèi)存，I/O訪問加權(quán)比較法。

會話管理是在中心服務(wù)器維護(hù)了所有登陸用戶的信息，包括用戶的令牌，用戶名稱，用戶的操作，用戶登陸時間等，同時開發(fā)了一個維護(hù)工具，可以清除在線用戶，刷新用戶登陸時間等。

日志和性能監(jiān)視是維護(hù)功能，主要記錄用戶的操作日志，以及異常信息，性能監(jiān)視器還記錄了每個請求的處理時間，可以用來分析性能障礙的原因，定位哪個操作引起性能差，為進(jìn)一步分析服務(wù)端提供了依據(jù)。

5 應(yīng)用服務(wù)器外殼

應(yīng)用服務(wù)器外殼是一個windows服務(wù)，用于承載業(yè)務(wù)組件，它是一個容器，把業(yè)務(wù)組件加載到容器中，同時接收中心服務(wù)器的請求，根據(jù)請求地址，調(diào)用具體業(yè)務(wù)組件，并把上下文和請求參數(shù)傳遞給組件。它的功能有：轉(zhuǎn)發(fā)請求，加載IOC容器，注冊服務(wù)器，保持心跳，動態(tài)編譯業(yè)務(wù)組件，異常處理。圖6為應(yīng)用服務(wù)器外殼功能圖：

圖6 應(yīng)用服務(wù)器外殼功能圖

轉(zhuǎn)發(fā)請求是應(yīng)用服務(wù)器的主要職責(zé)，應(yīng)該服務(wù)器外殼本身不處理請求，它把業(yè)務(wù)組件動態(tài)編譯后成為一個同一的接口，然后加載到內(nèi)存中，當(dāng)請求到來時，根據(jù)業(yè)務(wù)組件配置的服務(wù)名找到對應(yīng)的業(yè)務(wù)組件，傳遞上下文和參數(shù)到組件，并調(diào)用組件服務(wù)，最后把組件的處理的結(jié)果返回給中心服務(wù)器。

IOC容器管理負(fù)載加載業(yè)務(wù)組件的IOC配置，是利用Microsoft Enterprise Lib 5.0 的Unity來加載IOC，可以同時配置多個業(yè)務(wù)IOC容器，統(tǒng)一加載，業(yè)務(wù)組件再調(diào)用框架提供的IOC類庫即可訪問IOC內(nèi)部組件。

注冊服務(wù)器是向中心服務(wù)器注冊自己，包括自己的IP地址，協(xié)議信息，加載的業(yè)務(wù)組件服務(wù)，同時接收中心服務(wù)器返回的應(yīng)用服務(wù)器節(jié)點令牌作為自己的唯一標(biāo)識，此外還接受中心服務(wù)器返回的所有應(yīng)用服務(wù)器節(jié)點，節(jié)點的模塊信息和負(fù)載信息，所以應(yīng)用服務(wù)器外殼也維護(hù)了一份路由表，自己也可以路由到其他節(jié)點，無需中心服務(wù)器參與，這是多個應(yīng)用服務(wù)器之間調(diào)用的基礎(chǔ)。

心跳機(jī)制是應(yīng)用服務(wù)器每隔指定時間向中心服務(wù)器發(fā)送消息，告訴中心服務(wù)器自己的狀態(tài)，如果中心服務(wù)器長久沒有收到應(yīng)用服務(wù)器的報告，則認(rèn)為該應(yīng)用服務(wù)器沒有響應(yīng)，從路由表中移除它。

動態(tài)編譯是加載業(yè)務(wù)組件的核心功能。為了能夠快速響應(yīng)請求，業(yè)務(wù)組件沒有使用普通的反射原理，而是在服務(wù)啟動的時候把各個業(yè)務(wù)組件的服務(wù)經(jīng)過動態(tài)編譯為同一的接口并實例化到內(nèi)存中。當(dāng)請求來時根據(jù)請求地址找到對應(yīng)的業(yè)務(wù)組件后，無需再實例化了，直接可以調(diào)用服務(wù)，加快了響應(yīng)的速度。

異常處理是在動態(tài)編譯中統(tǒng)一處理的。業(yè)務(wù)組件都會被統(tǒng)一動態(tài)編譯為實現(xiàn)同一個接口的類，所以很容易的加入了異常處理，異常詳細(xì)信息記錄到日志，并返回給客戶端一個異常的ID和簡單的提示，不會包含具體的堆棧信息。

6 RESTful 架構(gòu)服務(wù)和代理

REST 即Representational State Transfer的縮寫，翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"，如果一個架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。它有以下特點：

1）每一個URI代表一種資源；

2）客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；

3）客戶端通過四個HTTP動詞，對服務(wù)器端資源進(jìn)行操作，實現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。

中心服務(wù)器就是RESful架構(gòu)服務(wù)，客戶端和服務(wù)端的交互在請求之間是無狀態(tài)的，從客戶端到服務(wù)器的每個請求都必須包含理解請求所必需的信息。如果服務(wù)器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態(tài)請求可以由任何可用服務(wù)器回答，客戶端可以緩存數(shù)據(jù)以改進(jìn)性能。這樣客戶端請求的接口只有4個，Get，Put，Delete，Post，加上資源和參數(shù)就可以請求所有的服務(wù)，非常簡單。C版客戶端的代理利用HttpClient類來調(diào)用Restful服務(wù)，B版利用XMLHttpRequest對象請求服務(wù)。

7 結(jié)論

本文詳細(xì)介紹了一個基于.Net的快速開發(fā)框架的設(shè)計，包括客戶端框架，客戶端代理，中心服務(wù)器，應(yīng)用服務(wù)器外殼。闡述了各個組件的功能及其原理。這個框架是基于.Net 4.0 開發(fā)的，業(yè)務(wù)組件完全是自己定制，開發(fā)組件時可以利用框架提供的公共類庫，完成后配置服務(wù)即可宿主到應(yīng)用服務(wù)器中?？蛻舳酥С諧版和B版，內(nèi)容定制，C版開發(fā)后配置菜單即可運(yùn)行起來。這個框架已經(jīng)經(jīng)過多個項目實踐，確實能夠加快項目的開發(fā)交付，使客戶能夠快速響應(yīng)市場的需求。圖7是一個系統(tǒng)布署圖。

圖7

參考文獻(xiàn)：

[1] Erich Gamma.可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，譯.北京：機(jī)械工業(yè)出版社，2007.

[2] 錢樂秋.軟件工程[M].北京：清華大學(xué)出版社， 2007.

[3] 李紅芹.基于三層架構(gòu)的.NET數(shù)據(jù)庫業(yè)務(wù)系統(tǒng)開發(fā)[J].計算機(jī)與現(xiàn)代化，2009（10）：120-125.

[4] 竇文琦，孫士學(xué).基于分層架構(gòu)的WEB系統(tǒng)框架分析[J].電腦技術(shù)與知識，2013（9）：24.

緩存策略配置好后，中心服務(wù)器第一次使用緩存是就會初始化策略，每個請求到來時，會進(jìn)行如下流程處理（圖5所示）。

圖5 分布式緩存獲取流程圖

流程是根據(jù)緩存的配置文件確定當(dāng)前請求是否有配置緩存，如果是，則根據(jù)傳遞的參數(shù)獲取緩存的鍵值，根據(jù)鍵值獲取緩存，如果緩存為空，則去持久層獲取，再更新緩存，如果不為空，則直接返回，減少了與持久層的交互，提升了性能。

路由與負(fù)載均衡管理是客戶端的請求到來時，請求會自動轉(zhuǎn)發(fā)到負(fù)載較輕的應(yīng)用服務(wù)器上。由于在應(yīng)用服務(wù)器啟動的時候，會向中心服務(wù)器注冊，報告自己的地址和承載的服務(wù)，所以中心服務(wù)器會有一份詳細(xì)的關(guān)于所有應(yīng)用服務(wù)器的信息。當(dāng)請求到來時，會根據(jù)負(fù)載均衡算法，選擇一個負(fù)載較輕的應(yīng)用服務(wù)器。這樣的結(jié)構(gòu)使得應(yīng)用服務(wù)器可以水平擴(kuò)展，如果某個應(yīng)用服務(wù)器負(fù)擔(dān)很重，再部署一臺新的應(yīng)用服務(wù)器，承載相同的業(yè)務(wù)，向中心服務(wù)器注冊即可承載應(yīng)用，減輕另外一臺的壓力。負(fù)載均衡算法采用2種，最少連接數(shù)法和基于CPU，內(nèi)存，I/O訪問加權(quán)比較法。

會話管理是在中心服務(wù)器維護(hù)了所有登陸用戶的信息，包括用戶的令牌，用戶名稱，用戶的操作，用戶登陸時間等，同時開發(fā)了一個維護(hù)工具，可以清除在線用戶，刷新用戶登陸時間等。

日志和性能監(jiān)視是維護(hù)功能，主要記錄用戶的操作日志，以及異常信息，性能監(jiān)視器還記錄了每個請求的處理時間，可以用來分析性能障礙的原因，定位哪個操作引起性能差，為進(jìn)一步分析服務(wù)端提供了依據(jù)。

5 應(yīng)用服務(wù)器外殼

應(yīng)用服務(wù)器外殼是一個windows服務(wù)，用于承載業(yè)務(wù)組件，它是一個容器，把業(yè)務(wù)組件加載到容器中，同時接收中心服務(wù)器的請求，根據(jù)請求地址，調(diào)用具體業(yè)務(wù)組件，并把上下文和請求參數(shù)傳遞給組件。它的功能有：轉(zhuǎn)發(fā)請求，加載IOC容器，注冊服務(wù)器，保持心跳，動態(tài)編譯業(yè)務(wù)組件，異常處理。圖6為應(yīng)用服務(wù)器外殼功能圖：

圖6 應(yīng)用服務(wù)器外殼功能圖

轉(zhuǎn)發(fā)請求是應(yīng)用服務(wù)器的主要職責(zé)，應(yīng)該服務(wù)器外殼本身不處理請求，它把業(yè)務(wù)組件動態(tài)編譯后成為一個同一的接口，然后加載到內(nèi)存中，當(dāng)請求到來時，根據(jù)業(yè)務(wù)組件配置的服務(wù)名找到對應(yīng)的業(yè)務(wù)組件，傳遞上下文和參數(shù)到組件，并調(diào)用組件服務(wù)，最后把組件的處理的結(jié)果返回給中心服務(wù)器。

IOC容器管理負(fù)載加載業(yè)務(wù)組件的IOC配置，是利用Microsoft Enterprise Lib 5.0 的Unity來加載IOC，可以同時配置多個業(yè)務(wù)IOC容器，統(tǒng)一加載，業(yè)務(wù)組件再調(diào)用框架提供的IOC類庫即可訪問IOC內(nèi)部組件。

注冊服務(wù)器是向中心服務(wù)器注冊自己，包括自己的IP地址，協(xié)議信息，加載的業(yè)務(wù)組件服務(wù)，同時接收中心服務(wù)器返回的應(yīng)用服務(wù)器節(jié)點令牌作為自己的唯一標(biāo)識，此外還接受中心服務(wù)器返回的所有應(yīng)用服務(wù)器節(jié)點，節(jié)點的模塊信息和負(fù)載信息，所以應(yīng)用服務(wù)器外殼也維護(hù)了一份路由表，自己也可以路由到其他節(jié)點，無需中心服務(wù)器參與，這是多個應(yīng)用服務(wù)器之間調(diào)用的基礎(chǔ)。

心跳機(jī)制是應(yīng)用服務(wù)器每隔指定時間向中心服務(wù)器發(fā)送消息，告訴中心服務(wù)器自己的狀態(tài)，如果中心服務(wù)器長久沒有收到應(yīng)用服務(wù)器的報告，則認(rèn)為該應(yīng)用服務(wù)器沒有響應(yīng)，從路由表中移除它。

動態(tài)編譯是加載業(yè)務(wù)組件的核心功能。為了能夠快速響應(yīng)請求，業(yè)務(wù)組件沒有使用普通的反射原理，而是在服務(wù)啟動的時候把各個業(yè)務(wù)組件的服務(wù)經(jīng)過動態(tài)編譯為同一的接口并實例化到內(nèi)存中。當(dāng)請求來時根據(jù)請求地址找到對應(yīng)的業(yè)務(wù)組件后，無需再實例化了，直接可以調(diào)用服務(wù)，加快了響應(yīng)的速度。

異常處理是在動態(tài)編譯中統(tǒng)一處理的。業(yè)務(wù)組件都會被統(tǒng)一動態(tài)編譯為實現(xiàn)同一個接口的類，所以很容易的加入了異常處理，異常詳細(xì)信息記錄到日志，并返回給客戶端一個異常的ID和簡單的提示，不會包含具體的堆棧信息。

6 RESTful 架構(gòu)服務(wù)和代理

REST 即Representational State Transfer的縮寫，翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"，如果一個架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。它有以下特點：

1）每一個URI代表一種資源；

2）客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；

3）客戶端通過四個HTTP動詞，對服務(wù)器端資源進(jìn)行操作，實現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。

中心服務(wù)器就是RESful架構(gòu)服務(wù)，客戶端和服務(wù)端的交互在請求之間是無狀態(tài)的，從客戶端到服務(wù)器的每個請求都必須包含理解請求所必需的信息。如果服務(wù)器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態(tài)請求可以由任何可用服務(wù)器回答，客戶端可以緩存數(shù)據(jù)以改進(jìn)性能。這樣客戶端請求的接口只有4個，Get，Put，Delete，Post，加上資源和參數(shù)就可以請求所有的服務(wù)，非常簡單。C版客戶端的代理利用HttpClient類來調(diào)用Restful服務(wù)，B版利用XMLHttpRequest對象請求服務(wù)。

7 結(jié)論

本文詳細(xì)介紹了一個基于.Net的快速開發(fā)框架的設(shè)計，包括客戶端框架，客戶端代理，中心服務(wù)器，應(yīng)用服務(wù)器外殼。闡述了各個組件的功能及其原理。這個框架是基于.Net 4.0 開發(fā)的，業(yè)務(wù)組件完全是自己定制，開發(fā)組件時可以利用框架提供的公共類庫，完成后配置服務(wù)即可宿主到應(yīng)用服務(wù)器中?？蛻舳酥С諧版和B版，內(nèi)容定制，C版開發(fā)后配置菜單即可運(yùn)行起來。這個框架已經(jīng)經(jīng)過多個項目實踐，確實能夠加快項目的開發(fā)交付，使客戶能夠快速響應(yīng)市場的需求。圖7是一個系統(tǒng)布署圖。

圖7

參考文獻(xiàn)：

[1] Erich Gamma.可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，譯.北京：機(jī)械工業(yè)出版社，2007.

[2] 錢樂秋.軟件工程[M].北京：清華大學(xué)出版社， 2007.

[3] 李紅芹.基于三層架構(gòu)的.NET數(shù)據(jù)庫業(yè)務(wù)系統(tǒng)開發(fā)[J].計算機(jī)與現(xiàn)代化，2009（10）：120-125.

[4] 竇文琦，孫士學(xué).基于分層架構(gòu)的WEB系統(tǒng)框架分析[J].電腦技術(shù)與知識，2013（9）：24.

緩存策略配置好后，中心服務(wù)器第一次使用緩存是就會初始化策略，每個請求到來時，會進(jìn)行如下流程處理（圖5所示）。

圖5 分布式緩存獲取流程圖

流程是根據(jù)緩存的配置文件確定當(dāng)前請求是否有配置緩存，如果是，則根據(jù)傳遞的參數(shù)獲取緩存的鍵值，根據(jù)鍵值獲取緩存，如果緩存為空，則去持久層獲取，再更新緩存，如果不為空，則直接返回，減少了與持久層的交互，提升了性能。

路由與負(fù)載均衡管理是客戶端的請求到來時，請求會自動轉(zhuǎn)發(fā)到負(fù)載較輕的應(yīng)用服務(wù)器上。由于在應(yīng)用服務(wù)器啟動的時候，會向中心服務(wù)器注冊，報告自己的地址和承載的服務(wù)，所以中心服務(wù)器會有一份詳細(xì)的關(guān)于所有應(yīng)用服務(wù)器的信息。當(dāng)請求到來時，會根據(jù)負(fù)載均衡算法，選擇一個負(fù)載較輕的應(yīng)用服務(wù)器。這樣的結(jié)構(gòu)使得應(yīng)用服務(wù)器可以水平擴(kuò)展，如果某個應(yīng)用服務(wù)器負(fù)擔(dān)很重，再部署一臺新的應(yīng)用服務(wù)器，承載相同的業(yè)務(wù)，向中心服務(wù)器注冊即可承載應(yīng)用，減輕另外一臺的壓力。負(fù)載均衡算法采用2種，最少連接數(shù)法和基于CPU，內(nèi)存，I/O訪問加權(quán)比較法。

會話管理是在中心服務(wù)器維護(hù)了所有登陸用戶的信息，包括用戶的令牌，用戶名稱，用戶的操作，用戶登陸時間等，同時開發(fā)了一個維護(hù)工具，可以清除在線用戶，刷新用戶登陸時間等。

日志和性能監(jiān)視是維護(hù)功能，主要記錄用戶的操作日志，以及異常信息，性能監(jiān)視器還記錄了每個請求的處理時間，可以用來分析性能障礙的原因，定位哪個操作引起性能差，為進(jìn)一步分析服務(wù)端提供了依據(jù)。

5 應(yīng)用服務(wù)器外殼

應(yīng)用服務(wù)器外殼是一個windows服務(wù)，用于承載業(yè)務(wù)組件，它是一個容器，把業(yè)務(wù)組件加載到容器中，同時接收中心服務(wù)器的請求，根據(jù)請求地址，調(diào)用具體業(yè)務(wù)組件，并把上下文和請求參數(shù)傳遞給組件。它的功能有：轉(zhuǎn)發(fā)請求，加載IOC容器，注冊服務(wù)器，保持心跳，動態(tài)編譯業(yè)務(wù)組件，異常處理。圖6為應(yīng)用服務(wù)器外殼功能圖：

圖6 應(yīng)用服務(wù)器外殼功能圖

轉(zhuǎn)發(fā)請求是應(yīng)用服務(wù)器的主要職責(zé)，應(yīng)該服務(wù)器外殼本身不處理請求，它把業(yè)務(wù)組件動態(tài)編譯后成為一個同一的接口，然后加載到內(nèi)存中，當(dāng)請求到來時，根據(jù)業(yè)務(wù)組件配置的服務(wù)名找到對應(yīng)的業(yè)務(wù)組件，傳遞上下文和參數(shù)到組件，并調(diào)用組件服務(wù)，最后把組件的處理的結(jié)果返回給中心服務(wù)器。

IOC容器管理負(fù)載加載業(yè)務(wù)組件的IOC配置，是利用Microsoft Enterprise Lib 5.0 的Unity來加載IOC，可以同時配置多個業(yè)務(wù)IOC容器，統(tǒng)一加載，業(yè)務(wù)組件再調(diào)用框架提供的IOC類庫即可訪問IOC內(nèi)部組件。

注冊服務(wù)器是向中心服務(wù)器注冊自己，包括自己的IP地址，協(xié)議信息，加載的業(yè)務(wù)組件服務(wù)，同時接收中心服務(wù)器返回的應(yīng)用服務(wù)器節(jié)點令牌作為自己的唯一標(biāo)識，此外還接受中心服務(wù)器返回的所有應(yīng)用服務(wù)器節(jié)點，節(jié)點的模塊信息和負(fù)載信息，所以應(yīng)用服務(wù)器外殼也維護(hù)了一份路由表，自己也可以路由到其他節(jié)點，無需中心服務(wù)器參與，這是多個應(yīng)用服務(wù)器之間調(diào)用的基礎(chǔ)。

心跳機(jī)制是應(yīng)用服務(wù)器每隔指定時間向中心服務(wù)器發(fā)送消息，告訴中心服務(wù)器自己的狀態(tài)，如果中心服務(wù)器長久沒有收到應(yīng)用服務(wù)器的報告，則認(rèn)為該應(yīng)用服務(wù)器沒有響應(yīng)，從路由表中移除它。

動態(tài)編譯是加載業(yè)務(wù)組件的核心功能。為了能夠快速響應(yīng)請求，業(yè)務(wù)組件沒有使用普通的反射原理，而是在服務(wù)啟動的時候把各個業(yè)務(wù)組件的服務(wù)經(jīng)過動態(tài)編譯為同一的接口并實例化到內(nèi)存中。當(dāng)請求來時根據(jù)請求地址找到對應(yīng)的業(yè)務(wù)組件后，無需再實例化了，直接可以調(diào)用服務(wù)，加快了響應(yīng)的速度。

異常處理是在動態(tài)編譯中統(tǒng)一處理的。業(yè)務(wù)組件都會被統(tǒng)一動態(tài)編譯為實現(xiàn)同一個接口的類，所以很容易的加入了異常處理，異常詳細(xì)信息記錄到日志，并返回給客戶端一個異常的ID和簡單的提示，不會包含具體的堆棧信息。

6 RESTful 架構(gòu)服務(wù)和代理

REST 即Representational State Transfer的縮寫，翻譯是"表現(xiàn)層狀態(tài)轉(zhuǎn)化"，如果一個架構(gòu)符合REST原則，就稱它為RESTful架構(gòu)。它有以下特點：

1）每一個URI代表一種資源；

2）客戶端和服務(wù)器之間，傳遞這種資源的某種表現(xiàn)層；

3）客戶端通過四個HTTP動詞，對服務(wù)器端資源進(jìn)行操作，實現(xiàn)"表現(xiàn)層狀態(tài)轉(zhuǎn)化"。

中心服務(wù)器就是RESful架構(gòu)服務(wù)，客戶端和服務(wù)端的交互在請求之間是無狀態(tài)的，從客戶端到服務(wù)器的每個請求都必須包含理解請求所必需的信息。如果服務(wù)器在請求之間的任何時間點重啟，客戶端不會得到通知。此外，無狀態(tài)請求可以由任何可用服務(wù)器回答，客戶端可以緩存數(shù)據(jù)以改進(jìn)性能。這樣客戶端請求的接口只有4個，Get，Put，Delete，Post，加上資源和參數(shù)就可以請求所有的服務(wù)，非常簡單。C版客戶端的代理利用HttpClient類來調(diào)用Restful服務(wù)，B版利用XMLHttpRequest對象請求服務(wù)。

7 結(jié)論

本文詳細(xì)介紹了一個基于.Net的快速開發(fā)框架的設(shè)計，包括客戶端框架，客戶端代理，中心服務(wù)器，應(yīng)用服務(wù)器外殼。闡述了各個組件的功能及其原理。這個框架是基于.Net 4.0 開發(fā)的，業(yè)務(wù)組件完全是自己定制，開發(fā)組件時可以利用框架提供的公共類庫，完成后配置服務(wù)即可宿主到應(yīng)用服務(wù)器中?？蛻舳酥С諧版和B版，內(nèi)容定制，C版開發(fā)后配置菜單即可運(yùn)行起來。這個框架已經(jīng)經(jīng)過多個項目實踐，確實能夠加快項目的開發(fā)交付，使客戶能夠快速響應(yīng)市場的需求。圖7是一個系統(tǒng)布署圖。

圖7

參考文獻(xiàn)：

[1] Erich Gamma.可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，譯.北京：機(jī)械工業(yè)出版社，2007.

[2] 錢樂秋.軟件工程[M].北京：清華大學(xué)出版社， 2007.

[3] 李紅芹.基于三層架構(gòu)的.NET數(shù)據(jù)庫業(yè)務(wù)系統(tǒng)開發(fā)[J].計算機(jī)與現(xiàn)代化，2009（10）：120-125.

[4] 竇文琦，孫士學(xué).基于分層架構(gòu)的WEB系統(tǒng)框架分析[J].電腦技術(shù)與知識，2013（9）：24.