---

前言

“古來青史誰不見，今見功名勝古人。”Java 激蕩三十年，我們一起來回顧 Java 開發的歷程。總結前人智慧，引領前進之路，本文作為 Java 全棧入門第一課，全棧工程師、Java 后端工程師面試第一課，希望能有“等閑識得東風面，萬紫千紅總是春”的效果。

---

一、軟件

1.1、何為軟件？

一系列按照特定順序組織的計算機數據和指令的集合。

1.2、計算機軟件的分類

計算機軟件分為系統軟件和應用軟件兩大類。

1.2.1、系統軟件

系統軟件是指控制和協調計算機及外部設備,支持應用軟件開發和運行的系統，是無需用戶干預的各種程序的集合，主要功能是調度，監控和維護計算機系統；負責管理計算機系統中各種獨立的硬件，使得它們可以協調工作。

系統軟件使得計算機使用者和其他軟件將計算機當作一個整體而不需要顧及到底層每個硬件是如何工作的。

比如：我們常見的一些操作系統。

1.2.2、應用軟件

應用軟件是為滿足用戶不同領域、不同問題的應用需求而提供的那部分軟件。

它可以拓寬計算機系統的應用領域，放大硬件的功能。

比如：辦公室軟件、互聯網軟件、多媒體軟件、分析軟件、協作軟件、商務軟件等。

1.3、軟件系統體系結構

軟件體系結構是具有一定形式的結構化元素，即構件的集合，包括處理構件、數據構件和連接構件。

• 處理構件負責對數據進行加工；
• 數據構件是被加工的信息；
• 連接構件把體系結構的不同部分組合連接起來。

相比較于“軟件架構”,“軟件體系結構”一詞多用于學術研究領域使用，“軟件架構”多用于工程實踐領域，二者的外文名都是“software architecture”，在 IEEE 中的定義均為：“一個系統的基礎組織，包含各個構件、構件互相之間與環境的關系，還有指導其設計和演化的原則。”

1.3.1、C/S 結構（桌面應用程序）

C/S （Client/Server）結構，即大家熟知的客戶機和服務器結構。

通過它可以充分利用兩端硬件環境的優勢，將任務合理分配到 Client 端和 Server 端來實現，降低了系統的通訊開銷。

目前大多數應用軟件系統都是 Client/Server 形式的兩層結構，在此我們就不得不提到目前在國內使用 C/S 架構的鼻祖應用——騰訊 QQ。

發展方向：由于現在的軟件應用系統正在向分布式的 Web 應用發展，Web 和 Client/Server 應用都可以進行同樣的業務處理，應用不同的模塊共享邏輯組件；因此，內部的和外部的用戶都可以訪問新的和現有的應用系統，通過現有應用系統中的邏輯可以擴展出新的應用系統。這也就是目前應用系統的發展方向。

1.3.2、B/S 結構（Web 應用程序）

B/S（Browser/Server）結構即瀏覽器和服務器結構。它是隨著 Internet 技術的興起，對 C/S 結構的一種變化或者改進的結構。

在這種結構下，用戶工作界面是通過 WWW 瀏覽器來實現，極少部分事務邏輯在前端（Browser）實現，但是主要事務邏輯在服務器端（Server）實現，形成所謂三層結構。這樣就大大簡化了客戶端電腦載荷，減輕了系統維護與升級的成本和工作量，降低了用戶的總體成本（TCO）。

1.3.3、Web 服務器與數據庫服務器

在上面的介紹中我們說到了兩類服務器，那么這兩類服務器各是什么，有何作用呢？

Web 服務器：在 PC 機上安裝了 Web 服務的軟件，這 PC 機就是稱為 Web 服務器。
數據庫服務器：在 PC 機上安裝了數據庫管理服務軟件，這 PC 機就稱為數據庫服務器。

1.3.4、Web 應用的請求流程

我們開發 Web 應用，其請求和處理響應的流程即為下圖所示：

而我們在 Web 應用的請求流程中，對于不同形式的資源的處理也是具有明確針對性的。

