常用的架構模式之一——客戶端-服務器模式

    客戶端-服務器模式,即咱們常說的C/S模式。它是經常使用的架構模式之一。C/S架構能夠是兩層的,也可使三層的。前端

    兩層的C/S是基於資源不對等,且爲實現共享而提出來的,是20世紀90年代成熟起來的技術,C/S架構定義了工做站(客戶應用程序)如何與服務器相連,以實現數據和應用分佈到多臺計算機上。服務器負責有效地管理系統的資源,其任務集中於:數據庫安全性的要求、數據庫訪問併發性的控制、數據庫前端的客戶應用程序的全局數據完整性規則、數據庫的備份與恢復,除最後一點,其餘幾點可歸納爲對數據庫管理系統的管理和控制;客戶應用程序的主要任務是提供用戶與數據庫交互的界面,向數據庫服務器提交用戶請求並接收來自數據庫服務器的信息,對存在於客戶端的數據執行應用邏輯要求。網絡通訊軟件的主要做用是完成數據庫服務器和客戶應用程序之間的數據傳輸。數據庫

    C/S架構將應用一分爲二,服務器(後臺)負責數據管理,客戶機(前臺)完成與用戶的交互任務。服務器爲多個客戶應用程序管理數據,而客戶程序發送、請求和分析從服務器接收的數據。安全

 

 

    在一個C/S結構的軟件系統中,客戶應用程序是針對一個小的、特定的數據集,如一個表的某一行來進行操做,而不是像文件服務器那樣針對整個文件進行,對某一條記錄進行封鎖,而不是對整個文件進行封鎖,所以保證了系統的併發性,並使網絡上傳輸的數據量減到最少,從而改善了系統的性能。服務器

    C/S結構的優勢主要在於系統的客戶應用程序和服務器構建分別運行在不一樣的計算機上,系統中每臺服務器均可以適合各構件的要求,這對於硬件和軟件的變化顯示出極大的適應性和靈活性,並且易於對系統進行擴充和縮小。在C/S結構中,系統中的功能構件充分隔離,客戶應用程序的開發集中於數據的顯示和分析,而數據庫服務器的開發則集中於數據的管理,沒必要在每個新的應用程序中都要對一個DBMS進行編碼。將大的應用處理任務分佈到許多經過網絡鏈接的低成本計算機上,以節約大量的費用。網絡

    C/S體系結構具備強大的數據操做和事務處理能力,模型思想簡單,易於人們理解和接受。但隨着企業規模的日益擴大,軟件的複雜程度不斷提升,C/S結構逐漸暴露了如下缺點:架構

1.開發成本較高,C/S體系結構對客戶端軟硬件要求配置較高,尤爲是軟件的不斷升級,對硬件要求不斷提升,增長了整個系統的成本,且客戶端變得愈來愈臃腫。併發

2.客戶端程序設計複雜,採用C/S結構進行軟件開發,大部分工做量放在客戶端的程序設計上,客戶端顯得十分龐大。工具

3.信息內容和形式單一,由於傳統應用通常爲事務處理,界面基本遵循數據庫的字段解釋,開發之初就已肯定,用戶得到的只是單純的字符和數字,即枯燥又死板。性能

4.用戶界面風格不一,使用繁雜,不利於推廣使用。開發工具

5.軟件移植困難,採用不一樣的開發工具或平臺開發的軟件,通常互不兼容,不能或很難移植到其餘平臺上運行。

6.軟件維護和升級困難,採用C/S結構的軟件要升級,開發人員必須現場爲客戶機升級,每一個客戶機上的軟件都需維護。對軟件的一個小小的改動,每個客戶端都必需要更新。

7.新技術不能輕易應用,由於一個軟件平臺及開發工具一旦選定,不可能輕易更改。

    二層C/S結構的客戶機的負荷過重,而且是單一服務器且以局域網爲中心的,難以擴展。所以出現了三層C/S結構,與二層相比增長了一個應用服務器。而HI有表示層存在於客戶機上,整個應用用邏輯駐留在應用服務器上。也就是「瘦客戶機」。

      三層結構在邏輯上保持了相對獨立性,提升系統的可擴展性和可維護性。能夠更靈活的選擇平臺。

      

      精簡總結版:

 特定環境:大量用戶訪問如何進行優化客戶端海量資源 一個問題:資源不對等,如何實現資源共享 解決方案:1.增長服務器數量 2優化數據庫-鏈接池訪問數   3二層發展成三層-中間件篩選過濾: (二層是客戶端-服務器直接進行交互。三層架構的中間件被用來執行全部的安全檢查和重負載狀況下的負載平衡。中間件須要從客戶端的全部請求,並作必要的驗證後,經過向服務器發出請求。而後,服務器沒有所需的處理和發送響應回中間件,中間件終於經過這個響應返回給客戶端。)   4優化客戶端,服務器處理完後0.06秒已已經處理完,已傳輸到了但在5秒客戶端才顯示。 5中間加隊列,減小數據庫的壓力 實例:京東圖書大促時服務器崩潰,增長服務器數量並不能解決問題。這時須要找到瓶頸,如控制數據庫的鏈接數量等
相關文章
相關標籤/搜索