文章目錄

• 前言
• 一、軟件
• • 1.1、何為軟件？
  • 1.2、計算機軟件的分類
  • • 1.2.1、系統(tǒng)軟件
    • 1.2.2、應(yīng)用軟件
  • 1.3、軟件系統(tǒng)體系結(jié)構(gòu)
  • • 1.3.1、C/S 結(jié)構(gòu)（桌面應(yīng)用程序）
    • 1.3.2、B/S 結(jié)構(gòu)（Web 應(yīng)用程序）
    • 1.3.3、Web 服務(wù)器與數(shù)據(jù)庫服務(wù)器
    • 1.3.4、Web 應(yīng)用的請求流程
    • 1.3.5、Web 應(yīng)用處理靜態(tài)資源請求
    • 1.3.6、Web 應(yīng)用處理動態(tài)資源請求
    • 1.3.7、RIA 應(yīng)用
    • 1.3.8、APP
• 二、基于 Web 的軟件開發(fā)
• • 2.1、B/S 架構(gòu)工作原理
  • 2.2、網(wǎng)絡(luò)游戲架構(gòu)圖
  • 2.3、游戲開發(fā)的核心
• 三、Java 常用框架解析
• • 3.1、為什么使用框架？框架為何經(jīng)久不息？
  • 3.2、現(xiàn)階段流行的框架有哪些？
  • • 3.2.1、“一類經(jīng)典永流傳”——SpringMVC、Spring、Mybatis
    • 3.2.2、“長江后浪推前浪”——微服務(wù)、分布式、緩存、項目管理、中間件
    • 3.2.3、“好風(fēng)憑借力”——腳手架的使用
    • 3.2.4、“送我上青云”——傳統(tǒng)框架的迭代使用
  • 3.3、如何拿捏住框架的“七寸”？
• 四、數(shù)據(jù)庫與數(shù)據(jù)倉庫
• • 4.1、數(shù)據(jù)庫分類及排行榜
  • • 4.1.1、SQL 關(guān)系型數(shù)據(jù)庫
    • 4.1.2、NoSQL 非關(guān)系型數(shù)據(jù)庫
  • 4.2、常見關(guān)系型數(shù)據(jù)庫使用技巧
  • • 4.2.1、關(guān)聯(lián)關(guān)系的存在
    • 4.2.2、主鍵和外鍵
    • 4.2.3、范式和冗余
    • 4.2.4、表列數(shù)量
    • 4.2.5、數(shù)據(jù)類型
    • 4.2.6、性能優(yōu)化
  • 4.3、如何進行數(shù)據(jù)庫性能調(diào)優(yōu)？
  • • 4.3.1、where 子句的使用
    • 4.3.2、數(shù)字閉區(qū)間的使用
    • 4.3.3、少用 in exists
    • 4.3.4、碎片問題、oracle 高水位問題
    • 4.3.5、建立索引要謹慎
    • 4.3.6、日期的處理
  • 4.4、數(shù)據(jù)庫倉庫與大數(shù)據(jù)有何關(guān)聯(lián)？
  • • 4.4.1、數(shù)據(jù)庫
    • 4.4.2、數(shù)據(jù)倉庫
  • 4.5、服務(wù)器架構(gòu)演變解析
  • • 4.5.1、單節(jié)點
    • 4.5.2、分布式
    • 4.4.3、微服務(wù)
• 五、新一代前后端分離
• • 5.1、前后端分離知多少？
  • 5.2、內(nèi)容展示和業(yè)務(wù)邏輯的分離
  • 5.3、前端業(yè)務(wù)和后端業(yè)務(wù)的分離
  • • 5.3.1、優(yōu)勢
    • 5.3.2、應(yīng)用
    • 5.3.3、存在的挑戰(zhàn)
  • 5.4、越分越簡單還是越復(fù)雜？
• 總結(jié)

---

前言

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

---

一、軟件

1.1、何為軟件？

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

1.2、計算機軟件的分類

計算機軟件分為系統(tǒng)軟件和應(yīng)用軟件兩大類。

1.2.1、系統(tǒng)軟件

