简介

web1.0时代（1996年左右）
web2.0时代（2006年左右）
互联网时代--->互联网+时代--->智慧城市：嘀嘀打车、饿了么（2012年左右）
大数据+云计算
AI未来以来时代
......

背景演变

第一时期

1. 单一应用架构简介

互联网发展的最早时期，所有的代码、业务都写在JSP中，也是网站初期的最早架构。
All in one：所有的模块和代码都放在一起，不分层（2000年左右）。
数据库和代码在一个服务器中

产生问题（维护）

代码放在一起不具备可维护性（代码都在JSP页面中）
容错性差，出现异常用户可直接看到异常信息，该错误可能会导致服务宕机

2. 分层阶段简介

分层开发以提高可维护性（controller、service、dao）
MVC架构（是一个基于Java Web应用的设计模式）
数据库和应用的服务器分离部署

产生问题（高并发）

随着用户访问量的持续增加，单台应用服务器已无法满足需求。

3. 集群阶段简介

集群：同一个业务部署在多个服务器上。
支持高并发、高可用。

产生问题（转发、Session）

那么多的服务器用户到底访问那个？
session保存在哪里？

4. Nginx、Redis阶段

使用Nginx反向代理统一用户请求地址，Niginx利用负载均衡完成用户请求的转发。
使用Redis Cluster（Redis集群）实现session共享。

产生问题（数据库）

Nginx+Tomcat集群带来的高并发导致数据库的压力过大

5. 数据库优化阶段

主从复制

采用数据库的主从复制，读写分离技术
主从数据库之间进行数据同步：master负责增删改操作；slave负责读/查询操作
mysql本身就支持master-slave功能（主从复制）

Solr/ElasticSearch

数据库本身对大数据量查询效率慢，对模糊查询的支持不是很优秀。
像电商类网站，搜索是非常核心的功能，即使做了读写分离，但是还有很多功能不能有效解决（分词技术）
针对该问题，引入全文检索服务器功能

Redis缓存

在大并发情况下对于热点数据，请求的数据库的次数是海量的，然而数据库无法应对如此大的查询请求，会导致数据库无法对外提供服务（连接异常）
利用Redis进行缓存，将热点数据存储在Redis中，无需每次都请求数据库。
并且Redis的读写性能极好，拥有丰富的数据类型并且支持原子性

数据库表的拆分

一张表里面有1000条数据，查询性能很高。
如表中有100万数据，查询的性能很低。
单个表性能做提升，但是提升的空间终归还是有限的。

垂直拆分

假设一张用户表里面有30个字段：id,姓名，年龄，身份证号，身高，体重，性别，手机号，家庭住址.....
热门字段：id，姓名，身份证号，年龄，性别，手机号
冷门字段：其他剩余
我们可以将热门字段放在user表中，冷门字段放在userinfo表中，完成表的拆分

水平拆分

按需求拆分（省份/时间）
我们可以将一张用户表中的数据，按照不同的省份拆成不同的表

采用第三方分库分表的中间件

mycat、sharding-jdbc、drds(阿里)
通过设计可以保证高并发、高可用（通过不断的增加服务器）

https://blog.csdn.net/jornada_/article/details/82947677

产生的问题

服务器很贵，存在忙闲不均的问题（就双11那几天访问量大），服务器的维护需要大量的人工成本（运维工程师）
可维护性差：一个业务的改动，每台服务器上都要重新部署
可拓展性差：（指的是服务器）再增加一台服务器，需要重新配置环境
协同开发不方便：大家都去修改相同业务代码，已发生代码冲突/错误问题
单体架构：随着业务需求的不断增加，应用代码也会变的越来越多，导致部署到服务器上时，所占用的硬盘空间过大

第二时期

垂直应用架构概述

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

水平拆分（横着拆）

情景要求

现在网站分为前台（给用户使用），后台（给管理员使用），是否需要拆成2个项目独立部署？如果需要拆的话，有一些前后台都需要公用的代码，这些代码怎么办？