1.3.5、Web 應用處理靜態資源請求

1.3.6、Web 應用處理動態資源請求

1.3.7、RIA 應用

RIA：Rich Internet Application，富網絡應用。RIA 是 Rich Internet Applications 的縮寫，翻譯成中文為富因特網應用程序（Macromedia 中文網站翻譯為 Rich Internet 應用程序）。

傳統網絡程序的開發是基于頁面的、服務器端數據傳遞的模式，把網絡程序的表示層建立于 HTML 頁面之上，而 HTML 是適合于文本的，傳統的基于頁面的系統已經漸漸不能滿足網絡瀏覽者的更高的、全方位的體驗要求了，這就是被 Macromedia 公司稱之為的“體驗問題”（“Experience Matters”），而富因特網應用程序（Rich Internet Applications，縮寫為 RIA）的出現也就是為了解決這個問題。

RIA（Rich Internet Application，富互聯網應用系統）技術允許我們在因特網上以一種像使用 Web 一樣簡單的方式來部署富客戶端程序。這是一個用戶接口，它比用 HTML 能實現的接口更加健壯、反應更加靈敏和更具有令人感興趣的可視化特性。無論將來 RIA 是否能夠如人們所猜測的那樣完全代替 HTML 應用系統，對于那些采用胖客戶端技術運行復雜應用系統的機構來說，RIA 確實提供了一種廉價的選擇。

1.3.8、APP

對于 APP 的發展整體我們可以將其分為 4 個階段，如下圖所示：

從早期的單服務原生 APP 和 Web APP 到現在微信等第三方軟件集成的小程序再到三者均有的混合多服務 APP，技術的發展在不斷地適應市場的發展與消費者的需求。

二、基于 Web 的軟件開發

2.1、B/S 架構工作原理

在 Java 這樣的跨平臺語言出現之后，B/S 架構管理軟件更是方便、快捷、高效。

我們在此對基于 Web 的軟件開發 B/S 架構工作原理進行深度剖析：

以目前的技術看，局域網建立 B/S 結構的網絡應用，并通過 Internet/Intranet 模式下數據庫應用，相對易于把握、成本也是較低的。它是一次性到位的開發，能實現不同的人員，從不同的地點，以不同的接入方式（比如 LAN, WAN, Internet/Intranet 等）訪問和操作共同的數據庫；它能有效地保護數據平臺和管理訪問權限，服務器數據庫也很安全 。

2.2、網絡游戲架構圖

對于網絡游戲而言，作為廣大用戶我們良好的體驗性是處于第一位的。

首先想到的就是游戲要實時交互，畫面的同步實時性更高。畫面要不卡頓、低延遲。

這樣的話，局內人數的限定要求、畫面、場景要求就會大大提高，同時基于的 TCP、UCP 的底層數據交互更為頻繁。這就對設備 CPU、內存和網卡等要求更為苛刻。

而游戲架構設計不合理以及架構本身存在的問題就會造成內存泄漏，導致設備 CPU 一直在高速運算，對于用戶而言，顯而易見的就是表現為手機用一段時間發熱、發燙。

“為發燒而生？”這也就是為什么廣大廠商都在擠破頭的搞芯片研發、CPU 研發的原因。

也正如我所之前在華為云社區微話題所提到的“大型聯網游戲部署在云服務上，如何在服務端大大提高 FPS，以提高玩家游戲體驗？除了 5G 技術的支持，云服務又該如何應對？”

如果有同學想涉足或者轉戰游戲開發領域，這些問題就是你要考慮和掌握的技術點。

同時，以下我所提到的游戲開發核心更需要銘記在心。

2.3、游戲開發的核心

• 游戲的設計以及內容是最重要；
• 脫離了技術，所有的都是空談；
• 程序是骨，美術是肉，而策劃是靈魂；
• 講好故事，很多人在聽，喜歡看，想體驗。

三、Java 常用框架解析

3.1、為什么使用框架？框架為何經久不息？