系統(tǒng)軟件是指控制和協(xié)調(diào)計算機及外部設(shè)備,支持應(yīng)用軟件開發(fā)和運行的系統(tǒng)，是無需用戶干預(yù)的各種程序的集合，主要功能是調(diào)度，監(jiān)控和維護計算機系統(tǒng)；負責(zé)管理計算機系統(tǒng)中各種獨立的硬件，使得它們可以協(xié)調(diào)工作。

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

比如：我們常見的一些操作系統(tǒng)。

1.2.2、應(yīng)用軟件

應(yīng)用軟件是為滿足用戶不同領(lǐng)域、不同問題的應(yīng)用需求而提供的那部分軟件。

它可以拓寬計算機系統(tǒng)的應(yīng)用領(lǐng)域，放大硬件的功能。

比如：辦公室軟件、互聯(lián)網(wǎng)軟件、多媒體軟件、分析軟件、協(xié)作軟件、商務(wù)軟件等。

1.3、軟件系統(tǒng)體系結(jié)構(gòu)

軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。

• 處理構(gòu)件負責(zé)對數(shù)據(jù)進行加工；
• 數(shù)據(jù)構(gòu)件是被加工的信息；
• 連接構(gòu)件把體系結(jié)構(gòu)的不同部分組合連接起來。

相比較于“軟件架構(gòu)”,“軟件體系結(jié)構(gòu)”一詞多用于學(xué)術(shù)研究領(lǐng)域使用，“軟件架構(gòu)”多用于工程實踐領(lǐng)域，二者的外文名都是“software architecture”，在 IEEE 中的定義均為：“一個系統(tǒng)的基礎(chǔ)組織，包含各個構(gòu)件、構(gòu)件互相之間與環(huán)境的關(guān)系，還有指導(dǎo)其設(shè)計和演化的原則。”

1.3.1、C/S 結(jié)構(gòu)（桌面應(yīng)用程序）

C/S （Client/Server）結(jié)構(gòu)，即大家熟知的客戶機和服務(wù)器結(jié)構(gòu)。

通過它可以充分利用兩端硬件環(huán)境的優(yōu)勢，將任務(wù)合理分配到 Client 端和 Server 端來實現(xiàn)，降低了系統(tǒng)的通訊開銷。

目前大多數(shù)應(yīng)用軟件系統(tǒng)都是 Client/Server 形式的兩層結(jié)構(gòu)，在此我們就不得不提到目前在國內(nèi)使用 C/S 架構(gòu)的鼻祖應(yīng)用——騰訊 QQ。

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

1.3.2、B/S 結(jié)構(gòu)（Web 應(yīng)用程序）

B/S（Browser/Server）結(jié)構(gòu)即瀏覽器和服務(wù)器結(jié)構(gòu)。它是隨著 Internet 技術(shù)的興起，對 C/S 結(jié)構(gòu)的一種變化或者改進的結(jié)構(gòu)。

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

1.3.3、Web 服務(wù)器與數(shù)據(jù)庫服務(wù)器

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

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

1.3.4、Web 應(yīng)用的請求流程

我們開發(fā) Web 應(yīng)用，其請求和處理響應(yīng)的流程即為下圖所示：

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

1.3.5、Web 應(yīng)用處理靜態(tài)資源請求

1.3.6、Web 應(yīng)用處理動態(tài)資源請求

1.3.7、RIA 應(yīng)用

RIA：Rich Internet Application，富網(wǎng)絡(luò)應(yīng)用。RIA 是 Rich Internet Applications 的縮寫，翻譯成中文為富因特網(wǎng)應(yīng)用程序（Macromedia 中文網(wǎng)站翻譯為 Rich Internet 應(yīng)用程序）。

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

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

1.3.8、APP

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

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

二、基于 Web 的軟件開發(fā)

2.1、B/S 架構(gòu)工作原理

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

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

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

2.2、網(wǎng)絡(luò)游戲架構(gòu)圖

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

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

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

而游戲架構(gòu)設(shè)計不合理以及架構(gòu)本身存在的問題就會造成內(nèi)存泄漏，導(dǎo)致設(shè)備 CPU 一直在高速運算，對于用戶而言，顯而易見的就是表現(xiàn)為手機用一段時間發(fā)熱、發(fā)燙。

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

也正如我所之前在華為云社區(qū)微話題所提到的“大型聯(lián)網(wǎng)游戲部署在云服務(wù)上，如何在服務(wù)端大大提高 FPS，以提高玩家游戲體驗？除了 5G 技術(shù)的支持，云服務(wù)又該如何應(yīng)對？”

