Docker--架构篇 - 详解
目录
一、整体架构图和演变因素
以解决上一架构的缺点而不断演进解决方法形成新的架构
二、单机架构
2.1介绍
应用服务和数据库服务共用一台服务器
2.2原因
出现在互联网早期，访问量比较小，单机足以满足需求
2.3原理图
2.4优缺点
优点：部署简单、成本低
缺点：性能存在严重瓶颈，数据库与应用服务竞争资源
三、应用数据分离架构
3.1介绍
应用服务和数据库分离
3.2原因
单机存在严重的资源竞争，导致站点变慢
3.3原理图
4.4优缺点
优点：
（1）成本可控
（2）与单机相比性能提升
（3）数据库被隔离保障安全性
缺点：
（1）硬件成本增加
（2）性能依然存在瓶颈，无法应对海量开发
四、应用服务集群架构
4.1介绍
引入负载均衡，应用服务以集群方式运行
4.2原因
单个应用不足以支撑海量的并发请求，高并发的时候站点响应变慢
4.3原理图
4.4优缺点
优点：
（1）应用服务满足高并发
（2）性能提升可迅速响应（不访问数据库的前提下）
（3）应用服务可横向扩展
缺点：
（1）数据库性能存在瓶颈
（2）不协助高并发可用
（3）运维工作上升
（4）硬件成本高
五、读写分离架构
5.1介绍
将数据库读写操作分散到不同节点，数据库服务器搭建主从集群，一主一从，多主多从，主机负责写，从机负责读
5.2原因
数据库成为瓶颈，而互联网应用一般读多写少，数据库承载压力大，主要是由这些读的请求造成的，那么我们可能把读操作和写操作分开
5.3原理图
5.4优缺点
优点：
（1）读写性能提高
（2）可用性提升
缺点：
（1）频繁读取的热材料负载高（2）数据库间同步延迟
（3）服务器成本增加
六、冷热分离架构
6.1介绍
引入缓存服务器，实行冷热素材分离，将热点信息缓存在缓存服务器中，每次访问先从缓存中寻找，从而达到高效响应
6.2原因
海量的请求导致数据库负载过高，站点响应再度变慢
6.3原理图
6.4优缺点
优点：
（1）大幅提升数据库访问请求速度
（2）性能明显提升
缺点：
（1）可能引发缓存一致性，缓存击穿，缓存失效，缓存雪崩等问题，服务器成本进一步增加（2）业务量变大，单表数据过大，数据查询缓慢
七、垂直分库架构
7.1介绍
拆分数据库数据，数据库数据分布式存储、处理和查询，分布式数据库架构
7.2原因
单机的写库会逐渐会达到性能瓶颈，得拆分数据库，数据表的数据量太大，处理压力太大，必须进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支撑分布式
7.3原理图
7.4优缺点
优点：数据库吞吐量大幅提升，不再是瓶颈
缺点：
（1）跨库join、分布式事务等问题，这些得对应的去进行解决，目前的mpp都有对应的解决方案
应用的代码整体耦合在一起，修改一行代码必须整体重新发布就是（2）耦合度高，数据库和缓存结合目前能够抗住海量的请求，但
八、微服务架构
8.1介绍
通过按照业务来划分应用服务，使单个应用职责更清晰相互之间能够独立迭代
8.2原因
（1）扩展性差:应用程序无法轻松扩展，因为每次需更新应用程序时，都必须重新构建整个系统
（2）持续开发困难:一个很小的代码改动，也需要重新部署整个应用,无法频繁并轻松的发布版本
（3）不可靠，一个功能影响其他功能
（4）不灵活，代码耦合度很高
（5）维护工作困难
8.3原理图
8.4优缺点
优点：
（1）灵活性高
（2）独立扩展
（3）提高容错性
（4）支持多编程语言
缺点：
（1）运维难度高
（2）资源使用变多
（3）处理故障困难
九、容器编排架构
9.1介绍
借助容器化技术（docker）将应用/服务行打包成镜像，通过容器编排设备（k8s）来动态分布和部署镜像服务以容器化方式运行
9.2原因
（1）微服务拆分细，服务多部署工作量大，而且设置复杂，容易出错
（2）微服务数量多扩缩容麻烦
（3）微服务环境可能发生冲突
9.3原理图
9.4优缺点
优点：
（1）部署运维简单快捷
（2）隔离性好，容器与容器之间文件系统、网络等相互隔离
（3）支持版本前后滚动更新
缺点：
（1）技术栈变多
（2）机器本身成本和运维成本高，资源利用率低，会存在大量服务器空闲的情况
十、网络应用架构演示图
浙公网安备 33010602011771号