第一章：服务器和客户端的概念

1.1 概述

1.2 客户端

1.2.1 作用

• 客户端：和用户进行交互，用于接收用户的输入（操作）、展示服务器端的数据以及向服务器传送数据。

1.2.2 常见的客户端

• PC端网页：

• 移动端：

• lot（物联网）设备：

1.3 服务器

1.3.1 作用

• 服务器：和客户端进行交互，接收客户端的数据、处理具体的业务逻辑、传递给客户端需要的数据。

1.3.2 概念

• 从硬件而言：服务器是计算机的一种，它比普通的计算机（PC）运行更快、负载更高、价格更贵，服务区在网络中为其它客户机（如：PC机、智能手机、ATM等终端甚至是火车系统等大型设备）提供计算或应用服务。
• 从软件而言：服务器其实就是安装在计算机上的一个软件，根据其作用的不同又可以分为各种不同的服务器，如：应用服务器、数据库服务器、Redis服务器、DNS服务器、FTP服务器等。
• 总结：服务器就是一台（或者一个集群）安装了服务器软件的高性能的计算机。

1.3.3 常见的服务器硬件设备

• 塔式服务器：

• 机式服务器：

• 刀片服务器：

• 柜式服务器：

1.3.4 常见的服务器操作系统

• 服务器就是一台计算机，它必须安装操作系统之后才能安装其它服务器软件。

• 常见的服务器操作系统：

• ① Linux操作系统：使用最多的服务器操作系统，安全稳定、性能强悍、开源免费（或少于费用）。

• ② Unix操作系统：和硬件服务器捆绑销售，版权不公开，用法和Linux几乎一致。
• ③ Windows Server操作系统：源代码不开放、费用高昂，漏洞较多，性能较差，运维成本极高。

1.3.5 常见的服务器软件

• 硬件服务器装好操作系统之后，就可以安装应用软件了，像我们熟知的Tomcat、MySQL、Redis、FastDFS、ElasticSearch等都是服务器应用软件，它们分别提供自己特定的服务器功能。
• 如果某一台服务器上安装了Tomcat，那么就可以称为Tomcat服务器；换言之，如果安装了MySQL，就可以称为MySQL服务器……

1.3.6 虚拟机服务器

• VMWare虚拟机：通常来说，VMWare通常用于开发人员自己的本地电脑，主要用于模拟服务器环境，或者用于测试，不是团队共同使用的正式环境。

• 弹性云服务器：使用弹性云服务器最大的好处就是弹性伸缩，如：阿里云、腾讯云、华为云等。

• 什么是弹性伸缩？
• 我现在的服务器是20G内存，因为访问量暴涨我需要把内存扩容到80G，要是物理的硬件服务器就需要买来新的内存条插入主板上的内存插槽。而弹性云服务器只需要改一下内存容量的参数就行了，非常方便。等访问量下降了，再把内存容量调回来就可以，不仅方便，而且可以精准的在访问高峰期提高服务器配置而不是一直维持高配，节约成本。

第二章：服务器端应用程序

• 服务器端应用程序就是运行在应用服务器上的，用于处理具体业务功能的一个应用程序，Java EE就是用来编写服务器端应用程序的。
• 常见的服务器端应用程序：淘宝、京东等。

第三章：业务

• 业务就是服务器应用程序中的各个功能，例如：商城里面的注册、登录、添加购物车、提交订单、结算等。

第四章：请求和响应

4.1 请求

• 请求是从客户端发送给服务器，主要用于将客户端的数据传递给服务器。

4.2 响应

• 响应是从服务器发送给客户端，主要用于将服务器端的数据传递给客户端。

第五章：项目的逻辑构成

5.1 请求响应对

• 请求响应对是构成项目的最基本的逻辑单元，一个项目是由非常多的请求响应对组成的。

• 示例：点击超链接跳转到登录页面

5.2 功能

• 功能：一个功能包含多个请求响应对。

• 示例：注册用户功能

请求1：点超链接跳转到注册页面

请求2：发送请求获取短信验证码

请求3：检查用户名是否可用

请求4：提交表单完成注册

5.3 模块

• 模块：一个模块包含多个功能。

• 示例：用户信息管理模块

功能1：用户注册功能

功能2：用户登录功能

功能3：个人中心--账户安全功能

功能4：个人中心--账户绑定功能

功能5：个人中心--收货地址功能

功能6：个人中心--我的银行卡功能

5.4 子系统

