一、服务器和客户端的概念
1.1 客户端的作用
与用户进行交互，用于接收用户的输入、展示服务器端的数据以及向服务器端传递数据。
1.2 服务器的作用
与客户端进行交互，接收客户端的数据、处理具体的业务逻辑、传递给客户端需要的数据。
1.3 什么是服务器？
“服务器”是一个很广泛的概念，从硬件而言：服务器是计算机的一种，它比普通计算机运行更快、负载更高、价格更贵。服务器在网络中为其他客户机（如PC机、智能手机、ATM等终端）提供计算或者应用服务。从软件而言：服务器其实就是安装在计算机上的一个软件，根据其作用的不同又可以分为各种不同的服务器，例如应用服务器、数据库服务器、Redis服务器、DNS服务器、ftp服务器等。
1.3.1 常见的服务器硬件设备
- 刀片服务器
- 塔式服务器
- 机房
1.3.2 常见的服务器操作系统
服务器是一台计算机，它必须安装操作系统之后才能够安装使用服务器软件
- Linux系统：使用最多的服务器系统，安全稳定、性能强劲、开源免费（或少许费用）。
- Unix系统：和硬件服务器捆绑销售，版权不公开，用法和Linux一样。
- Windows Server系统：源代码不开放，费用高昂，漏洞较多，性能较差，运维成本高。
1.3.3 常见的服务器软件
- Tomcat
- MySQL
- Redis
- FastDFS
- ElasticSearch
1.3.4 虚拟机服务器
- VMWare虚拟机：通常来说VMWare用于开发人员在本地电脑上搭建一个模拟的服务器环境，或自己装一些东西测试，不是团队共同使用的正式环境。
- 弹性云服务器：使用弹性云服务器最大的好处就是弹性收缩。什么是弹性伸缩呢？比如现在我的服务器是20G内存，因为访问量暴涨需要把内存扩容到80G，要是物理的硬件服务器就需要买来新的内存条插入主板上的内存插槽。而弹性云服务器只需要改一下内存容量的参数就行了，非常方便。等访问量下降了，再把内存容量调回来就可以了，不仅方便，而且可以精准的在访问高峰期提高服务器配置而不是一直维持高配，节约成本。
二、服务器端应用程序
服务器应用程序就是运行在应用服务器软件上，用于处理具体业务功能的一个应用程序。例如：淘宝、京东等项目都是服务器端应用程序。
业务就是服务器应用程序中的各个功能，例如：商城里面的注册、登录、添加购物车、提交订单、结算订单等等都成称之为业务。
三、请求和响应
3.1 请求
请求就是从客户端发送给服务器，主要用于将客户端的数据传递给服务器。
3.2 响应
响应就是从服务器发送给客户端，主要用于将服务器的数据传递给客户端。
四、项目的逻辑构成
4.1 请求响应对
请求响应对是构成项目的最基本的逻辑单元，一个项目是由非常非常多的请求响应对构成的。
例如：点击链接跳转到注册页面
4.2 功能：一个功能包含多个请求响应对
例如：注册用户功能
- 请求1：点超链接跳转到注册页面
- 请求2：发送请求获取短信验证码
- 请求3：检查用户名是否可用
- 请求4：提交表单完成注册
4.3 模块：一个模块包含多个功能
例如：用户信息管理模块
- 功能1：用户注册功能
- 功能2：用户登录功能
- 功能3：个人中心——账户安全功能
- 功能4：个人中心——账户绑定功能
- 功能5：个人中心——收货地址功能
4.4 子系统
根据项目规模的不同，子系统可能有也可能没有。如果设置了子系统，那么子系统中也必然包含很多模块。其实庞大项目的子系统就相当于一个项目了，甚至比一些小型项目还要大。
例如：认证中心子系统
- 模块1：用户信息管理模块
- 模块2：权限管理模块
- 模块3：授权管理模块
- 模块4：权限检查模块
4.5 项目
为了解决生活中的实际问题开发一个项目，这个项目就是为这个需求提供的一整套解决方案。
例如：电商项目
- 子系统1：认证中心子系统
- 子系统2：商品管理子系统
- 子系统3：购物车子系统
- 子系统4：订单子系统
五、架构
5.1 架构的概念
架构其实就是项目的结构。项目是由哪些部分组成的、每部分的作用、以及各个部分之间的联系、以及各个部分是如何组成一个系统的。
5.2 架构的演进过程
5.2.1 单一应用架构（all in one）
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署结点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）是关键。
架构优点
架构简单，前期开发成本低、开发周期端，适合小型项目。
架构缺点
全部功能集成在一个工程中
- 业务代码耦合度高，不易维护
- 维护成本高，不易拓展
- 并发量大，不易解决
- 技术栈受限，只能使用一种语言开发
单一架构中的技术体系
视图：用户的操作界面+数据的动态显示
- 前端技术：HTML、CSS、JavaScript、Vue
- 异步交互：Ajax
- 服务器端页面模板技术：Thymeleaf
控制层：处理请求+跳转页面
- 服务器：Tomcat
- 控制器：Servlet
- 域对象：request、session、servletContext
业务逻辑层：业务逻辑计算
持久化层：操作数据库
5.2.2 垂直架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，可以提升效率。此时，用于加速前端页面开发的Web框架（MVC）是关键。
架构优点
- 业务代码相对解耦
- 维护成本相对易于拓展（修改一个功能，可以直接修改一个项目，单独部署）
- 并发量大相对易于解决（搭建集群）
- 技术栈可扩展（不同的系统可以用不同的编程语言编写）
架构缺点
- 功能集中在一个项目中，不利于开发、扩展、维护
- 粒度不够细
- 代码之间存在数据、方法的冗余
5.2.3 分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，主键形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
架构优点
- 业务代码完全解耦，并可实现通用
- 维护成本易于拓展（修改一个功能，可以直接修改一个项目，单独部署）
- 并发量大易于解决（搭建集群）
- 技术栈完全扩展（不同的系统可以用不同的编程语言编写）
架构缺点
- 缺少统一管理资源调度的框架
5.2.4 流动计算架构（SOA）
服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高集群机器利用率的资源调度和治理中心（SOA）是关键。
资源调度和治理中心的框架：dubbo、spring cloud。
架构优点
- 业务代码完全解耦，并可实现通用
- 维护成本易于拓展（修改一个功能，可以直接修改一个项目，单独部署）
- 并发量大易于解决（搭建集群）
- 技术栈完全扩展（不同的系统可以用不同的编程语言编写）
- 框架实现了服务治理，不用担心集群的使用情况（失败会尝试其他服务…）
