WEB開發還有前途嗎？

想了想,仍是先畫一系列的圖,再來解釋一下什麼是WEB開發.

 

 

第一層 入門介紹圖

適合:剛入門互聯網,沒多少基礎知識和專業知識.

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

對於大多數剛剛接觸到互聯網這個職業的人來講,對於軟件是怎麼編寫的,大概的職業是怎麼劃分的,理解到這個程度就夠了.

 

整個系統架構能夠分紅三層(分層是碼農必備思惟).

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

 

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

什麼叫作輸入呢?鍵盤,鼠標,聲音,圖像等等都是輸入,最簡單的輸入就是鍵盤和鼠標,大家若是看過各類黑客電影,無論是在鍵盤上啪啪啪,仍是在空氣中點點點,都是輸入.

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

 

叫展現層的緣由,是由於大部分的狀況下,都是用戶只須要看,少部分纔是操做.

因此一般是用展現層來代指用戶的輸入輸出層.

 

爲何要分層?

其實最先在互聯網沒有出現以前,分層是一個相對而言,軟件設計裏的概念.可是在如今,就很簡單了,你能夠理解爲,在你的手機,電腦,智能手環上運行的,都是展現層.

 

在過去,單機軟件的時代,你能夠簡單理解爲它不是分層的(雖然在系統的內部依然有層次的劃分).

而在聯網的時代,全部的數據和交互都是由雲端的服務器來存儲和處理.

 

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

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

 

這樣可否理解清楚一點?

因此從簡單的意義上來講,前端就是指的用戶這一端,後端就是指的服務器這一端,也是雲端.

什麼叫作服務器呢?

 

你在家裏看到的電腦叫PC, PC通常而言,都是配置比較低,給我的使用.

除了PC還有小型機,大型機等等,這種服務器不是你如今看到的樣子,而是這種.

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

 

 

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

"不,您不能夠在公司的電腦是複製,在家裏的電腦上粘貼.多貴的電腦都不行"

 

但是如今真不是什麼問題了,這就是最近幾年雲的價值,不少軟件都改爲Sass平臺,或者是App這種應用,或者是多端統一.

數據放在雲端,才能夠作到多端統一,不須要本地存儲.

 

雲端的電腦就叫作服務器,業務層和持久層,就是在雲端.

這也是先後端區分的重要區別,不是以語言來區分前端和後端,而是看程序是運行在用戶端,仍是運行在雲端.在用戶端的,就是前端,在雲端的,就是後端.

 

這個概念區分了之後,咱們再來看看,爲何以前叫WEB應用,和如今的前端又有什麼區別.

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

如今已經好久沒人提到了.

 

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

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

 

靜態網頁就是隻有Html(不考慮JS),內容是在Html裏寫死的.通常都用於不常常修改的部分,好比說關於咱們,公司介紹之類的,每個網頁都有本身的獨有設計,很差統一,也不常常修改,沒有必要作成動態.

動態網頁就是指,頁面的框架一致,可是內空不一樣,好比說知乎的我的主頁,結構是類似的,可是不一樣的人看到的數據不同.這就是經過前端傳過來的用戶ID,去後端取數據的過程.

 

以前的動態網頁,把數據變成Html的這個過程,是在服務器端完成的,我把它稱之爲渲染,由於這個術語,還有人說我不懂Http,說渲染就是瀏覽器作的事兒.

這也是在過去,不少老的工程師,後端和前端一塊寫的緣由,也是不少全菜工程師的來源.

 

因此那個時候,說到WEB工程師,其實在某種程度上,就是跟CS工程師作區分而來的.你想要作一個WEB程序,你大概要懂數據庫,要能讀寫,還要能展現給用戶.

即便在如今,在傳統行業中也會有不少人這麼作,外包公司和二三線城市很是常見.

 

 

因此題主的原話是這樣的