如果有同學(xué)想涉足或者轉(zhuǎn)戰(zhàn)游戲開發(fā)領(lǐng)域，這些問題就是你要考慮和掌握的技術(shù)點。

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

2.3、游戲開發(fā)的核心

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

三、Java 常用框架解析

3.1、為什么使用框架？框架為何經(jīng)久不息？

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

3.2、現(xiàn)階段流行的框架有哪些？

3.2.1、“一類經(jīng)典永流傳”——SpringMVC、Spring、Mybatis

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

• SpringMVC——負責(zé)視圖層
• Spring——負責(zé)業(yè)務(wù)層
• Mybatis——負責(zé)數(shù)據(jù)層

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

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

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

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

3.2.3、“好風(fēng)憑借力”——腳手架的使用

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

3.2.4、“送我上青云”——傳統(tǒng)框架的迭代使用

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

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

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

說了這么多，框架換來換去，我們所謂的“軟件開發(fā)”即為數(shù)據(jù)的流轉(zhuǎn)，如下圖所示：

問：作為架構(gòu)師，學(xué)習(xí)全棧內(nèi)容，何時“爐火純青”？

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

四、數(shù)據(jù)庫與數(shù)據(jù)倉庫

4.1、數(shù)據(jù)庫分類及排行榜

我們最為常見的三類關(guān)系型數(shù)據(jù)：Oracle、MySQL、Microsoft SQL Server。

以下是 2021 年 1 月，DB-engines 數(shù)據(jù)庫排名：

我們可以看到 Oracle、MySQL、Microsoft SQL Server 三大數(shù)據(jù)庫穩(wěn)居榜首，分布式數(shù)據(jù)庫 Redis 趨于上升。這也側(cè)面表現(xiàn)出的就是大數(shù)據(jù)以及分布式的迅速發(fā)展。

4.1.1、SQL 關(guān)系型數(shù)據(jù)庫

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

4.1.2、NoSQL 非關(guān)系型數(shù)據(jù)庫

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

4.2、常見關(guān)系型數(shù)據(jù)庫使用技巧

我們在此總結(jié)較為常見關(guān)系型數(shù)據(jù)庫需要著重注意的幾個問題以及使用技巧。

4.2.1、關(guān)聯(lián)關(guān)系的存在

關(guān)聯(lián)關(guān)系，這個是必須的，key 與 value 之間必須具有的對應(yīng)關(guān)系。

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

4.2.2、主鍵和外鍵

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

很多企業(yè)對于外鍵可能會有額外的業(yè)務(wù)要求，比如強制外鍵，多見于金融領(lǐng)域，提高查詢的安全性。

4.2.3、范式和冗余

數(shù)據(jù)庫的幾范式？什么時候冗余？什么時候不冗余？

4.2.4、表列數(shù)量

在建庫的時候要控制數(shù)量，尤其注意列的數(shù)量不要太多。積極去和和項目經(jīng)理進行協(xié)調(diào)。

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

4.2.5、數(shù)據(jù)類型

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

4.2.6、性能優(yōu)化

掌握和進行不同數(shù)據(jù)庫性能優(yōu)化的技術(shù)，如進行 SQL 調(diào)優(yōu)，進行查詢優(yōu)化，處理方案優(yōu)化等等。

4.3、如何進行數(shù)據(jù)庫性能調(diào)優(yōu)？

數(shù)據(jù)庫性能調(diào)優(yōu)是一個大的方向點，里面包含的內(nèi)容涉及較為廣泛，以下僅提較為常見的幾種優(yōu)化方式。

4.3.1、where 子句的使用

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

4.3.2、數(shù)字閉區(qū)間的使用

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

可能在數(shù)據(jù)量小的情況下優(yōu)勢不明顯，但是在海量數(shù)據(jù)的情況下，提升效率的百分比是驚人的。

4.3.3、少用 in exists

進行聯(lián)合查詢，用 left/right join 來實現(xiàn)替代。

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

這個問題相信進行實戰(zhàn)開發(fā)有一段時間的同學(xué)有體會。

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

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

4.3.5、建立索引要謹慎

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

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

4.3.6、日期的處理

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

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