• Java 模塊化上的欠缺。Java 類庫雖強大，但其模塊化較為欠缺。對于數據的封裝和查詢等方面較為不足。
• 提高開發效率。傳統的 JSP+Servlet 較為臃腫，而框架使用輕巧的同時查詢的效率更高。
• 提升性能。直接使用底層語言進行開發，若開發者經驗不足，無法全面考慮到可能存在的問題以及問題該如何解決。比如我們老生常談的內存泄漏，GC 處理的問題，而使用框架把這些流程已經完善，開發者只需要去專注系統與應用的業務流程即可。
• 解決具體問題。框架可以解決掉較為簡單的邏輯結構。例如使用 Shiro 直接就可以實現登陸、注冊等功能，沒有必要多費時間重新寫一遍。

3.2、現階段流行的框架有哪些？

3.2.1、“一類經典永流傳”——SpringMVC、Spring、Mybatis

SSM 這是最為經典的三大框架，也是作為全棧工程師、Java 后端工程師必須和首要掌握的框架。

• SpringMVC——負責視圖層
• Spring——負責業務層
• Mybatis——負責數據層

3.2.2、“長江后浪推前浪”——微服務、分布式、緩存、項目管理、中間件

近年來大量新技術的迭代和更新應用到了企業級項目中。微服務、分布式、緩存、項目管理、中間件等。

• Dubbo——微服務
• Maven——良好的項目管理工具
• Log4j——日志處理
• Ehcache——處理內存緩存
• Redis——分布式緩存
• Shiro——模板快速實現登錄注冊、加密等功能

雖說“面試造火箭”，但這也是全棧工程師、Java 后端工程師面試必問知識點。

3.2.3、“好風憑借力”——腳手架的使用

• Spring Boot——可以單獨使用，集成其他框架，適用于微服務
• Spring Cloud——依賴于 Spring Boot，基于腳手架，開發者可以在開發前指定框架、數據庫等內容，適用于大項目，分布式操作

3.2.4、“送我上青云”——傳統框架的迭代使用

這就是用到了一些老的框架，比如我們之前掌握的 Struts、Struts2、Hibernate 等。

新的技術離不開老技術的核心，我們需要切實的掌握老技術，自行在開發中進行替換和迭代處理。

3.3、如何拿捏住框架的“七寸”？

說了這么多，框架換來換去，我們所謂的“軟件開發”即為數據的流轉，如下圖所示：

問：作為架構師，學習全棧內容，何時“爐火純青”？

答：當你能夠理解各層框架所處的位置及其作用并且可以靈活應用的時候就可以。

四、數據庫與數據倉庫

4.1、數據庫分類及排行榜

我們最為常見的三類關系型數據：Oracle、MySQL、Microsoft SQL Server。

以下是 2021 年 1 月，DB-engines 數據庫排名：

我們可以看到 Oracle、MySQL、Microsoft SQL Server 三大數據庫穩居榜首，分布式數據庫 Redis 趨于上升。這也側面表現出的就是大數據以及分布式的迅速發展。

4.1.1、SQL 關系型數據庫

關系型數據庫，是指采用了關系模型來組織數據的數據庫，其以行和列的形式存儲數據，以便于用戶理解，關系型數據庫這一系列的行和列被稱為表，一組表組成了數據庫。用戶通過查詢來檢索數據庫中的數據，而查詢是一個用于限定數據庫中某些區域的執行代碼。

4.1.2、NoSQL 非關系型數據庫

NoSQL，泛指非關系型的數據庫。隨著互聯網 web2.0 網站的興起，傳統的關系數據庫在處理 web2.0 網站，特別是超大規模和高并發的 SNS 類型的 web2.0 純動態網站已經顯得力不從心，出現了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL 數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，特別是大數據應用難題。

4.2、常見關系型數據庫使用技巧

我們在此總結較為常見關系型數據庫需要著重注意的幾個問題以及使用技巧。

4.2.1、關聯關系的存在