"目前正在學習JAVA WEB開發（主要後臺，有時間也會學習前端）。"
這裏其實就是指的是傳統意義上的WEB開發,前端後端都包括,這個方向,嚴格意義上來講,不屬於互聯網,更多的見於企業軟件,銀行,證券,學校.

一般沒有產品經理,只有項目經理,每個工程師,比技術更重要的每每是業務知識.

 

醫療和財務也常常有這種,OA和稅務其實挺常見的.所以,站在這個角度上,題主的描述沒有什麼大的問題.

 

固然這裏還有一個錯誤的術語使用,就是後臺.確切的來講,應該叫後端.

後端是指運行在雲端的代碼.

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

 

前臺是指外部用戶使用的系統.

後臺是指公司內部使用的系統.

 

這是正確的描述方式.所以,題主應該是指作後端,也就是Java,可是同時也會寫一些前端代碼,JS和CSS這些.

 

 

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

如今的App這麼多,小程序這麼火,WEB開發是否是就沒什麼價值了?

答案固然是錯的.

 

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

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

而如今,SPA的天下,把靜態網頁變成動態網頁,是由瀏覽器端完成的.

 

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

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

如今被原來當成是前端和後端的標準訪問方式.

 

App實際上是脫胎在於原有的CS架構,在CS架構中,過去是經過WEBService等傳輸數據,用XML來描述,而在如今,多半是用Json.

而手機端,Android和Ipone,其實就是兩臺小小計算機,手機手機,如今能夠理解爲就是拿在手裏的計算機.

 

因此Android和Iphone理所固然的選擇了用Http的方式,用Json格式來向後端傳輸數據.

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

 

 

畫個圖用了13分鐘.

 

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

　那麼Andriod和IOS是什麼樣子的呢？他們理論上來說和CS架構是等同的.因此他們是這樣的.

 

 

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

看到客戶端和服務器端之間的差異了麼?

 

靜態頁面,素材,代碼是提早安裝在用戶手機上的.在Android是就是APK,在IOS上就是IPA.爲何客戶端的用戶體驗比在網頁端好,就在於客戶是須要你先安裝,在安裝的時候,把一些模板和素材提早下載到本地,和後端的通訊,只獲取數據就好.

 

這直接致使了移動移動的流行,很早以前智能手機就能夠訪問網頁,可是網頁作不到這種流暢的體驗,緣由就在因而,每打開一次網頁,都須要加載一次資源,代碼,樣式等等,而在過去4G尚未那麼流暢,手機的內存和CPU沒有那麼大和快的時候,瀏覽器的應用體驗不好,基本上是不可用的狀態.

 

如今呢?你其實很難感知到,你的手機和雲端一直相連.

 

因此這個時候的後端工程師作什麼呢?

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

 

二者之間的差異,就在因而過去須要在服務器端用模板技術,把靜態網頁變成動態網頁.

而如今,須要生成JSON的數據接口,不用再關心頁面如何跳轉.

 

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

其實跟沒減輕相差很少,由於一旦到了雲端,後端的主要工做,實際上是在架構方面.這個等下,我仍是會圖來表示一下.

 

咱們先接着往下看,看看WEB怎麼改變這種被App不斷蠶食的狀態.

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

 

移動時代造就了不少英雄,性能和用戶體驗是必不可少的環節.

而WEB可不能夠和Android和IOS同樣,也可以提早把資源加載到本地,提早把代碼放到本地,和後端只經過數據接口來通訊?

 

 

答案固然是能夠的.Manifest+Ajax就是解決這個問題的好方案.

Manifest可讓瀏覽器離線使用網頁,因此,理論上來說,你的網頁也只須要讓用戶加載第一次.經過版本號來判斷是否須要更新本地的文件.再經過Ajax獲取數據,就能夠實現和App同樣的功能.

畫成圖多是這個樣子的.

 

 

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

 

因此再回過頭來看題主的問題.

 

感受如今不少WEB網站都只是展現性的，用戶主要活躍在移動APP上。不知道如今WEB開發還有什麼應用的前景？
 

