前后端分離框架在軟件設(shè)計中的應(yīng)用

農(nóng)振勁

摘要：在我們看到的很多互聯(lián)網(wǎng)軟件應(yīng)用開發(fā)和運營模式案例中，一些網(wǎng)絡(luò)公司在互聯(lián)網(wǎng)軟件項目的開發(fā)和運營中仍然繼續(xù)沿用這種傳統(tǒng)的應(yīng)用開發(fā)和運營模式。 在這種運行模式下，程序的前后端軟件高度交叉耦合，系統(tǒng)升級和維護(hù)操作相當(dāng)困難。 本文簡要分析和探討了國內(nèi)軟件前端開發(fā)技術(shù)方法，介紹和分析了一些流行的前端分離軟件設(shè)計方法，希望可以起到一定的借鑒作用。

關(guān)鍵詞： 前端分離框架， 軟件設(shè)計， 應(yīng)用

導(dǎo)讀：在互聯(lián)網(wǎng)技術(shù)飛速發(fā)展的今天，前端開發(fā)長期被忽視。 大多數(shù)前端的人只??知道如何開發(fā)一些 HTML 代碼和一些 CSS。 前端幾乎沒有自己完整的開發(fā)架構(gòu)，甚至一些前端開發(fā)工作都是由后端自己完成的。 但是，隨著整個互聯(lián)網(wǎng)環(huán)境的不斷快速發(fā)展，對后臺系統(tǒng)設(shè)計的性能要求會變得非常高，軟件系統(tǒng)構(gòu)建的相對復(fù)雜度、程度和規(guī)模也會越來越大。 如果仍然使用傳統(tǒng)的前端耦合方式，將會出現(xiàn)大量的重復(fù)代碼。 當(dāng)某個特定的功能模塊需要修改時，前端代碼和后端代碼都需要再次修改，這使得模塊代碼的管理更加困難，系統(tǒng)后期的維護(hù)也是比較麻煩。

一、前后端分離框架在軟件設(shè)計中發(fā)展過程

1.1傳統(tǒng)發(fā)展模式

隨著互聯(lián)網(wǎng)在全球的快速發(fā)展，長期以來，軟件網(wǎng)站的發(fā)展模式基本上是基于傳統(tǒng)網(wǎng)站的發(fā)展模式。其核心特點是首先由語言提供的模板自動生成HTML頁面，然后前端服務(wù)器將自動生成的頁面信息返回并傳輸給瀏覽器，呈現(xiàn)給網(wǎng)站用戶。以Java語言編寫為例，在這種傳統(tǒng)的開發(fā)模式下，JSP可以作為動態(tài)模板引擎。JSP通過使用包含在Java語言代碼或HTML代碼模板中的特定標(biāo)記集來封裝動態(tài)邏輯。當(dāng)客戶機請求訪問JSP頁面時，服務(wù)器需要將這些JSP請求編譯成動態(tài)Servlet文件，并自動執(zhí)行這些文件。這樣的好處是開發(fā)效率高。但由于JSP開發(fā)中嵌入的Java代碼會使與前端邏輯的耦合更加嚴(yán)重，導(dǎo)致后期維護(hù)頁面時前端人員需要一些JSP，增加了程序員的學(xué)習(xí)成本，項目開發(fā)完成后后臺維護(hù)也不方便。

1.2 Ajax

使用Ajax后，頁面數(shù)據(jù)內(nèi)容的實時更新將不需要刷新到整個頁面，只需要提供從后臺返回頁面數(shù)據(jù)信息的API即可。在前端，可以嘗試通過Ajax調(diào)用API來添加、刪除和檢查系統(tǒng)數(shù)據(jù)。請求的調(diào)用放在前端，后端開發(fā)者不需要特別關(guān)注頁面，只需要提供一些符合要求的API調(diào)用即可。前端開發(fā)人員通常只在需要之前根據(jù)后端開發(fā)提供的API自動獲取相關(guān)數(shù)據(jù)，從而在一定程度上實現(xiàn)了前端開發(fā)和后端設(shè)計的完全解耦。

1.3前后端分離框架

