想了想,還是先畫一系列的圖,再來解釋一下什么是WEB開發(fā).

第一層 入門介紹圖

適合:剛入門互聯(lián)網,沒多少基礎知識和專業(yè)知識.

為嘛這個圖上傳的不清楚?算了.我也不知道

對于大多數剛剛接觸到互聯(lián)網這個職業(yè)的人來說,對于軟件是怎么編寫的,大概的職業(yè)是怎么劃分的,理解到這個程度就夠了.

整個系統(tǒng)架構可以分成三層(分層是碼農必備思維).

第一層,叫展示層,又被稱之為前端.展示層這個名字,其實有點不精確,確切的來說,應該叫用戶層,或者是輸入輸出層,或者叫用戶交互層.

它的目標很簡單,就是接受用戶的輸入,并將結果反饋給用戶.

什么叫做輸入呢?鍵盤,鼠標,聲音,圖像等等都是輸入,最簡單的輸入就是鍵盤和鼠標,你們如果看過各種黑客電影,不管是在鍵盤上啪啪啪,還是在空氣中點點點,都是輸入.

輸出就是展示出來的結果,在屏幕上就是文字動畫,在音箱就是聲音之類的.

叫展示層的原因,是因為大部分的情況下,都是用戶只需要看,少部分才是操作.

所以通常是用展示層來代指用戶的輸入輸出層.

為什么要分層?

其實最早在互聯(lián)網沒有出現(xiàn)之前,分層是一個相對而言,軟件設計里的概念.但是在現(xiàn)在,就很簡單了,你可以理解為,在你的手機,電腦,智能手環(huán)上運行的,都是展示層.

在過去,單機軟件的時代,你可以簡單理解為它不是分層的(雖然在系統(tǒng)的內部依然有層次的劃分).

而在聯(lián)網的時代,所有的數據和交互都是由云端的服務器來存儲和處理.

這個層次就很好理解了,就是一個在用戶端,一個是在云端.

所以上面的這個圖更新一下,應該就是這樣的.

這樣能否理解清楚一點?

所以從簡單的意義上來說,前端就是指的用戶這一端,后端就是指的服務器這一端,也是云端.

什么叫做服務器呢?

你在家里看到的電腦叫PC, PC一般而言,都是配置比較低,給個人使用.

除了PC還有小型機,大型機等等,這種服務器不是你現(xiàn)在看到的樣子,而是這種.

算了不找圖了,我也沒怎么見過,畢竟不經常去機房,對型號什么的也沒那么熟悉,搜"刀片服務器"就好.

在過去,有一個笑話是這么說的:

"不,您不可以在公司的電腦是復制,在家里的電腦上粘貼.多貴的電腦都不行"

可是現(xiàn)在真不是什么問題了,這就是最近幾年云的價值,很多軟件都改成Sass平臺,或者是App這種應用,或者是多端統(tǒng)一.

數據放在云端,才可以做到多端統(tǒng)一,不需要本地存儲.

云端的電腦就叫做服務器,業(yè)務層和持久層,就是在云端.

這也是前后端區(qū)分的重要區(qū)別,不是以語言來區(qū)分前端和后端,而是看程序是運行在用戶端,還是運行在云端.在用戶端的,就是前端,在云端的,就是后端.

這個概念區(qū)分了以后,我們再來看看,為什么之前叫WEB應用,和現(xiàn)在的前端又有什么區(qū)別.

在過去,沒有SPA,沒有客戶端的時候,流行兩種模式,一種叫CS架構,一種叫BS架構.

現(xiàn)在已經很久沒人提到了.