由於題主以前說了,本身主要是作後臺(Java),=>其實應該是本身主作後端,也會寫一點JS.

那麼從如今的結構圖上來看,所謂的用戶活躍在移動App上,對後端人員的影響有多大呢?

 

 

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

2.在SPA的使用場景下,後端人員的職責減輕,和App端同樣,也是隻須要提供數據接口.

 

這表明什麼含義?表明後端很開心啊,原本後端的職責就是架構的穩定和可擴容性,業務邏輯什麼的都是小菜,負責前端展現也不是後端這幫悶騷男的High點.

 

因此用戶活躍在App上,對後端人員的影響就是,把一些本來不想專一,也不肯意專一的技術棧移走了,繼續專一於本身的架構穩定上.

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

 

咱們等會再看一下,後端倒底是什麼樣的.你就會明白,爲何說移動App的發展,包括SPA的發展,以及小程序的發展,不但不會對後端有衝擊,反而讓後端的地位更穩重.

 

 

第二層,初級架構圖,系統若只如初建,寫什麼架構來現眼.

一切一切的開端,都來自於互聯網的用戶壓力.

 

若是沒有來自用戶訪問的壓力,那麼後端的世界就太簡單了.

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

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

而持久層呢,一般是用數據庫,而數據最經常使用的仍是關係數據庫,在關係數據庫中,最多見的是Mysql.

 

Mysql自己是不提供Json接口的,因此纔會出來ORM這種東西,把數據庫中的表結構變成Java裏的Model,再進一步拼裝成Json數據.

 

Mysql靠什麼和業務層交互呢?靠Sql語句.

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

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

 

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

不少數據我均可以經過Sql語句,讓Mysql來幫我實現了~~

 

若是你有機會看到不少外包團隊的代碼,你會發現他們的特色就是,Java作爲中間件,幾乎不作任何的業務邏輯處理,寫代碼的套路就是先設計表結構,再寫一堆Sql語句,而後Java只是作爲一箇中間件把SqL語句的結果,傳達給前端而已.幾乎沒有什麼業務邏輯.

 

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

他的壞處在哪裏呢?

 

很差調試,這是問題之一,可是很差調試並非不能調試,忍一忍還能過去.

性能很差,這是問題之二.

 

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

Mysql自己,並非爲了支持高併發的性能而出現的,他提供的各類複雜的Sql語法,也很難在性能上達標.

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

 

各類Sql優化的核心也就是怎麼樣多利用Mysql的索引.

可是SQL的優化老是有瓶頸的.這種瓶頸體如今兩個地方.

 

一個是複雜的Sql語句執行的速度很是慢,有可能幾十秒.

另外一個是一旦併發到200以上或者更高,Mysql就會搞不定.

 

像淘寶雙11這種訪問量,單純靠Mysql能夠麼?

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

 

包括讀寫分離等.可是不管哪一種解決方案,其實給咱們的思考就是,有沒有一種比較簡單的方式,可以承擔起用戶的高併發,而且擴展性好,又足夠的穩定?

 

這時候有兩種方案誕生.

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

一種是緩存.

 

緩存是出如今KV數據庫以前的,若是我沒記錯的話.

什麼叫緩存呢?

 

Mysql本身有緩存.

舉個例子,在修真院的課程體系中,全部的職業都有15個任務,每一個任務都有任務詳情,操做步驟.

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

 

網絡傳輸啊,併發請求啊仍是會讓Mysql搞不定大併發的場景.

怎麼解決?

我可不能夠在Java的虛擬機裏,把取過來的任務數據所有用對象存儲?

 

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

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

 

這個時候若是有併發請求,我會懼怕麼?

根本不怕~~

 

並且我徹底能夠作負載均衡啊.理論上來講,若是隻是請求這麼一個任務列表的話,這種方式就足夠了.

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

 

因此,畫成圖,應該是這樣的.