4.4、數(shù)據(jù)庫倉庫與大數(shù)據(jù)有何關(guān)聯(lián)？

4.4.1、數(shù)據(jù)庫

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理。
例如：銀行交易，事務(wù)量較小，增刪改查量均等。

這類業(yè)務(wù)數(shù)據(jù)庫大多是進行讀寫優(yōu)化的，對于偏重大量數(shù)據(jù)的讀是支持不足的。

4.4.2、數(shù)據(jù)倉庫

數(shù)據(jù)倉庫的主要應(yīng)用是 OLAP（On-Line Analytical Processing），支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。它的發(fā)展就如大數(shù)據(jù)的 Hive。

數(shù)據(jù)倉庫的數(shù)據(jù)結(jié)構(gòu)是為了分析和查詢的便利。只讀優(yōu)化的數(shù)據(jù)庫，屬于分析性數(shù)據(jù)庫。
例如：超市分析顧客群體的購物習(xí)慣，進行活動針對促銷，只需要從購物者群里讀數(shù)據(jù)和分析數(shù)據(jù)即可。

4.5、服務(wù)器架構(gòu)演變解析

4.5.1、單節(jié)點

單節(jié)點 Web 服務(wù)器（Web 中間件）與數(shù)據(jù)庫服務(wù)器在一臺主機上。

優(yōu)勢：成本低。
缺點：服務(wù)器一出問題，應(yīng)用直接掛掉；不支持高并發(fā)量，大量數(shù)據(jù)的情況下造成硬盤 IO 開銷過大。

演變優(yōu)化：分離單節(jié)點 Web 服務(wù)器。Web 服務(wù)器與數(shù)據(jù)庫服務(wù)器各自在一臺主機上。

4.5.2、分布式

多臺 Web 服務(wù)器，多臺數(shù)據(jù)庫服務(wù)器 。在服務(wù)中同時添加緩存。

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

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

4.4.3、微服務(wù)

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

服務(wù)關(guān)聯(lián)注冊中心，根據(jù)不同請求去調(diào)用不同接口的功能，同時添加第三方服務(wù)等。現(xiàn)在多為多點分布式，比如我們熟知淘寶、京東。

備注：gateway（分發(fā)）注冊中心。

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

五、新一代前后端分離

5.1、前后端分離知多少？

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

View 層是視圖，Model 層是業(yè)務(wù)邏輯，Controller 層用來調(diào)度 View 層和 Model 層，ViewModel 和 Controller 可以理解為 Model 和 View 的處理器。

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

5.2、內(nèi)容展示和業(yè)務(wù)邏輯的分離

最初的前后端分離就是我們下面所看到的，前端負責(zé)頁面，負責(zé)發(fā)送請求。后端負責(zé)處理請求和響應(yīng)。

5.3、前端業(yè)務(wù)和后端業(yè)務(wù)的分離

而現(xiàn)在絕大多數(shù)使用的前后端分離多為前臺僅負責(zé)前臺，使用后端提供的統(tǒng)一的API調(diào)用數(shù)據(jù)進行顯示即可。

后端處理好業(yè)務(wù)邏輯，將數(shù)據(jù)封裝好響應(yīng)給前臺即可。

5.3.1、優(yōu)勢

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

5.3.2、應(yīng)用

現(xiàn)在大型企業(yè)開發(fā)多使用第二種模式。敏捷開發(fā)、快速迭代，可能在業(yè)務(wù)剛談好，后端的數(shù)據(jù)邏輯就提前做好了，只需要前端調(diào)用顯示即可。

5.3.3、存在的挑戰(zhàn)

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

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

5.4、越分越簡單還是越復(fù)雜？

對于前后端分離不同模式的選擇要看不同的業(yè)務(wù)領(lǐng)域，里面所考慮的因素是全面的。

對于企業(yè)和老板而言：資金是挑戰(zhàn)，老板需要對產(chǎn)品線投入合理的資金。資金多多益善，但是少了不能維持開發(fā)。
對于技術(shù)層面和架構(gòu)師而言：架構(gòu)師要在技術(shù)權(quán)衡之后根據(jù)項目選擇合適的模式。

---

總結(jié)

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

---

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

總結(jié)

以上是生活随笔為你收集整理的架构师基础必备：“腹有诗书气自华”，驰骋一线大厂不是梦，抓紧收藏的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。