CS架構,其實指的就是桌面端,就是PC的應用軟件,一般都是用C來寫(還是C++或C#?我對C這套體系不夠熟悉,對桌面端接觸的不多.)

BS架構,指的就是網頁端.過去的網頁端,原生JS+JQuery是主流,網頁又分成兩種類型,一種叫靜態(tài)網頁,一種叫動態(tài)網頁.

靜態(tài)網頁就是只有Html(不考慮JS),內容是在Html里寫死的.一般都用于不經常修改的部分,比如說關于我們,公司介紹之類的,每一個網頁都有自己的獨有設計,不好統(tǒng)一,也不經常修改,沒有必要做成動態(tài).

動態(tài)網頁就是指,頁面的框架一致,但是內空不同,比如說知乎的個人主頁,結構是相似的,但是不同的人看到的數據不一樣.這就是通過前端傳過來的用戶ID,去后端取數據的過程.

之前的動態(tài)網頁,把數據變成Html的這個過程,是在服務器端完成的,我把它稱之為渲染,因為這個術語,還有人說我不懂Http,說渲染就是瀏覽器做的事兒.

這也是在過去,很多老的工程師,后端和前端一塊寫的原因,也是很多全菜工程師的來源.

所以那個時候,說到WEB工程師,其實在某種程度上,就是跟CS工程師做區(qū)分而來的.你想要做一個WEB程序,你大概要懂數據庫,要能讀寫,還要能展示給用戶.

即使在現(xiàn)在,在傳統(tǒng)行業(yè)中也會有很多人這么做,外包公司和二三線城市非常常見.

所以題主的原話是這樣的

"目前正在學習JAVA WEB開發(fā)（主要后臺，有時間也會學習前端）。"

這里其實就是指的是傳統(tǒng)意義上的WEB開發(fā),前端后端都包括,這個方向,嚴格意義上來說,不屬于互聯(lián)網,更多的見于企業(yè)軟件,銀行,證券,學校.

通常沒有產品經理,只有項目經理,每一個工程師,比技術更重要的往往是業(yè)務知識.

醫(yī)療和財務也經常有這種,OA和稅務其實挺常見的.因此,站在這個角度上,題主的描述沒有什么大的問題.

當然這里還有一個錯誤的術語使用,就是后臺.確切的來說,應該叫后端.

后端是指運行在云端的代碼.

前端是指運行在用戶端的代碼.

前臺是指外部用戶使用的系統(tǒng).

后臺是指公司內部使用的系統(tǒng).

這是正確的描述方式.因此,題主應該是指做后端,也就是Java,但是同時也會寫一些前端代碼,JS和CSS這些.

這個提前搞清楚了,再來說說看.

現(xiàn)在的App這么多,小程序這么火,WEB開發(fā)是不是就沒什么價值了?

答案當然是錯的.

看了上邊的圖,其實已經描述很清楚了.

在過去,把靜態(tài)網頁,變成動態(tài)網頁的過程,是由服務器端來完成的.

而現(xiàn)在,SPA的天下,把靜態(tài)網頁變成動態(tài)網頁,是由瀏覽器端完成的.

這要感謝兩個人,一個是Ajax前端,一個是App大人.

Ajax最早只是用來無刷新獲取數據,減少網絡傳輸的數據量.

現(xiàn)在被原來當成是前端和后端的標準訪問方式.

App其實是脫胎在于原有的CS架構,在CS架構中,過去是通過WEBService等傳輸數據,用XML來描述,而在現(xiàn)在,多半是用Json.

而手機端,Android和Ipone,其實就是兩臺小小計算機,手機手機,現(xiàn)在可以理解為就是拿在手里的計算機.

所以Android和Iphone理所當然的選擇了用Http的方式,用Json格式來向后端傳輸數據.

用圖來表示,就是這樣的.

畫個圖用了13分鐘.

這是過去的樣子,那個時候,說是WEB開發(fā)要學Java和JS,不算太過分.

　那么Andriod和IOS是什么樣子的呢？他們理論上來講和CS架構是等同的.所以他們是這樣的.

很好,這次只用了三分鐘.

看到客戶端和服務器端之間的差別了么?

靜態(tài)頁面,素材,代碼是提前安裝在用戶手機上的.在Android是就是APK,在IOS上就是IPA.為什么客戶端的用戶體驗比在網頁端好,就在于客戶是需要你先安裝,在安裝的時候,把一些模板和素材提前下載到本地,和后端的通信,只獲取數據就好.

這直接導致了移動移動的流行,很早之前智能手機就可以訪問網頁,但是網頁做不到這種流暢的體驗,原因就在于是,每打開一次網頁,都需要加載一次資源,代碼,樣式等等,而在過去4G還沒有那么流暢,手機的內存和CPU沒有那么大和快的時候,瀏覽器的應用體驗很差,基本上是不可用的狀態(tài).

現(xiàn)在呢?你其實很難感知到,你的手機和云端一直相連.

所以這個時候的后端工程師做什么呢?

一邊繼續(xù)提供WEB服務,一邊給Android和IOS提供數據接口.

兩者之間的差別,就在于是過去需要在服務器端用模板技術,把靜態(tài)網頁變成動態(tài)網頁.

而現(xiàn)在,需要生成JSON的數據接口,不用再關心頁面如何跳轉.

那后端的工程量是減輕了多少呢?

其實跟沒減輕相差不多,因為一旦到了云端,后端的主要工作,其實是在架構方面.這個等下,我還是會圖來表示一下.

我們先接著往下看,看看WEB怎么改變這種被App不斷蠶食的狀態(tài).

App應用增多,大量的開發(fā)人員轉向了Andriod和IOS,難道網頁就死了么?

移動時代造就了很多英雄,性能和用戶體驗是必不可少的環(huán)節(jié).

而WEB可不可以和Android和IOS一樣,也能夠提前把資源加載到本地,提前把代碼放到本地,和后端只通過數據接口來通信?

答案當然是可以的.Manifest+Ajax就是解決這個問題的好方案.

Manifest可以讓瀏覽器離線使用網頁,所以,理論上來講,你的網頁也只需要讓用戶加載第一次.通過版本號來判斷是否需要更新本地的文件.再通過Ajax獲取數據,就可以實現(xiàn)和App一樣的功能.

畫成圖可能是這個樣子的.

SPA技術的發(fā)展更是給了前端更好用的工具,完美的復用框架,只更換其中的內容,很適合網頁的結構.

所以再回過頭來看題主的問題.

感覺現(xiàn)在很多WEB網站都只是展示性的，用戶主要活躍在移動APP上。不知道現(xiàn)在WEB開發(fā)還有什么應用的前景？

因為題主之前說了,自己主要是做后臺(Java),=>其實應該是自己主做后端,也會寫一點JS.

那么從現(xiàn)在的結構圖上來看,所謂的用戶活躍在移動App上,對后端人員的影響有多大呢?

1.在Android和IOS的使用場景下,后端人員的職責減輕,不再用模板語言,將靜態(tài)網頁轉變成動態(tài)網頁,只需要提供Json數據接口.

2.在SPA的使用場景下,后端人員的職責減輕,和App端一樣,也是只需要提供數據接口.

這代表什么含義?代表后端很開心啊,本來后端的職責就是架構的穩(wěn)定和可擴容性,業(yè)務邏輯什么的都是小菜,負責前端展示也不是后端這幫悶騷男的High點.

所以用戶活躍在App上,對后端人員的影響就是,把一些原本不想專注,也不愿意專注的技術棧移走了,繼續(xù)專注于自己的架構穩(wěn)定上.

什么算后端架構呢,后端不是畫了一個增刪改查么,不就是在圖里一個方框表示么.

我們等會再看一下,后端倒底是什么樣的.你就會明白,為什么說移動App的發(fā)展,包括SPA的發(fā)展,以及小程序的發(fā)展,不但不會對后端有沖擊,反而讓后端的地位更穩(wěn)重.

第二層,初級架構圖,系統(tǒng)若只如初建,寫什么架構來現(xiàn)眼.

一切一切的開端,都來自于互聯(lián)網的用戶壓力.

如果沒有來自用戶訪問的壓力,那么后端的世界就太簡單了.

再重新回過頭來看這張圖.

在這里,業(yè)務層的一個目標就是把數據取出來,再轉換成Json數據接口給前端.

而持久層呢,通常是用數據庫,而數據最常用的還是關系數據庫,在關系數據庫中,最常見的是Mysql.

Mysql本身是不提供Json接口的,所以才會出來ORM這種東西,把數據庫中的表結構變成Java里的Model,再進一步拼裝成Json數據.

Mysql靠什么和業(yè)務層交互呢?靠Sql語句.

Sql語句定義了一套語法規(guī)則,最簡單的就是 select id from user where name = '暗滅'

這種單表查詢,意思是我要用戶名表查詢名字=暗滅的人的ID.

然而Mysql并不是單純的存取數據,它還支持多種查詢方式,還支持函數.這表示什么呢?

很多數據我都可以通過Sql語句,讓Mysql來幫我實現(xiàn)了~~

如果你有機會看到很多外包團隊的代碼,你會發(fā)現(xiàn)他們的特點就是,Java做為中間件,幾乎不做任何的業(yè)務邏輯處理,寫代碼的套路就是先設計表結構,再寫一堆Sql語句,然后Java只是做為一個中間件把SqL語句的結果,傳達給前端而已.幾乎沒有什么業(yè)務邏輯.

甚至連接口都沒有...只有一個通用的接口(這種代碼我看完之后也是醉了.)

他的壞處在哪里呢?

不好調試,這是問題之一,但是不好調試并不是不能調試,忍一忍還能過去.

性能不好,這是問題之二.

這個性能問題是致命的問題啊.

Mysql本身,并不是為了支持高并發(fā)的性能而出現(xiàn)的,他提供的各種復雜的Sql語法,也很難在性能上達標.

簡單說,Mysql在性能上的支持,最重要的就是索引.

各種Sql優(yōu)化的核心也就是怎么樣多利用Mysql的索引.

但是SQL的優(yōu)化總是有瓶頸的.這種瓶頸體現(xiàn)在兩個地方.

一個是復雜的Sql語句執(zhí)行的速度非常慢,有可能幾十秒.

另一個是一旦并發(fā)到200以上或者更高,Mysql就會搞不定.

像淘寶雙11這種訪問量,單純靠Mysql可以么?

噢,剛剛還漏說了一句,性能還可能靠分庫分表來解決一部分.

包括讀寫分離等.但是無論哪種解決方案,其實給我們的思考就是,有沒有一種比較簡單的方式,能夠承擔起用戶的高并發(fā),并且擴展性好,又足夠的穩(wěn)定?

這時候有兩種方案誕生.

一種是找到關系數據庫的弱點,直接升級為Kev-Value數據庫,又被稱之為NoSql數據庫.

一種是緩存.

緩存是出現(xiàn)在KV數據庫之前的,如果我沒記錯的話.

什么叫緩存呢?

Mysql自己有緩存.

舉個例子,在修真院的課程體系中,所有的職業(yè)都有15個任務,每個任務都有任務詳情,操作步驟.

如果我查詢的是Java的任務體系,我會訪問數據庫.

網絡傳輸啊,并發(fā)請求啊還是會讓Mysql搞不定大并發(fā)的場景.

怎么解決?

我可不可以在Java的虛擬機里,把取過來的任務數據全部用對象存儲?

很簡單啊,一個Map<Long,List<Task>> id_taskList 就搞定了.

前端來請求的時候,只要是告訴我ID,我就從id_taskList里去,根本不用去訪問數據庫.

這個時候如果有并發(fā)請求,我會害怕么?

根本不怕~~

而且我完全可以做負載均衡啊.理論上來說,如果只是請求這么一個任務列表的話,這種方式就足夠了.

具體單機能扛多少壓力,可以去試一下.TPS在1000應該問題不大.