目錄

一.什么是B/S架構(gòu)？

二.B/S架構(gòu)與C/S架構(gòu)有什么區(qū)別？

三.B/S架構(gòu)的優(yōu)缺點(diǎn)

四.B/S架構(gòu)的幾種形式

1：客戶端-服務(wù)器-數(shù)據(jù)庫(kù)

2：客戶端－web服務(wù)器－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

3：客戶端－負(fù)載均衡器(Nginx)－中間服務(wù)器(Node)－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

一.什么是B/S架構(gòu)？

B/S架構(gòu)，即瀏覽器/服務(wù)器架構(gòu)，是一種網(wǎng)絡(luò)架構(gòu)模式，將系統(tǒng)功能實(shí)現(xiàn)的核心部分集中到服務(wù)器上，簡(jiǎn)化了系統(tǒng)的開發(fā)、維護(hù)和使用?？蛻舳酥恍枰惭b一個(gè)瀏覽器，通過(guò)Web服務(wù)器與數(shù)據(jù)庫(kù)服務(wù)器進(jìn)行數(shù)據(jù)交互。B/S架構(gòu)利用了Web瀏覽器技術(shù)和Internet協(xié)議，實(shí)現(xiàn)了異構(gòu)系統(tǒng)的連接和信息的共享。

B/S架構(gòu)的分層：

第一層表現(xiàn)層：主要完成用戶和后臺(tái)的交互及最終查詢結(jié)果的輸出功能。

第二層邏輯層：主要是利用服務(wù)器完成客戶端的應(yīng)用邏輯功能。

第三層數(shù)據(jù)層：主要是接受客戶端請(qǐng)求后獨(dú)立進(jìn)行各種運(yùn)算。

二.B/S架構(gòu)與C/S架構(gòu)有什么區(qū)別？

B/S架構(gòu)與傳統(tǒng)的C/S架構(gòu)有什么區(qū)別呢？C/S架構(gòu)，即客戶端/服務(wù)器架構(gòu)，是一種分布式應(yīng)用模式，將系統(tǒng)功能分為兩層：客戶端和服務(wù)器端?？蛻舳素?fù)責(zé)用戶界面和業(yè)務(wù)邏輯，服務(wù)器端負(fù)責(zé)數(shù)據(jù)存儲(chǔ)和處理。C/S架構(gòu)需要在每個(gè)客戶端安裝專用的軟件，對(duì)網(wǎng)絡(luò)和硬件資源的要求較高。

三.B/S架構(gòu)的優(yōu)缺點(diǎn)

B/S架構(gòu)和C/S架構(gòu)各有優(yōu)缺點(diǎn)，具體選擇要根據(jù)系統(tǒng)的需求和環(huán)境來(lái)決定。下面我們來(lái)比較一下它們的主要特點(diǎn)：

- 開發(fā)成本：B/S架構(gòu)的開發(fā)成本相對(duì)較低，因?yàn)榭梢岳矛F(xiàn)有的Web技術(shù)和工具，而且不需要考慮客戶端的兼容性問題。C/S架構(gòu)的開發(fā)成本相對(duì)較高，因?yàn)樾枰_發(fā)專門的客戶端軟件，并且要適應(yīng)不同的操作系統(tǒng)和硬件環(huán)境。
- 維護(hù)成本：B/S架構(gòu)的維護(hù)成本相對(duì)較低，因?yàn)橹恍枰?jí)服務(wù)器端的軟件，而客戶端無(wú)需安裝或更新。C/S架構(gòu)的維護(hù)成本相對(duì)較高，因?yàn)樾枰诿總€(gè)客戶端進(jìn)行安裝或更新，并且要處理各種軟硬件故障。
- 安全性：B/S架構(gòu)的安全性相對(duì)較低，因?yàn)閿?shù)據(jù)傳輸過(guò)程中容易被截取或篡改，而且客戶端無(wú)法控制用戶的訪問權(quán)限。C/S架構(gòu)的安全性相對(duì)較高，因?yàn)閿?shù)據(jù)傳輸過(guò)程中可以采用加密或認(rèn)證技術(shù)，而且客戶端可以設(shè)置用戶的訪問權(quán)限。
- 交互性：B/S架構(gòu)的交互性相對(duì)較高，因?yàn)榭梢岳肳eb瀏覽器的多種腳本語(yǔ)言和ActiveX技術(shù)，實(shí)現(xiàn)動(dòng)態(tài)和豐富的用戶界面。C/S架構(gòu)的交互性相對(duì)較低，因?yàn)榭蛻舳塑浖墓δ芎徒缑媸芟抻陂_發(fā)工具和平臺(tái)。
- 擴(kuò)展性：B/S架構(gòu)的擴(kuò)展性相對(duì)較高，因?yàn)榭梢酝ㄟ^(guò)增加服務(wù)器或負(fù)載均衡技術(shù)，提高系統(tǒng)的并發(fā)能力和可靠性。C/S架構(gòu)的擴(kuò)展性相對(duì)較低，因?yàn)樾枰紤]客戶端軟件的兼容性和升級(jí)問題。

