App下載

Java后端程序員都做些什么?

猿友 2021-02-06 14:15:17 瀏覽數(shù) (2744)
反饋

我剛開始做 Web 開發(fā)的時候,根本沒有前端,后端之說。

原因很簡單,那個時候服務(wù)器端的代碼就是一切:接受瀏覽器的請求,實現(xiàn)業(yè)務(wù)邏輯,訪問數(shù)據(jù)庫,用 JSP 生成 HTML,然后發(fā)送給瀏覽器。

即使后來 Javascript 在瀏覽器中添加了一些 AJAX 的效果,那也是錦上添花,絕對不敢造次。因為頁面的 HTML 主要還是用所謂“套模板”的方式生成:美工生成 HTML 模板,程序員用 JSP,Veloctiy,FreeMaker 等技術(shù)把動態(tài)的內(nèi)容添加上去,僅此而已。

那個時候最流行的圖是這個樣子:
微信截圖_20210206094842

在最初的 J2EE 體系中,這個表示層可不僅僅是瀏覽器中運行的頁面,還包括 Java 寫的桌面端,只是 Java 在桌面端太不爭氣, 沒有發(fā)展起來。

每個程序員都是所謂“全?!惫こ處?,不僅要搞定 HTML, JavaScript, CSS,還要實現(xiàn)業(yè)務(wù)邏輯,編寫訪問數(shù)據(jù)庫的代碼。等到部署的時候,就把所有的代碼打成一個 WAR 包,往 Tomcat 指定的目錄一扔,測試一下沒問題,收工回家!

不差錢的公司會把程序部署到 Weblogic,Websphere 這樣的應(yīng)用服務(wù)器中,還會用上高大上的 EJB。

雖然看起來生活“簡單”又“愜意”,但實際上也需要實現(xiàn)那些多變的、不講邏輯的業(yè)務(wù)需求,苦逼的本質(zhì)并沒有改變。

1. 前后端的分離

隨著大家對瀏覽器頁面的視覺和交互要求越來越高,“套模板”的方式漸漸無法滿足要求,這個所謂的表示層慢慢地遷移到瀏覽器當中去了,一大批像 Angular, ReactJS 之類的框架崛起,前后端分離了!

后端的工程師只負責提供接口和數(shù)據(jù),專注于業(yè)務(wù)邏輯的實現(xiàn),前端取到數(shù)據(jù)后在瀏覽器中展示,各司其職。

像 Java 這樣的語言很適合去實現(xiàn)復(fù)雜的業(yè)務(wù)邏輯,尤其是一些 MIS 系統(tǒng),行業(yè)軟件如稅務(wù)、電力、煙草、金融,通信等等。  所以剝離表示層,只做后端挺合適的。 

但是如果僅僅是實現(xiàn)業(yè)務(wù)邏輯,那后端也不會需要這么多技術(shù)了,搞定 SSH/SSM 就行了。 

2. 后端技術(shù)

互聯(lián)網(wǎng),尤其是移動互聯(lián)網(wǎng)開始興起以后,海量的用戶呼嘯而來,一個單機部署的小小 War 包肯定是撐不住了,必須得做分布式。 

原來的單個 Tomcat 得變成 Tomcat 的集群,前邊弄個 Web 服務(wù)器做請求的負載均衡,不僅如此,還得考慮狀態(tài)問題,session 的一致性。

業(yè)務(wù)越來越復(fù)雜,我們不得不把某些業(yè)務(wù)放到一個機器(或集群)上,把另外一部分業(yè)務(wù)放到另外一個機器(或集群)上,雖然系統(tǒng)的計算能力,處理能力大大增強,但是這些系統(tǒng)之間的通信就變成了頭疼的問題,消息隊列(MQ),RPC框架(如Dubbo)應(yīng)運而生,為了提高通信效率,各種序列化的工具(如Protobuf)也爭先空后地問世。

單個數(shù)據(jù)庫也撐不住了,那就做數(shù)據(jù)庫的讀寫分離,如果還不行,就做分庫和分表,把原有的數(shù)據(jù)庫垂直地切一切,或者水平地切一切, 但不管怎么切,都會讓應(yīng)用程序的訪問非常麻煩,因為數(shù)據(jù)要跨庫做 Join/ 排序,還需要事務(wù),為了解決這個問題,又有各種各樣“數(shù)據(jù)訪問中間件”的工具和產(chǎn)品誕生。

