技术架构演进之路

单机架构

简介	应用和服务公用一台服务器
出现原因	出现在互联网早期,访问量比较小,单机足以满足需求.
架构工作原理	可以通过应用(多个模块)和数据库在一个服务器上完成交互
优点	部署简单,成本低
缺点	存在严重的性能瓶颈,数据库和服务互相竞争资源.

技术案例:

应用数据分离架构

简介	应用服务和数据库服务使用不同的服务器
出现原因	单机架构存在严重的资源瓶颈,导致站点变慢
架构工作原理	可以看到应用(多个模块)和数据库在各自的服务器上通过网络协调工作.
优点	成本相对可控,性能有一定提高,最重要的是数据库单独隔离,有一定的容毁能力
缺点	硬件成本较高,任然无法面对海量并发

前两种架构将性能归过于服务器,我们可以通过购买服务器来提高其性能

应用服务集群架构

简介	引入了负载均衡,应用以集群的方式运行
出现原因	单个应用不足以支持海量的并发请求,高并发的时候站点响应变慢
架构工作原理	可以看到应用不是一个,而是多个,通过负载均衡来实现高并发.
优点	高可用,支持横向扩展,具有一定的高性能(如果在不访问数据库的情况下)
缺点	数据库成为性能瓶颈,无法应对数据库的海量查询,数据库是单点的,没有高可用,硬件成本高,运维工作量大.

技术案例:

读写分离架构

简介	将数据库读写操作分散到不同的节点,数据库服务器搭建主从集群,一主一从,一主多从都可以,数据库主机负责写操作,从机负责读操作
出现原因	数据库成为瓶颈,而互联网应用一般读多写少,那么我们就可以进行选择,将读操作和写操作分开
架构工作原理	可以看到数据库服务器不再是一个,数据库主机负责写操作(也可以配置读),从机负责读操作,主机通过复制的方式将数据发送到从机.
优点:	数据库层面的一个高可用,读取性能一定得到提升,写的性能间接提升,
缺点	热点数据的频繁读取导致数据库的压力增大,同步服务如果挂点或者网络延迟大,主库和从库数据不一致的问题,成本增大.

技术案例:

冷热分离架构

简介	引入缓存,实现冷热分离,将热点数据放入缓存中快响应
出现原因	海量的请求导致数据库负载过高,站点响应再次变慢
架构工作原理	可以看到多了很多缓存服务器,对于热点数据直接放到缓存服务器中,不常用的数据再到数据库中查找.
优点	大幅降低对数据库的访问请求,性能提升非常明显
缺点	带来了缓存一致性问题,缓存击穿,缓存失效,缓存雪崩等额问题,服务器成本需要额外增加.业务体力变大后,数据量增大,数据库单库太大,单个表体量也太大,数据查询会很慢,数据库再次成为性能瓶颈.

技术案例:

垂直分库架构

简介	数据库的数据被拆分,数据库数据分布式存储,分布式处理,分布式查询,也可以理解为分布式数据库架构
出现原因	单机的写库会大道性能瓶颈,需要拆分数据库,数据表的数据量太大,处理压力大,需要进行分表,为降低运维难度,业界主键研发了分布式数据库,库表天然支持分布式.
架构工作原理	数据库是由多个主从库或者存储集群组成,支持分布式大规模并行处理
优点	数据库吞吐量大幅增加
缺点	跨库join,分布式事务等问题,这些需要对应的去解决,目前的mmp都有对应的解决方案

技术案例:

微服务架构

简介	微服务是一种架构风格,按照业务板块来划分代码,使单个应用的职责更加清晰,相互之间可以做到独立迭代
出现原因	扩展性差,因为没改动一行代码,都要重新部署整个系统,浪费时间,持续开发困难难;不可靠,以前的架构,如果整个系统中的某一个功能不可用,直接将导致整个系统瘫痪;不灵活:无法使用不同的编程语言构建单体程序;代码维护难:所有功能耦合在一起,信任不知道如何下手;
架构工作原理	电子商城拆分成多个微服务,如用户服务,交易服务,商品服务,各个服务共同协作组件成电子商城应用
优点	服务器独立测试,部署,升级;独立扩展;提高容错性;支持多种编程语言
缺点	运维复杂度高,应用和服务都会变多,部署会越来越困难,同一台服务器上部署多个应用还需要考虑环境的问题;资源使用变多;处理故障困难;

技术案例:

容器编排技术

简介	借助容器化技术将应用/服务打包为镜像,通过容器编排工具来动态发布和部署镜像
出现原因	微服务拆分细,服务多部署工作量大,而且配置复杂,容易出错
架构工作原理	一个商城应用拆分为商品,用户,交易服务,每个微服务打包到容器中,相互协作完成功能,通过容器编排工具完成部署
优点	部署简单;隔离性好,容器与容器之间文件系统,网络相互隔离,不会产生环境冲突;版本切换更为方便;
缺点	技术栈变多(docker,k8s);

互联网架构

背锅过程:

docker的核心作用:完成核心打包,让我们进行容器话的一个运行 !