可以免費(fèi)學(xué)習(xí)藍(lán)調(diào)的網(wǎng)站
BS與CS架構(gòu)
在很久以前宵荒，有web網(wǎng)頁的時候，有服務(wù)器和瀏覽器 這兩個東西是構(gòu)建我們?yōu)g覽互聯(lián)網(wǎng)的輔助工具豁鲤，瀏覽器是我們?yōu)g覽互聯(lián)網(wǎng)的主要入口兜材，而這只是我們常用的一種方式，除了瀏覽器我們?yōu)g覽互聯(lián)網(wǎng)還可以通過客戶端纫雁，也就是我們常用的exe程序煌往，而服務(wù)器就是我們?yōu)g覽的內(nèi)容，這些內(nèi)容不是憑空產(chǎn)生的是存在大型服務(wù)器里的轧邪，服務(wù)器和我們普通的電腦硬件(PC)內(nèi)容上沒什么刽脖，主要是操作系統(tǒng)會用一些開源的linux系統(tǒng)会钝，它的穩(wěn)定性會更好借嗽，更新也會更及時。綜合上述我們的這也就分成了瀏覽利用互聯(lián)網(wǎng)的兩個重要流派：
-
BS架構(gòu) -> Browser - Server -> 瀏覽器 - 服務(wù)器 e.g:大型網(wǎng)站 新聞門戶
2.png
優(yōu)缺點(diǎn)：
- B/S客戶端的計(jì)算機(jī)電腦配置要求較低
- B/S最大的優(yōu)點(diǎn)就是不用安裝任何專門的軟件镀琉，只要有一個瀏覽器就可以
- B/S客戶端不必安裝及維護(hù)
-
CS架構(gòu) -> Client - Server ->客戶端 - 服務(wù)器 e.g:QQ 網(wǎng)絡(luò)游戲 騰訊視頻（所有可以聯(lián)網(wǎng)的exe程序）
1.png
優(yōu)缺點(diǎn)：
- C/S客戶端的計(jì)算機(jī)電腦配置要求較高
- C/S每一個客戶端都必須安裝和配置專用的軟件
- C/S每一個客戶端都要進(jìn)行升級和維護(hù)
- C/S一般面向相對固定的用戶群硕糊，它可以對權(quán)限進(jìn)行多層次校驗(yàn)院水，提供了更安全的存取模式，對信息安全的控制能力很強(qiáng)简十。一般高度機(jī)密的信息系統(tǒng)應(yīng)采用C/S結(jié)構(gòu)
PS: 隨著互聯(lián)網(wǎng)的不斷發(fā)展 移動端逐漸興起檬某，App-IOS,Android是手機(jī)端的重要瀏覽方式，
在發(fā)展中前端框架google開發(fā)的augular的出現(xiàn)讓web開發(fā)出現(xiàn)了重大變革螟蝙，他讓web瀏覽器
通過http鏈接第一次訪問直接下載服務(wù)器程序（他就相當(dāng)于本地存儲也就是一個app）瀏覽
方式還是通過url鏈接去訪問網(wǎng)站但現(xiàn)在是混合開發(fā)恢恼，瀏覽器訪問也相當(dāng)于app訪問，他們倆
畫了一個等號胰默〕“撸【而這個時候前后端分離有了變化】。
前后端分離歷史與歷程
前后端未分離時代：
前后端耦合時代牵署，這時候有個技術(shù)模型叫做mvc漏隐，我們開發(fā)web網(wǎng)站都尊崇這個模式開發(fā)直到現(xiàn)在都是。
MVC: M->MODEL;V->VIEW;C->CONTROLLER
而開發(fā)的時候奴迅，很久以前的技術(shù)view層用jsp技術(shù)青责，control用servlet，mode用javabean
6.jpg
7.png
大致就是，所有的客戶端請求都被發(fā)送給作為控制器的Servlet爽柒，它接收請求，并根據(jù)請求信息將它們分發(fā)給適當(dāng)?shù)腏SP來響應(yīng)者填。同時浩村，Servlet還根據(jù)JSP的需求生成JavaBeans的實(shí)例并輸出給JSP環(huán)境。JSP可以通過直接調(diào)用方法或使用UseBean的自定義標(biāo)簽得到JavaBeans中的數(shù)據(jù)占哟。需要說明的是心墅，這個View還可以采用Velocity、Freemarker等模板引擎榨乎。使用了這些模板引擎怎燥，可以使得開發(fā)過程中的人員分工更加明確，還能提高開發(fā)效率蜜暑。
開發(fā)形式：
這種方式已經(jīng)逐漸淘汰铐姚。主要原因有兩點(diǎn)：
1.前端在開發(fā)過程中嚴(yán)重依賴后端，在后端沒有完成的情況下肛捍，前端根本無法干活隐绵。
2.由于趨勢問題，會JSP拙毫、懂Velocity和曉Freemarker等模板引擎的前端越來越少依许。
前后端半分離時代：
走過了前后端未分離的時代，來到了前后端半分離的時代缀蹄。在這個時代峭跳，前端負(fù)責(zé)開發(fā)頁面，通過接口（AJAX）獲取數(shù)據(jù)缺前，采用DOM操作對頁面進(jìn)行數(shù)據(jù)綁定蛀醉，最終是由前端把頁面渲染出來，這也就是AJAX與SPA應(yīng)用（單頁應(yīng)用）結(jié)合的方式.
8.png
1.瀏覽器請求诡延，CDN返回HTML頁面滞欠。
2.HTML中的JS代碼以AJAX的方式請求后臺的RESTFUL API接口。
3.接口響應(yīng)并返回JSON數(shù)據(jù)肆良，頁面解析JSON數(shù)據(jù)后通過DOM操作渲染頁面筛璧。
這里后端提供的都是以JSON為數(shù)據(jù)格式的API接口供Native端使用，同樣提供給WEB的也是JSON數(shù)據(jù)格式的API接口惹恃，那么就意味著WEB的工作流程是：
1.打開WEB瀏覽器夭谤，加載基本資源，如CSS巫糙、JS和圖片等朗儒。
2.使用JS發(fā)起一個AJAX請求到服務(wù)端請求數(shù)據(jù)，同時展示LOADING（加載中）。
3.得到JSON格式的數(shù)據(jù)后再根據(jù)邏輯選擇模板渲染出DOM字符串醉锄。
4.將DOM字符串插入頁面中WEB VIEW渲染出DOM結(jié)構(gòu)乏悄。
這些步驟都由用戶所使用的設(shè)備中逐步執(zhí)行，也就是說用戶的設(shè)備性能與APP的運(yùn)行速度緊密聯(lián)系恳不，換句話說檩小，如果用戶的設(shè)備很低端，那么APP打開頁面的速度就會很慢烟勋，極度影響用戶體驗(yàn)规求。
為什么說是半分離的呢，因?yàn)椴皇撬许撁娑际菃雾撁鎽?yīng)用卵惦。在多頁面應(yīng)用的情況下阻肿，前端因?yàn)闆]有掌握Controller層，前端需要和后端討論頁面是要同步輸出還是異步JSON渲染沮尿。而且即使在這個時期丛塌，通常也是一個工程師搞定前后端所有的工作。因此在這個階段只能算半分離蛹找。
這個時代比起上一個時代還是有進(jìn)步的姨伤，首先前端不會嵌入任何后臺代碼，前端專注于HTML庸疾、CSS乍楚、JS的開發(fā)，不依賴于后端届慈。自己還能夠模擬JSON數(shù)據(jù)來渲染頁面徒溪，發(fā)現(xiàn)BUG也能迅速定位出是誰的問題。
然而在這種架構(gòu)下還是存在明顯的弊端的金顿，最明顯的有如下幾點(diǎn)：
1.JS存在大量冗余臊泌，在業(yè)務(wù)復(fù)雜的情況下，頁面的渲染部分的代碼非常復(fù)雜揍拆。
2.在JSON返回的數(shù)據(jù)量比較大的情況下渠概，渲染非常緩慢，會出現(xiàn)頁面卡頓的情況嫂拴。
3.SEO（Serach Engine Optimization播揪，搜索引擎優(yōu)化）非常不方便。由于國內(nèi)的搜索引擎的爬蟲無法爬下JS異步渲染的數(shù)據(jù)筒狠，導(dǎo)致這樣的頁面SEO會存在一定的問題猪狈。
4.資源消耗嚴(yán)重，在業(yè)務(wù)復(fù)雜的情況下辩恼，一個頁面可能要發(fā)起多次HTTP請求才能將頁面渲染完畢雇庙∥叫危可能有人不服，覺得PC端建立多次HTTP請求也沒啥疆前，但是移動端建立一次HTTP請求的消耗十分巨大寒跳。
真是因?yàn)槿缟系娜秉c(diǎn)，我們在亟需真正的前后端分離架構(gòu)
前后端分離時代：
這個時候是淘寶進(jìn)行的首次項(xiàng)目開發(fā)竹椒，他開創(chuàng)性的運(yùn)用了node.js做中間層冯袍。前端負(fù)責(zé)View和Controller層，后端只負(fù)責(zé)Model層和Service層碾牌。Controller層要怎么實(shí)現(xiàn)呢？NodeJS適合運(yùn)用在高并發(fā)儡循、I/O密集舶吗、少量業(yè)務(wù)邏輯的場景。他利用了谷歌瀏覽器v8引擎择膝，速度非常的快誓琼，最重要的一點(diǎn)是，前端不用再學(xué)一門其它語言了肴捉，美滋滋腹侣。可以把NodeJS當(dāng)成跟前端交互的API齿穗。
3.png
- NodeJS路由的實(shí)現(xiàn)邏輯是把前端靜態(tài)頁面代碼當(dāng)成字符串發(fā)送到客戶端（例如瀏覽器）傲隶，簡單理解可以理解為路由是提供給客戶端的一組API接口，只不過返回的數(shù)據(jù)是頁面代碼的字符串而已窃页。
- 用NodeJS來作為橋梁架構(gòu)服務(wù)端API輸出的JSON能帶來優(yōu)異性能跺株。后端處于性能和別的原因，提供的接口所返回的數(shù)據(jù)格式也許不太適合前端直接使用脖卖，前端所需的排序功能乒省、篩選功能以及到了視圖層的頁面展現(xiàn)，也許都需要對接口所提供的數(shù)據(jù)進(jìn)行二次處理畦木。這些處理雖然是可以放在前端來執(zhí)行袖扛，但如果數(shù)據(jù)量一大，便會浪費(fèi)瀏覽器性能十籍，更會降低頁面渲染速度蛆封，影響用戶體驗(yàn)。因而如今增加NodeJS中間層是一種良好的解決方案妓雾。
- 增加了NodeJS中間層之后娶吞，瀏覽器（Webview）便不再直接請求服務(wù)端的API，而是瀏覽器先去請求服務(wù)端的NodeJS械姻，由NodeJS對服務(wù)端的API發(fā)起HTTP請求妒蛇，NodeJS收到服務(wù)端的API響應(yīng)返回的JSON后就去渲染HTML頁面机断，然后NodeJS直接將HTML頁面flush到瀏覽器。這樣绣夺，瀏覽器得到的就是普通的HTML頁面吏奸，不再用發(fā)AJAX去請求服務(wù)器之后再在瀏覽器進(jìn)行頁面渲染了。
增加NodeJS中間層主要有以下優(yōu)點(diǎn)：
適配性提升陶耍。我們在開發(fā)過程中奋蔚，經(jīng)常會給PC端、Mobile烈钞、App端各自研發(fā)一套前端泊碑。其實(shí)對于這三端來說，大部分業(yè)務(wù)邏輯是一樣的毯欣，唯一的區(qū)別就是交互展現(xiàn)邏輯的不同馒过。如果Controller層在后端手里，后端為了這些不同端頁面展現(xiàn)邏輯酗钞，自己維護(hù)這些Controller腹忽，模板無法重用，徒增與前端溝通成本砚作。如果增加了NodeJS層窘奏，每種前端的界面展示邏輯由NodeJS層自己維護(hù)。產(chǎn)品經(jīng)理在中途如果想要改動界面葫录，可以由前端自己維護(hù)着裹，無需后端操心。前后端各司其職米同，后端專注于自己的業(yè)務(wù)邏輯開發(fā)求冷，前端專注于產(chǎn)品效果開發(fā)。
9.png
2.響應(yīng)速度提升窍霞。有的時候會遇到后端返回給前端得數(shù)據(jù)太簡單了匠题，需要前端對這些數(shù)據(jù)進(jìn)行邏輯處理。那么在數(shù)據(jù)量比較小得時候但金，對其做運(yùn)算分組等操作韭山，并無影響。但是當(dāng)數(shù)據(jù)量大的時候冷溃，會有明顯的卡頓效果钱磅。這時候，NodeJS中間層其實(shí)可以將很多這樣的代碼放入NodeJS層處理似枕，也可以替后端分擔(dān)一些簡單的邏輯盖淡、又可以用模板引擎自己掌握前臺的輸出。這樣做凿歼，靈活度褪迟、響應(yīng)度都有較大的提升冗恨。
3.性能得到提升。大家應(yīng)該都知道單一職責(zé)原則味赃，從該角度來看掀抹，我們請求一個頁面，可能要響應(yīng)很多個后端接口心俗，請求變多了傲武，自然速度就變慢了，這種現(xiàn)象在Mobile端更加嚴(yán)重城榛。采用NodeJS作為中間層揪利，將頁面所需要的多個后端數(shù)據(jù)直接在內(nèi)網(wǎng)階段就拼裝好，再統(tǒng)一返回給前端狠持，會得到更好的性能土童。
4.異步與模板統(tǒng)一。淘寶首頁就是由幾十個HTML片段（每個片段一個文件）拼裝成的工坊。之前PHP同步加載這幾十個片段，一定是串行的敢订，換成NodeJS之后就可以實(shí)現(xiàn)異步加載王污，讀文件可以并行，一旦這些片段中也包含業(yè)務(wù)邏輯楚午，異步的優(yōu)勢就很明顯了昭齐，真正做到哪個文件先渲染完就先輸出顯示。前端機(jī)的文件系統(tǒng)越復(fù)雜矾柜，頁面的組成片段越多阱驾，這種異步的提速效果就越明顯。前后端模板統(tǒng)一在無線領(lǐng)域很有用怪蔑，PC頁面和WIFI場景下的頁面適合前端渲染（后端數(shù)據(jù)通過AJAX返回到前端）里覆，2G/3G弱網(wǎng)絡(luò)環(huán)境則適合后端渲染（數(shù)據(jù)隨著頁面一起返回給前端），所以同樣的模板缆瓣，在不同的條件下走不同的渲染渠道喧枷，模板只需要一次開發(fā)。
前后端分離的缺點(diǎn):
1.人員問題弓坞。宣傳這種架構(gòu)的公司一般都是很高級別的公司隧甚，一般的中小型公司沒有這樣的前端資源來支撐這樣的架構(gòu)。如果強(qiáng)推前后端分離的架構(gòu)可能會導(dǎo)致很多問題 渡冻，比如后端被逼著去學(xué)VueJS戚扳，NodeJS這些，白白增加后端的負(fù)擔(dān)族吻，甚至?xí)斐珊蠖碎_發(fā)紛紛離職的情況帽借。
2.產(chǎn)品迭代周期的問題珠增。中小型的軟件公司一般需要一個比較快的軟件迭代周期。采用前后端分離架構(gòu)的話宜雀，增加了一個接口指定流程和前后端聯(lián)調(diào)流程切平。從本質(zhì)上來說放慢了迭代的周期。
3.前端需要學(xué)習(xí)業(yè)務(wù)知識辐董。本來前端只需要掌管視覺交互的部分°财罚現(xiàn)在因?yàn)镃ontroller層也歸前端管了，前端必須對公司的業(yè)務(wù)流程有深入的了解简烘，才能準(zhǔn)確地寫出顯示邏輯苔严。不過這樣會讓后端覺得前端奪權(quán)，前端在混KPI孤澎。前端雖然必須要去學(xué)無聊的業(yè)務(wù)届氢，但是有得必有失，前端也因此能夠站穩(wěn)腳跟覆旭。也許正是因?yàn)榍昂蠖朔蛛x架構(gòu)的出現(xiàn)退子，前端可以朝著架構(gòu)師進(jìn)軍.
這是我的個人網(wǎng)址，用于分享和技術(shù)記錄還可以學(xué)習(xí)藍(lán)調(diào)口琴希望大家多點(diǎn)擊啊
