---

前言

“古来青史谁不见，今见功名胜古人。”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 的框架应用发展到后面的高阶架构解决方案和前后端分离，从最基础的技术框架到分布式架构、服务器中间件、服务器技术、容器技术以及各种业务解决方案彻底的捋了一遍，希望本文对初学者而言能够帮你开启你学习全栈的大门。待你学成归来，给我留句言吧，“吟咏流千古，声名动四夷。”

---

我是白鹿，一个不懈奋斗的程序猿。望本文能对你有所裨益，欢迎大家的一键三连！若有其他问题、建议或者补充可以留言在文章下方，感谢大家的支持！