拆分方法

按照不同的层次进行拆分
将一个大应用查分成多个小应用

parent pom    #父工程（放所有的pom.xml)
common.jar    #公共库 相关工具类
pojo.jar      #java bean
mapper.jar    #数据持久层
service.jar   #业务逻辑层
web.war       #web访问层
manager.war   #后台管理

优点

独立jar包，模块复用
减少了部署时服务器的磁盘占用：用户访问的web.war包可以多部署几个服务器，后台管理的manager.war包就部署1台服务器

垂直拆分（竖着拆）

拆分方法

按照不同的功能进行拆分
将一个大的应用按功能拆分成多个互不相干的小应用，并且每个应用都是独立的Web应用程序（向分布式发展）

优点

可维护性：如果需求发生变更，只需要调整某个应用模块即可
功能拓展性：增加了不同的业务需求，就增加对应的Web模块
协同开发方便：不同的小组负责不同的模块
部署性能调优：哪个模块访问量大，就多部署几台负责该模块的服务器

产生的问题

客户对页面的要求越来越高，需要频繁修改页面，但是此时前后端未分离（每一个应用从头到尾都是完整的），每次都需要重新部署后台应用程序。
随着业务需求的不断增加，多个不同的模块之间可能会产生业务交互，（不同的模块都部署在不同的服务器上）如何解决？

第三时期

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
RPC：（Remote Procedure Call)是一个计算机通信协议，该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。RPC是一个分布式计算的CS模式，总是由Client向Server发出一个执行若干过程请求，Server接受请求，使用客户端提供的参数，计算完成之后将结果返回给客户端。RPC的协议有很多，比如最早的CORBA，Java RMI，Web Service的RPC风格，Hessian，Thrift，甚至Rest API

分布式架构概述

将一个业务拆分成多个子业务，部署在不同的服务器上
采用前后端分离进行开发/部署（页面+业务代码）

使用RPC、Http、HttpClient等底层技术技术解决不同模块之间的调用

产生的问题

分布式事务：二阶段提交
分布式锁：Redis中的Setnx key value
分布式Session：Redis集群
分布式日志：ELK（Elasticsearch、Logstash 和 Kibana）

当服务越来越多，服务和服务之间的调用非常的混乱（我都不知道你有哪些服务）（RPC）
资源的浪费问题（支付管理访问量小，却部署了100台服务器；物流管理访问量大，但只部署了50台服务器）

第四时期

流动计算架构概述

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
SOA：Service Oriented Architecture，“面向服务的架构”:他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。

解决方案

分布式服务治理中间件：（Dubbo/SpringCloud)
举例：

以一个公司为例：有基层员工， 有管理层， 有老板。
最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越多，管理也很混乱，
就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转

Dubbo底层用的RPC协议（Dubbo是一个RPC框架）。
SpringCloud底层用的HTTP协议。

微服务和SpringBoot

微服务

单体应用拆分成多个互不相干的小应用，每一个小的应用称为微服务。
因为SOA（面向服务架构）也是基于小应用的，我们也可称之为微服务架构

优点

微服务对业务功能的拆分更加的细致（复用性更强），可提高开发效率
拓展性强：可根据需求选择使用最新的技术
适用于互联网项目：迭代周期短，开发效率快

缺点

微服务太多，服务的管理/治理成本高
不利于服务的部署：可使用Docker/K8S
技术难点在增加：分布式事务、锁、Session、日志
对程序员的要求在不断提高：Dubbo/SpringCloud

产生的问题

单体应用架构我们使用的SSM框架即可
当我们把单体应用架构拆分成多个小应用时，每一个小应用都是独立的web程序，每一个都要进行SSM配置（包含大量重复jar包和配置文件）

Springboot

用于简化代码的开发和简化代码框架的构建。

PS：

几乎全部手打，对于重点部分进行加粗操作，便于阅读，含原创内容
部分资源网络整理，如有侵权请告知删除。
转载本文请注明出处