架構設計之CS架構
C/S架構,玩的是“寂寞”
——C/S架構的新認識
房產HIS開發部王薔
C/S(Client/Server)架構是客戶端和伺服器架構,通過充分利用兩端硬體環境的優勢,將任務合理分配到Client端和Server端來實現。B/S(Browser/Server)架構是瀏覽器和伺服器架構,使用者工作介面是通過瀏覽器來實現,極少部分事務邏輯在前端(Browser)實現,但是主要事務邏輯在伺服器端(Server)實現。
C/S和B/S架構是當今世界開發模式技術架構的兩大主流技術。C/S是美國Borland公司最早研發的,B/S是美國微軟公司研發。關於兩種架構的優劣勢爭論一直都存在,也沒有一個定論,所以本文不探討兩種架構的優劣勢,只是根據作者多年的C/S
在房產行業管理軟體中登記管理子系統是最核心的系統,該系統兩種架構的軟體都有,如何選擇一個合適自身的軟體架構對於我們房產行業資訊化的從業人員來說是一個很頭疼的問題。如果你做為房管部門的系統管理員還在為C/S架構系統的安裝升級維護麻煩而苦惱的話,那本篇文章會給你帶來另一種認識。
一、三層架構:
傳統的C/S架構一般採用兩層架構,客戶端接受使用者的請求,客戶端向資料庫服務提出請求,資料庫服務將資料提交給客戶端,客戶端將資料進行計算(可能涉及到運算、彙總、統計等等)並將結果呈現給使用者。而在三層架構中,客戶端接受使用者的請求,客戶端嚮應用服務提出請求,應用服務從資料庫服務中獲得資料,應用服務將資料進行計算並將結果提交給客戶端,客戶端將結果呈現給使用者。
兩層架構中客戶端參與計算,而三層架構中客戶端並不參與計算,只是簡單地接收使用者的請求,顯示最後的結果。由於三層架構中的客戶端並不需要參與計算,所以對客戶端計算機的配置要求是比較低的。由於應用服務到客戶端只是傳遞最終的結果,資料量較少,所以對網路的要求不高,需要的只是提高伺服器的配置。由於資料計算(業務邏輯)處理都放在應用服務層,客戶端只是一個顯示的載體,所以當業務邏輯發生變化時,只需更新應用服務即可,而不用更新每個客戶端。
在三層體系結構中,客戶端和應用服務層的通訊可採用WebServices或Remoting技術來實現。如果在區域網內執行的系統,採用Remoting技術,效能和速度會顯得更優。
房產管理軟體C/S架構三層架構圖
二、客戶端無盤一鍵安裝:
B/S系統客戶端只需要安裝了瀏覽器,使用者輸入URL地址就可以開啟系統,而傳統的C/S系統需要通過光碟或拷貝安裝檔案點選setup來進行安裝,比如我們使用的QQ、迅雷、Office工具都需要有相應的安裝檔案才能進行安裝。微軟為了解決C/S系統安裝麻煩的問題,提出了ClickOnce部署技術,使用該技術可建立自行更新的基於Windows的應用程式,這些應用程式可以通過最低程式的使用者互動來安裝和執行。ClickOnce部署自動提供更新,只有更改過的應用程式部分才會被下載。
使用ClickOnce技術釋出的C/S應用程式,使用者只需要在客戶端通過瀏覽器輸入系統釋出地址,就可以點選安裝進行線上安裝,而無需插入安裝光碟或拷貝安裝檔案來進行安裝。當系統更新重新發布後,使用者再次進入系統時會自動更新,而無需去手工去下載或拷貝系統更新包。
在傳統的C/S系統安裝過程中,需要人工去幹預選擇需要安裝的元件、安裝檔案的路徑、是否建立快捷方式等,這些對普通使用者來說都是必須的操作,不過使用者操作的都是點選下一步到最後的完成,沒有真正意義上的互動過程,只是機械地告訴計算機要進行下一步操作,而事實上每個安裝程式都為我們提供了一種靜默安裝模式,也就是無使用者互動安裝,使用這種模式,使用者只需操作一次滑鼠或鍵盤就可以完成安裝。將靜默安裝和ClickOnce部署技術結合在一起可以實現客戶端無盤一鍵安裝,使用者只需要開啟瀏覽器輸入URL地址點選一次滑鼠就可以完成整個安裝過程。
三、伺服器一鍵安裝:
無論是在C/S系統還是B/S系統中,伺服器的安裝是讓所有系統管理員很頭疼的事,伺服器的第一次安裝和伺服器崩潰後無備份的恢復都會花費大量的時間和精力,除開作業系統的安裝外,伺服器的平臺軟體安裝很繁瑣很耗時,比如大型資料庫(Oracle/SQL Server)的安裝、資料恢復、GIS空間資料引擎(ArcSDE)的安裝等等都需要很多的使用者互動才能安裝好,如果操作不慎,安裝可能會失敗,最壞的情況可能還需要重灌作業系統,這些都會讓系統管理員鬱悶很久。借鑑客戶端的靜默安裝技術,我們可以通過編寫程式讓系統來模擬人工操作完成伺服器所有平臺的安裝,有點類似我們在安裝作業系統時的無人值守安裝,在安裝完作業系統後會自動安裝一些常用的工具軟體。
正所謂“尺有所長,寸有所短”,任何事物都具有兩面性,B/S與C/S也有各自的優缺點,希望通過本文的描述可以改變您對C/S架構傳統的一些認識,也同時感慨先進技術帶給我們的一些優越性,能夠讓我們從容地選擇適合自身的架構。
相關推薦
架構設計之CS架構
C/S架構,玩的是“寂寞” ——C/S架構的新認識 房產HIS開發部王薔 C/S(Client/Server)架構是客戶端和伺服器架構,通過充分利用兩端硬體環境的優勢,將任務合理分配到Client端和Server端來實現。B/S(Browser/Server)架構是瀏覽器和
分布式架構設計之電商平臺
用戶服 base 介紹 val 重要 本地 交互 pac 一定的 分布式架構設計之電商平臺 何為軟件架構?不同人的答案會有所不同,而我認為一個好的軟件架構除了要具備業務功能外,還應該具備一定的高性能、高可用、高伸縮性及可拓展等非功能需求。而軟件架構是由業務架構和技術架構
SoC嵌入式軟件架構設計之三:代碼分塊(Bank)設計原則
post 介紹 讀寫 cor 層次 clas rom bank 分配 上一節講述了在沒有MMU的CPU(如80251、MIPS M控制器系列、ARM cortex m系列)上實現虛擬內存管理的集成硬件設計方法。新設計的內存管理管理單元要實現虛擬內存管理還須要
SaaS架構設計之如何轉化成SaaS多租戶模式
分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!  
架構設計之六個複雜度來(續)
這篇繼上篇架構設計之六個複雜度來源 沒有講完的剩下的三個內容低成本、安全、規模等。 一、低成本 當我們的架構方案只涉及幾臺或者十幾臺伺服器時,一般情況下成本並不是我們重點關注的目標,但如果架構方案設計幾百甚至上千上萬臺伺服器,成本就會變成一個非常重要的架構設計考慮點。例如,A方案需要100
阿里架構設計之初體驗,送給準備進階架構的朋友(個人總結)
1 基本概念和目的 架構設計的目的是為了解決系統複雜度帶來的問題,並不是要面面俱到,不需要每個架構都具備高效能、高可用、高擴充套件等特點,而是要識別出實際業務實際情況的複雜點,然後有有針對性地解決問題,即:有的放矢,而不是貪大求全。 在實際情況中,不一定每個系統都要做架
小牛帶你架構設計之服務限流
v閱讀目錄 v部落格前言 限流可以認為服務降級的一種,限流就是限制系統的輸入和輸出流量已達到保護系統的目的。一般來說系統的吞吐量是可以被測算的,為了保證系統的穩定執行,一旦達到的需要限制的閾值,就需要限制流量並採取一些措施以完成限制流量的目的。比如:延遲處理,拒絕處理,
架構設計之「資料庫從主備到主主的高可用方案」
在網際網路專案中,當業務規模越來越大,資料越來越多,隨之而來的就是資料庫壓力會越來越大。慢慢就會發現,資料庫層可能已經成為了整個系統的關鍵點和效能瓶頸了,因此實現資料層的高可用就成為了我們專案中經常要解決的問題。 本文我們就來聊一聊如何實現資料儲存層的高可用方案。在保障資料層的高效能與高穩定方面,最容易想到的
架構設計之「資料庫叢集方案」
在之前的文章中,我們知道資料庫服務可能已經成為了很多系統的效能關鍵點,甚至是瓶頸了。也給大家介紹了資料庫伺服器從主備架構、到主從架構、再到主主架構的基礎方案。但如果單臺機器已經不能滿足完整業務資料儲存的時候,我們就需要考慮採用多機甚至多中心的部署方案了。 今天我們就再來聊一聊,在多機環境下,資料庫叢集的架構方
高效能網站架構設計之快取篇(6)- Redis 叢集命令
叢集cluster info :列印叢集的資訊cluster nodes :列出叢集當前已知的所有節點( node),以及這些節點的相關資訊。節點cluster meet <ip> <port> :將 ip 和 port 所指定的節點新增到叢集當中,讓它成為叢集的一份子。cluster
高效能網站架構設計之快取篇(3)- Redis 的配置
我們說Redis是一個強大的Key-Value儲存系統,在前面我們已遇到了兩個問題: 1、redis server 啟動後,獨佔程序,能不能修改為後臺服務呢? 2、redis server 服務是單執行緒的,而我的機器是多核的,能不能在同一臺機器上開啟多個例項更充分的利用 cpu 資源呢?但6379埠已經
高效能網站架構設計之快取篇(1)- Redis的安裝與使用
一、什麼 Redis REmote DIctionary Server,簡稱 Redis,是一個類似於Memcached的Key-Value儲存系統。相比Memcached,它支援更豐富的資料結構,包括string(字串)、list(連結串列)、set(集合)、zset(sorted set --有序集合)
高效能網站架構設計之快取篇(5)- Redis 叢集(上)
叢集技術是構建高效能網站架構的重要手段,試想在網站承受高併發訪問壓力的同時,還需要從海量資料中查詢出滿足條件的資料,並快速響應,我們必然想到的是將資料進行切片,把資料根據某種規則放入多個不同的伺服器節點,來降低單節點伺服器的壓力。 上一篇我們講到了 Redis 的主從複製技術,當實現了多節點的 master
高效能網站架構設計之快取篇(4)- Redis 主從複製
Redis 的主從複製配置非常容易,但我們先來了解一下它的一些特性。 redis 使用非同步複製。從 redis 2.8 開始,slave 也會週期性的告訴 master 現在的資料量。可能只是個機制,用途應該不大。 一個 master 可以擁有多個 slave,廢話,這也是業界的標配吧。
高效能網站架構設計之快取篇(2)- Redis C#客戶端
在上一篇中我簡單的介紹瞭如何利用redis自帶的客戶端連線server並執行命令來操作它,但是如何在我們做的專案或產品中操作這個強大的記憶體資料庫呢?首先我們來了解一下redis的原理吧。 官方文件上是這樣說的:Redis在TCP埠6379上監聽到來的連線,客戶端連線到來時,Redis伺服器為此建立一個TC
高效能網站架構設計之快取篇(6)- Redis 叢集(中)
昨天晚上釣魚回來,大發神經,寫了篇概括程式設計師生活現狀的文章,沒想到招來眾多人的口誅筆伐,大有上升到政治層面的趨勢。 我也許不會再發表任何衝擊心靈的文章,我希望給大家帶來更多的正能量,所以那篇文章已被我刪除。 我的本意只是想讓各位看過文章之後能冷靜地思考自己的程式人生,不管是對是錯,人都有選擇的權力,走
IM系統架構設計之淺見
背景:除去大名鼎鼎的QQ這款即時聊天工具,還有許多細分行業的IM,比如淘寶阿里旺旺、網易泡泡、YY語音......。恰巧公司產品也要開發一款基於我們自己行業的類IM系統,很有幸我擔當了這個產品的架構師,核心程式碼編寫、實現者。下面我近年來從技術上我對IM系統(即時訊息的傳
Android外掛化架構設計之載入資原始檔
開篇介紹 現在專案比較大 資源比較多,但是若希望動態來載入資原始檔,可以有以下幾種方式: 1. 通過下載資原始檔zip包然後解壓來載入 2. 通過外掛開發 本文通過外掛開發來實現載入外掛中的資原始檔. 程式演示 也可以開啟連結 效果演示 開
系統架構設計之微服務(Microservice)
看了這篇文章總體上會對微服務有個認識,如果不是分散式應用和採用雲部署模式,微服務基本上是一個技術概念,如果不能得以實踐,姑且聽之。 什麼是微服務架構? 微服務是指開發一個單個 小型的但有業務功能的服務,每個服務都有自己的處理和輕量通訊機制,可以部署在單個或多個伺服器上
架構設計之Spring-Session分散式叢集會話管理
前言 通常在web開發中,會話管理是很重要的一部分,用於儲存與使用者相關的一些資料。對於JAVA開發者來說,專案中的session一般由Tomcat或者jetty容器來管理。 特點介紹 儘管使用特定的容器可以很好地實現會話管理,但是獨立容器掛掉或者由於其他原因重啟會導致使用者資訊丟失,並且無法支援分散式叢集會