• 根据项目规模的不同，子系统这层概念可能有也可能没有。如果设置了子系统，那么子系统中必然包含很多模块；其实，庞大项目的子系统已经相当于一个项目了，甚至比一个小型项目还大。

• 示例：认证中心子系统

模块1：用户信息管理模块

模块2：权限管理模块

模块3：授权管理模块

模块4：权限检查模块

5.5 项目

• 为了解决现实生活中的实际问题开发一个项目，这个项目就是为了这个需求提供的一整套的解决方案。

• 示例：电商项目

子系统1：认证中心子系统

子系统2：商品管理子系统

子系统3：购物车子系统

子系统4：仓储子系统

子系统5：物流子系统

子系统6：订单子系统

第六章：架构（了解）

6.1 概述

• 架构其实就是项目的结构。只不过结构这个词太小了，不适合用来描述项目这么高大上的东西，所以换了另一个高大上的词：架构。
• 当我们聊一个项目的架构的时候，我们聊的是项目是由那些部分组成的、每部分的作用、以及各个部分之间是怎么联系的（通讯的）以及这些部分是怎么组成一个系统（项目）。

6.2 架构的演进过程

6.2.1 单体应用架构

• web应用程序发展的早期，大部分web工程（包含前端页面，web层代码，service层代码，dao层代码）是将所有的功能模块，打包到一起并放在一个web容器中运行。

• 比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能度部署在一个web容器中运行的系统就叫做单体架构，目前也有人称为单体地狱。
• 优点：
  • ① 所有的功能集成在一个项目工程中。
  • ② 项目架构简单，前期开发成本低，周期短，小型项目的首选。
• 缺点：
  • ① 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • ② 系统性能只能通过扩展集群结点，成本高，有瓶颈。
  • ③ 技术栈受限。
  • ④ 代码耦合度很高。
  • ⑤ 容错性差，比如用户管理出问题了，整个系统全部出问题，牵一发而动全身。

6.2.2 垂直应用架构

• 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互补相干的几个应用，以提高效率。

• 优点：
  • ① 项目架构简单，前期开发成本低，周期daunt，小型项目的首选。
  • ② 通过垂直拆分，原来的单体项目不至于无线扩大。
  • ③ 不同的项目可采用不同的技术。
  • ④ 针对不同的子工程优化。
  • ⑤ 解决高并发问题。
  • ⑥ 方便水平扩展，容错性好（相对于单体架构来说的，比如上图中的商品管理出问题了，对CMS系统和后台管理系统来说没影响）。
• 缺点：
  • ① 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护。
  • ② 系统性能扩展只能通过扩展集群结点，成本高，有瓶颈。
  • ③ 系统间相互独立，会产生session共享问题（可以使用Redis Cluster、SpringSession等技术解决）。
  • ④ 重复的开发工作（比如上图中的用户管理功能在电商系统和后台管理系统中都有）。

6.2.3 SOA架构

6.2.3.1 什么是SOA？

• SOA，全称是Service-Oriented Architecture，即面向服务的架构。它可以根据需要通过网络对松散耦合的粗粒度应用组件（服务）进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
• 站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的是把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
• 通过上面的描述可以发现SOA有如下的特点：分布式、可重用、扩展灵活、松耦合。

6.2.3.2 SOA架构

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使得前端应用能够更快速的响应多变的市场需求。

• 优点：
  • ① 抽取公共的功能为服务，提高开发效率。
  • ② 对不同的服务进行集群化部署解决系统压力。
  • ③ 基于ESB或Dubbo减少系统耦合。
• 缺点：
  • ① 抽取服务的粒度较大。
  • ② 服务提供方和调用方接口耦合度较高。

6.2.4 微服务架构

• 优点：
  • ① 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将会缩短，运维成本也将大幅度下降。
  • ② 微服务遵循单一原则。微服务之间采用RESTful等轻量级协议传输。
• 缺点：
  • ① 微服务过多，服务治理成本高，不利于系统维护。
  • ② 分布式系统开发的技术成本高（容错、分布式事务等）。

6.2.5 SOA和微服务的关系

• SOA：面向服务的架构，是一种设计方法，其中包含多个服务，服务和服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统的进程之中。各个服务之间通过网络调用。
• 微服务架构：其实和SOA架构类似，微服务是SOA架构上的升华，微服务架构强调的一个重点是”业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。 | 功能 | SOA | 微服务 | | —- | —- | —- | | 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 | | 耦合 | 通常松耦合 | 总是松耦合 | | 公司架构 | 任何类型 | 小型，专注于功能交叉团队 | | 管理 | 着重中央管理 | 着重分散管理 | | 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |