各阶段架构解析(含高并发和微服务):架构生命周期

·  阅读 2391

简介

  1. web1.0时代(1996年左右)
  2. web2.0时代(2006年左右)
  3. 互联网时代--->互联网+时代--->智慧城市:嘀嘀打车、饿了么(2012年左右)
  4. 大数据+云计算
  5. AI未来以来时代
  6. ......

背景演变

第一时期

1. 单一应用架构简介

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

产生问题(维护)

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

2. 分层阶段简介

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

产生问题(高并发)

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

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

产生的问题

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

第二时期

垂直应用架构概述

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

水平拆分(横着拆)

情景要求

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

拆分方法

  • 按照不同的层次进行拆分
  • 一个大应用查分成多个小应用
parent pom    #父工程(放所有的pom.xml)
common.jar    #公共库 相关工具类
pojo.jar      #java bean
mapper.jar    #数据持久层
service.jar   #业务逻辑层
web.war       #web访问层
manager.war   #后台管理
复制代码

优点

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

垂直拆分(竖着拆)

拆分方法

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

优点

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

产生的问题

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

第三时期

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

分布式架构概述

  • 一个业务拆分多个子业务,部署在不同的服务器上
  • 采用前后端分离进行开发/部署(页面+业务代码)

  • 使用RPCHttpHttpClient等底层技术技术解决不同模块之间的调用

产生的问题

  1. 分布式事务:二阶段提交
  2. 分布式锁:Redis中的Setnx key value
  3. 分布式Session:Redis集群
  4. 分布式日志: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(面向服务架构)也是基于小应用的,我们也可称之为微服务架构

优点

  1. 微服务对业务功能的拆分更加的细致复用性更强),可提高开发效率
  2. 拓展性强:可根据需求选择使用最新的技术
  3. 适用于互联网项目:迭代周期,开发效率

缺点

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

产生的问题

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

Springboot

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


PS:

  1. 几乎全部手打,对于重点部分进行加粗操作,便于阅读,含原创内容
  2. 部分资源网络整理,如有侵权请告知删除。
  3. 转载本文请注明出处
分类:
后端
标签:
分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改