為了最大程度地提高性能,緩存肯定少不了,可以在本機做緩存(如Ehcache),也可以做分布式緩存(如Redis),如何搞數(shù)據(jù)分片,數(shù)據(jù)遷移,失效轉(zhuǎn)移,這又是一個超級大的主題了。

互聯(lián)網(wǎng)用戶喜歡上傳圖片和文件,還得搞一個分布式的文件系統(tǒng)(如FastDFS),要求高可用,高可靠。

數(shù)據(jù)量大了,搜索的需求就自然而然地浮出水面,你得弄一個支持全文索引的搜索引擎(如Elasticsearch ,Solr)出來。

林子大了,什么鳥都有,必須得考慮安全,數(shù)據(jù)的加密/解密,簽名、證書,防止 SQL 注入,XSS/CSRF 等各種攻擊。

3. “大后端”

前面提到了這么多的系統(tǒng),還都是分布式的,每次上線,運維的同學(xué)說:把這么多系統(tǒng)協(xié)調(diào)好,把老子都累死了。

得把持續(xù)集成做好,能自動化地部署,自動化測試(其實前端也是如此),后來出現(xiàn)了一個革命化的技術(shù) docker, 能夠讓開發(fā)、測試、生成環(huán)境保持一致,系統(tǒng)原來只是在環(huán)境(如Ngnix, JVM,Tomcat,MySQL等)上部署代碼,現(xiàn)在把代碼和環(huán)境一并打包, 運維的工作一下子就簡化了。

公司自己購買服務(wù)器比較貴,維護也很麻煩,又難于彈性地增長,那就搞點虛擬的服務(wù)器吧,硬盤、內(nèi)存都可以動態(tài)擴展(反正是虛擬的), 訪問量大的時候多用點,沒啥訪問量了就釋放一點,按需分配,很方便,這就是云計算的一個場景。

隨著時間的推移,各個公司和系統(tǒng)收集的數(shù)據(jù)越來越多,都堆成一座大山了,難道就放在那里白白地浪費硬盤空間嗎?

有人就驚奇地發(fā)現(xiàn),咦,我們利用這些數(shù)據(jù)搞點事情啊, 比如把數(shù)據(jù)好好分析一下,預(yù)測一下這個用戶的購買/閱讀/瀏覽習(xí)慣,給他推薦一點東西嘛。

可是這么多數(shù)據(jù),用傳統(tǒng)的方式計算好幾天甚至好幾個月才能出個結(jié)果,到時候黃花菜都涼了,所以也得利用分布式的技術(shù),想辦法把計算分到各個計算機去,然后再把計算結(jié)果收回來, 時勢造英雄,Hadoop 及其生態(tài)系統(tǒng)就應(yīng)運而生了。

之前聽說過一個大前端的概念,把移動端和網(wǎng)頁端都歸結(jié)為“前端”,我這里造個詞“大后端”,把那些用戶直接接觸不到的、發(fā)生在服務(wù)器端的都歸結(jié)進來。

4. 怎么學(xué)?

現(xiàn)在無論是前端還是后端,技術(shù)領(lǐng)域多如牛毛,都嚴重地細分了,所以我認為真正的全棧工程師根本不存在,因為一個人精力有限,不可能搞定這么多技術(shù)領(lǐng)域,太難了。

培訓(xùn)機構(gòu)所說的“全?!?,我認為就是前后端還在拉拉扯扯,藕斷絲連,沒有徹底分離的時候的“全?!惫こ處?。

那么問題來了, 后端這么多東西,我該怎么學(xué)?

往深度挖掘,可以成為某個技術(shù)領(lǐng)域的專家,如搜索方面的專家、安全方面的專家,分布式文件的專家等等,不管是哪個領(lǐng)域,重點都不是學(xué)會使用某個工具和框架, 而是保證你可以自己的知識和技術(shù)去搞定這個領(lǐng)域的頂尖問題。

往廣度發(fā)展,各個技術(shù)領(lǐng)域都要了解,對于某種需求,能夠選取合適的軟件和技術(shù)架構(gòu)來實現(xiàn)它,把需求轉(zhuǎn)化成合適的技術(shù)組件,讓這些組件以合適的方式連接、部署、運行,這也需要持續(xù)地學(xué)習(xí)和不斷的經(jīng)驗積累。


0 人點贊