隨著現(xiàn)代互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，當(dāng)前需要服務(wù)器處理代碼的Web項目的業(yè)務(wù)場景將與過去有很大不同。以前我們只是把代碼庫和數(shù)據(jù)庫放在同一個服務(wù)器平臺上，所有應(yīng)用的服務(wù)器壓力由同一個服務(wù)器承擔(dān)。但目前，互聯(lián)網(wǎng)各大應(yīng)用網(wǎng)站的應(yīng)用訪問量每天都在大幅增長。如果所有的應(yīng)用程序都放在一個服務(wù)器平臺上，這將很容易使整個服務(wù)器崩潰。為了快速解決這種復(fù)雜性問題，現(xiàn)在許多系統(tǒng)工程師可以使用集群部署或分布式部署模式，將任何項目集中部署到多個分布式服務(wù)器環(huán)境中，或者將其細(xì)分為許多子項目。當(dāng)向一個用戶系統(tǒng)發(fā)送請求時，一個系統(tǒng)請求的整個過程可能要分別經(jīng)過很多分布式服務(wù)器，也會出現(xiàn)很多跨局部區(qū)域并發(fā)請求的復(fù)雜性問題。如果一個子項目系統(tǒng)的前后耦合度非常高，那么子系統(tǒng)請求的并發(fā)復(fù)雜度必然會增加。要有效解決這種尷尬局面，前后端分離將成為必然的發(fā)展趨勢。

二、前后端分離框架設(shè)計在軟件設(shè)計框架中的應(yīng)用

2.1數(shù)據(jù)安全注意事項

因為一個常規(guī)Web項目的前端無論如何都要通過公網(wǎng)訪問后端API，后端API暴露在外網(wǎng)，帶來很多隱患。為了防止數(shù)據(jù)被外部調(diào)用，導(dǎo)致數(shù)據(jù)泄露（比如被爬蟲獲?。?，前后端分離的接口可以添加Token作為參數(shù)（比如釘釘小程序官方接口），或者添加Cookies保證接口的訪問權(quán)限。

2.2參數(shù)配置

對于一些在使用過程中可能發(fā)生變化的參數(shù)，比如文件路徑的前綴，盡量不要寫在前端代碼中。建議將它們寫在配置中，以便于修改。如果是移動終端，需要修改代碼，重新生成安裝包;如果是Web端，同樣如此。但是如果把配置信息寫在后端代碼的配置文件中，只需要在需要修改的時候直接在后端修改，前端不會感覺到變化，可以提高系統(tǒng)的可維護(hù)性。這也是前后端分離的一個優(yōu)點。

2.3緩存機制

在某些場景下，后端在將數(shù)據(jù)返回到前端之前會經(jīng)歷復(fù)雜的數(shù)據(jù)處理，包括從數(shù)據(jù)庫獲取數(shù)據(jù)、處理數(shù)據(jù)和重組數(shù)據(jù)結(jié)構(gòu)。如果數(shù)據(jù)量很大，就要花很多時間。

但是如果一個接口返回的數(shù)據(jù)是相對固定的，不需要每次都檢索，相對固定的信息可以記錄在緩存中。比如省/市/縣區(qū)域在數(shù)據(jù)庫中是固定的，如果每次都要搜索處理，會浪費很多時間。寫入Redis緩存可以節(jié)省大量時間，大大提高響應(yīng)速度。

2.4跨域問題處理

當(dāng)前端向后端發(fā)送POST請求時，會生成兩條請求記錄（OPTIONS和POST）。例如，如果發(fā)送POST請求“/getData?”，可以在控制臺上看到兩個具有相同URL的請求。第一個是由沒有正文和響應(yīng)的選項發(fā)送的，第二個是由POST提交的帶有參數(shù)正文和響應(yīng)的普通請求。這是實施機制的結(jié)果。當(dāng)跨域服務(wù)請求發(fā)生時，可能會先向請求者發(fā)送OPTIONS請求，確認(rèn)兩個服務(wù)器請求是否能繼續(xù)正常有效地通信，請求是否允許被接受。否則，它不會發(fā)送真正的請求。如果測試通信正常，它將開始發(fā)送真實請求。

關(guān)于這個問題，需要在后臺設(shè)置POST請求，并允許OPTIONS請求，否則POST請求會受到影響。OPTIONS請求在各種編程語言和應(yīng)用程序框架中的處理方式是不同的，所以這里不再解釋。

三、結(jié)論

在軟件設(shè)計開發(fā)系統(tǒng)中，前后端任務(wù)分離后，直接由前端和后端分別提供數(shù)據(jù)，然后由各個端負(fù)責(zé)渲染，使得項目之間的分工更加明確。在一個項目的設(shè)計開發(fā)過程中，前端和后端可以直接測試待開發(fā)的各種功能軟件的性能，最終將前端任務(wù)和后端任務(wù)連接起來，有效提高了系統(tǒng)開發(fā)的效率。但同時需要特別注意的是，國內(nèi)的前后端分離技術(shù)發(fā)展還遠(yuǎn)未成熟，前端頁面的呈現(xiàn)方式也不利于搜索引擎的優(yōu)化，所以還是要嚴(yán)格按照自己的項目需求來選擇前端的開發(fā)方式。同時，應(yīng)該嘗試更多的方式嘗試前后端分離模式，以促進(jìn)國內(nèi)前后端分離模式盡快走向成熟。