關聯關系，這個是必須的，key 與 value 之間必須具有的對應關系。

關系模型可以簡單理解為二維表格模型，而一個關系型數據庫就是由二維表及其之間的關系組成的一個數據組織。

4.2.2、主鍵和外鍵

這是唯一標識一個元組的標識。

很多企業對于外鍵可能會有額外的業務要求，比如強制外鍵，多見于金融領域，提高查詢的安全性。

4.2.3、范式和冗余

數據庫的幾范式？什么時候冗余？什么時候不冗余？

4.2.4、表列數量

在建庫的時候要控制數量，尤其注意列的數量不要太多。積極去和和項目經理進行協調。

對于大數據量進行拆表、建立主從表、進行多表查詢。盡量減少后期查詢性能低下的問題。

4.2.5、數據類型

datetime、timestamp 的使用？為什么使用這個？

4.2.6、性能優化

掌握和進行不同數據庫性能優化的技術，如進行 SQL 調優，進行查詢優化，處理方案優化等等。

4.3、如何進行數據庫性能調優？

數據庫性能調優是一個大的方向點，里面包含的內容涉及較為廣泛，以下僅提較為常見的幾種優化方式。

4.3.1、where 子句的使用

數據庫在解析 SQL 語句的時候是從后往前進行的，即 where 之后的先開始解析。
所以我們可以添加確定的篩選條件，在從后往前解析的時候提升查詢效率。

4.3.2、數字閉區間的使用

用 ≥ 等于替代 > ，用 ≤ 代替 < ，不要讓數據庫系統去判斷值的情況，使用定值，提升查詢效率。

可能在數據量小的情況下優勢不明顯，但是在海量數據的情況下，提升效率的百分比是驚人的。

4.3.3、少用 in exists

進行聯合查詢，用 left/right join 來實現替代。

4.3.4、碎片問題、oracle 高水位問題

這個問題相信進行實戰開發有一段時間的同學有體會。

何為碎片問題？（oracle 高水位問題）

在業務表業務量較大，頻繁更新數據的情況下，會有個別的“碎片”長期存在于數據庫系統中不去使用，占用資源空間。
大量的碎片就會造成數據庫系統查詢效率極其低下。即“一棵大樹，葉子沒了，樹枝還在”。葉子都沒了要樹枝干啥？
我們要及時清理碎片，這也就是 oracle 的高水位問題。對于碎片處理，不同的數據庫系統有不同的調優方案。

4.3.5、建立索引要謹慎

建立數據庫索引要謹慎，盡量建立復合索引（可以覆蓋單個索引）。

索引過多會影響查詢速度，這也就是我們上面所提到的樹枝和葉子的問題，索引就是樹枝。

4.3.6、日期的處理

在期比較中，盡可能不要用函數包裹字段，避免失效。

將日期變成時間戳，使用毫秒數進行比較，如下圖所示，效果顯而易見：

4.4、數據庫倉庫與大數據有何關聯？

4.4.1、數據庫

傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理。
例如：銀行交易，事務量較小，增刪改查量均等。

這類業務數據庫大多是進行讀寫優化的，對于偏重大量數據的讀是支持不足的。

4.4.2、數據倉庫

數據倉庫的主要應用是 OLAP（On-Line Analytical Processing），支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果。它的發展就如大數據的 Hive。

數據倉庫的數據結構是為了分析和查詢的便利。只讀優化的數據庫，屬于分析性數據庫。
例如：超市分析顧客群體的購物習慣，進行活動針對促銷，只需要從購物者群里讀數據和分析數據即可。

4.5、服務器架構演變解析

4.5.1、單節點

單節點 Web 服務器（Web 中間件）與數據庫服務器在一臺主機上。

優勢：成本低。
缺點：服務器一出問題，應用直接掛掉；不支持高并發量，大量數據的情況下造成硬盤 IO 開銷過大。

演變優化：分離單節點 Web 服務器。Web 服務器與數據庫服務器各自在一臺主機上。

4.5.2、分布式