綜上所述，B/S架構(gòu)是一種適合于Internet環(huán)境下的網(wǎng)絡(luò)應(yīng)用模式，它具有開發(fā)、維護(hù)簡(jiǎn)單，交互性強(qiáng)，擴(kuò)展性好等優(yōu)點(diǎn)。但是它也存在著安全性差，數(shù)據(jù)傳輸效率低等缺點(diǎn)。因此，在選擇B/S架構(gòu)時(shí)，需要根據(jù)系統(tǒng)

四.B/S架構(gòu)的幾種形式

1：客戶端-服務(wù)器-數(shù)據(jù)庫(kù)

這個(gè)應(yīng)該是我們平時(shí)比較常用的一種模式：

1、客戶端向服務(wù)器發(fā)起Http請(qǐng)求

2、服務(wù)器中的web服務(wù)層能夠處理Http請(qǐng)求

3、服務(wù)器中的應(yīng)用層部分調(diào)用業(yè)務(wù)邏輯，調(diào)用業(yè)務(wù)邏輯上的方法

4、如果有必要，服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交換. 然后將模版＋數(shù)據(jù)渲染成最終的Html, 返送給客戶端

2：客戶端－web服務(wù)器－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

類似于第一種方法，只是將web服務(wù)和應(yīng)用服務(wù)解耦

1 客戶端向web服務(wù)器發(fā)起Http請(qǐng)求

2 web服務(wù)能夠處理Http請(qǐng)求，并且調(diào)用應(yīng)用服務(wù)器暴露在外的RESTFUL接口

3 應(yīng)用服務(wù)器的RESTFUL接口被調(diào)用，會(huì)執(zhí)行對(duì)應(yīng)的暴露方法.如果有必要和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互，應(yīng)用服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行交互后，將json數(shù)據(jù)返回給web服務(wù)器

4 web服務(wù)器將模版＋數(shù)據(jù)組合渲染成html返回給客戶端

3：客戶端－負(fù)載均衡器(Nginx)－中間服務(wù)器(Node)－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

這種模式一般用在有大量的用戶，高并發(fā)的應(yīng)用中。

1、整正暴露在外的不是真正web服務(wù)器的地址，而是負(fù)載均衡器器的地址

2、客戶向負(fù)載均衡器發(fā)起Http請(qǐng)求

3、負(fù)載均衡器能夠?qū)⒖蛻舳说腍ttp請(qǐng)求均勻的轉(zhuǎn)發(fā)給Node服務(wù)器集群

4、Node服務(wù)器接收到Http請(qǐng)求之后，能夠?qū)ζ溥M(jìn)行解析，并且能夠調(diào)用應(yīng)用服務(wù)器暴露在外的RESTFUL接口

5、應(yīng)用服務(wù)器的RESTFUL接口被調(diào)用，會(huì)執(zhí)行對(duì)應(yīng)的暴露方法.如果有必要和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互，應(yīng)用服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行交互后，將json數(shù)據(jù)返回給Node

6、Node層將模版＋數(shù)據(jù)組合渲染成html返回反向代理服務(wù)器

7、反向代理服務(wù)器將對(duì)應(yīng)html返回給客戶端

?文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-446928.html

到了這里，關(guān)于什么是B/S架構(gòu)？的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！