多臺 Web 服務器，多臺數據庫服務器 。在服務中同時添加緩存。

注意：對于內存池的配比要適當，過大造成浪費，過小無法支撐服務。

演變優化：趨于多層分布式 ，在服務過程中添加代理服務器、緩存服務器等其他部件。

4.4.3、微服務

微服務即為“打亂分布式”，在具體服務過程中添加代理服務器、注冊中心、多個多種微服務服務器、接口。

服務關聯注冊中心，根據不同請求去調用不同接口的功能，同時添加第三方服務等。現在多為多點分布式，比如我們熟知淘寶、京東。

備注：gateway（分發）注冊中心。

注意：架構師要選擇適合業務場景的架構。雖然微服務易于開發和維護，但是成本比較高，適合變化不大的需求場景，資金雄厚的公司。因為可能某一個微服務端口出問題，其他配套的上百個端口就需要二次運維（保證、測試等），成本很高。

五、新一代前后端分離

5.1、前后端分離知多少？

• MVVM——Model-View-ViewModel
• MVC——Model-View-Controller

View 層是視圖，Model 層是業務邏輯，Controller 層用來調度 View 層和 Model 層，ViewModel 和 Controller 可以理解為 Model 和 View 的處理器。

前后端分離的架構模式從我們熟知的 MVC 發展到 MVVM。MVC 中 Controller 演變成 MVVM 中的 viewModel。MVVM 主要解決了 MVC 中大量的 DOM 操作使頁面渲染性能降低，加載速度變慢，影響用戶體驗。和當 Model 頻繁發生變化，開發者需要主動更新到 View 。

5.2、內容展示和業務邏輯的分離

最初的前后端分離就是我們下面所看到的，前端負責頁面，負責發送請求。后端負責處理請求和響應。

5.3、前端業務和后端業務的分離

而現在絕大多數使用的前后端分離多為前臺僅負責前臺，使用后端提供的統一的API調用數據進行顯示即可。

后端處理好業務邏輯，將數據封裝好響應給前臺即可。

5.3.1、優勢

大大減輕了應用服務器壓力。很多數據在前臺就已經檢驗完成，同時靜態文件有專屬的服務器，無需多次請求應用服務器。后端將全部數據封裝在對象中，通過統一 API 給前臺 URL和參數信息，處理好邏輯，從對應 DB 取數據即可。極大的提升了開發效率。

5.3.2、應用

現在大型企業開發多使用第二種模式。敏捷開發、快速迭代，可能在業務剛談好，后端的數據邏輯就提前做好了，只需要前端調用顯示即可。

5.3.3、存在的挑戰

兩頭的完美配合這就要求前端人員需要懂后端開發，了解如何取后端的數據。

各行各業都是缺高手的，既要求能夠讀懂整體業務，又能做到分庫分表。

5.4、越分越簡單還是越復雜？

對于前后端分離不同模式的選擇要看不同的業務領域，里面所考慮的因素是全面的。

對于企業和老板而言：資金是挑戰，老板需要對產品線投入合理的資金。資金多多益善，但是少了不能維持開發。
對于技術層面和架構師而言：架構師要在技術權衡之后根據項目選擇合適的模式。

---

總結

“滾滾長江東逝水,浪花淘盡英雄。”全棧學習若想達到爐火純青的境地所投入成本是巨大的，經驗的積累和同化少則兩三年，多則數十年。Java 激蕩三十年，本文給大家從一開始 Java 的框架應用發展到后面的高階架構解決方案和前后端分離，從最基礎的技術框架到分布式架構、服務器中間件、服務器技術、容器技術以及各種業務解決方案徹底的捋了一遍，希望本文對初學者而言能夠幫你開啟你學習全棧的大門。待你學成歸來，給我留句言吧，“吟詠流千古，聲名動四夷。”

---

我是白鹿，一個不懈奮斗的程序猿。望本文能對你有所裨益，歡迎大家的一鍵三連！若有其他問題、建議或者補充可以留言在文章下方，感謝大家的支持！