引言:为了更好理解互联网架构,需要先了解基础概念
概念:
- 应用、系统:完成整套服务的程序或者程序群
- 模块、组件:完成指定功能的部分,相互解耦合
- 分布式:系统中的多个模块部署在不同服务器上,强调的物理形态
- 集群:为了完成某个目标的特定组件,部署于多台服务器,强调完成特定服务目标
- 主、从:集群中,通常由一个程序承担更多责任称为主,其他承担附属职责的称为从
- 中间件:实现不同程序的通信,充当桥梁
- 容器:理解为装载集装箱的货物,可以实现功能
- 容器编排(K8S):理解为货船,组织集装箱的搬运
- 可用性:单位时间段,系统正常提供服务的概率
- 吞吐、并发:单位时间段内,系统可以成功处理请求数量。并发指同一时刻支持的请求最高量
一、单机架构
概念
单机架构是最基础的软件系统架构模式,指整个应用系统的所有组件---包括应用界面、业务逻辑、数据存储等都运行在一台物理机或虚拟机上
特征
- 集中部署:所有服务模块打包一起,作为整体,单个服务器包含程序和数据库
- 本地通信:各组件之家通过进程内函数调用,无序网络开销
- 单进程:通常以一个进程或者少数进程承载全部功能
- 共享资源:CPU、内存、磁盘、数据库等全部本机独占
优点
- 架构简单,开发部署方便
- 调试容易,运维成本低
缺点
- 扩展性差,受限于单机硬件上限
- 技术栈耦合,难以独立升级某个模块
- 对访问量大的,硬件资源成为限制
使用场景
- 业务规模小,用户量有限
- 对可用性不高的离线系统
二、应用数据分离架构
概念
应用数据分离架构和之前的架构区别在于将数据库服务独立部署在同一个数据中心的其他服务器上,应用程序通过网络访问数据
特征
- 物理隔离:应用和数据部署在不同机器,通过数据库协议进行网络通信
- 资源独立:应用程序专注于CPU和内存,数据库服务专注于磁盘IO和存储
- 独立升级:可以单独升级数据库机器配置或应用机器配置
优点
- 解决不同线程资源争抢
- 数据库独立优化
- 数据库单独隔离,不会因为应用把数据库弄坏
缺点
- 网络络通信开销
- 运维复杂度略上升
- 当访问量增加,单台应用服务器无法满足需求
使用场景
- 业务量增加,单机资源成为瓶颈
- 数据量较大,需要独立的存储和IO能力
- 作为从单机向分布式演进的过渡阶段
三、应用服务集群架构
概念
- 应用服务集群架构是在应用与数据分离的基础上,将应用服务器从单台扩展为多台,引入了负载均衡。
- 负载均衡:解决用户流量分发到哪台服务器,需要一个专门的系统组件做流量分发,实际中的负载均衡不仅仅指的是工作在应用层,还可能其他的网络层
- 流量调度算法:
- Round-Robin轮询算法(公平均分给不同服务器)
- Weight-Round-Robin轮询算法(能者多劳)
- 一致散列哈希算法(通过计算用户特征值<如ip地址>得到哈希值,请求总是分配给指定服务器,用于专项客户经理服务)
- 负载均衡软件:Nginx(软件),HAProxy,LVS、F5(硬件)等
特征
- 水平扩展:流量大时,直接加应用服务器
- 故障隔离:某个服务器宕机,负载均衡自动摘除,不影响整体服务
- 无状态化:应用服务器不保存状态(session外置<存入redis等中间件>),每台机器地位平等
优点
- 支持高并发,高可用,单台宕机不影响整体
- 可水平扩容
- 支持滚动发布
缺点
- 引入负载均衡,架构复杂度上升
- 分布式日志追踪复杂
- 需要解决session共享
session:用户登录后,服务器在内存创建session对象,记录用户登录状态,通过session ID关联用户。在集群架构中,用户通过服务器A登录,A创建session对象,用户下一次请求被负载均衡到服务器B,B找不到session,则认为用户未登录
解决:
- session粘连:同一个用户负载均衡到同一个服务器
- session复制:每个服务器拷贝session
- 集中式session:将所有session数据存储到独立中间件(redis),应用服务器从redis读写session
- Token方案:将用户信息加密后存在Token中,由客户端携带,服务器收到请求解析
四、读写分离/主从分离架构
概念
读写分离架构是在应用服务集群的基础上,将数据库也拆分。一台主库负责写操作,多台从库负责读操作,主库和从库之间通过数据同步保持数据一致性。解决了随着用户流量的增长,数据库的访问效率成为瓶颈
分离读写请求中间件:MyCat,TDDL,Amoeba,Cobar等
数据同步:主库写数据-写入bin log-从库拉取bin log-从库重放-数据同步
特征
- 写操作走主库,保证数据一致性
- 读分散:读操作分散到多个从库,水平扩展读能力
- 异步复制:主从之间通常异步复制,存在短暂数据延迟
- 读扩展:读压力大,直接加从库
优点
- 读能力大幅提升,水平扩展读能力
- 读写互不干扰,减少资源争抢
- 从库用于备份,报表查询,不影响主库
- 主库故障可将从库提升到主库
缺点
- 主库单点,写能力无法扩展
- 主从复制有延迟,可能读到旧数据
- 架构复杂度上升,有路由延迟
使用场景
- 读请求高于写请求
- 单库读性能成为瓶颈
- 作为分库分表前的过渡方案
五、冷热分离架构
概念
冷热分离架构是一种数据存储优化策略,核心思想是将数据按访问频率分为热数据和冷数据,热数据放在高性能存储,冷数据放在廉价数据库,大大降低数据库压力
例如:Mencached,Redis等缓存软件
特征
- 分层存储:不同访问频率的数据使用不同成本的存储介质
- 数据流转:数据随着时间或访问频率的变化,从热-温-冷逐步迁移
- 透明访问:应用层通过路由规则统一访问,不需要关心数据具体存在哪里
优点
- 降低存储成本
- 热数据表体积小,查询效率提升
- 减少热库磁盘占用和索引压力
缺点
- 架构复杂度上升,需要维护数据迁移
- 数据迁移需要保证数据一致性
- 冷热数据联合查询较为复杂
使用场景
- 电商订单系统:近3个月订单存Mysql,历史订单归档HBase或OSS
- 用户行为数据:实时行为存Redis,历史行为存数据湖(不管什么格式、来源的数据先扔进去,用的时候在捞出来加工)
六、垂直分库
概念
垂直分库是数据库拆分的一种策略,核心是按业务模块将不同业务的表拆分到不同的数据库实例中。由于单库存在不同线程的资源争抢,所有业务表混在一起使索引优化互相影响,所以引入分库分表
说明:使用mycat进行分库分表后,实际上构建了一个分布式系统,虽然对外看起来是库,但内部是由中间件与多个单机数据库共同协作完成。这种将大任务拆解分发到多节点并行计算的模式是典型的MMP思想(人多力量大)
MPP架构数据库:Greenplum,TiDB,Postgresql XC,HAWQ等
特征
- 业务隔离:关联度低的业务拆分到独立数据库,同一业务的表保留在同一库中
- 资源独立:每个库拥有独立的CPU、内存、磁盘、连接池,互不干扰
- 数据内聚:统一业务域的表间关联(订单表和订单项表)可通过主键内连接
优点
- 业务解耦,各库独立维护、优化
- 故障隔离,资源隔离
- 按业务独立扩展,按需分配资源
- 与微服务架构契合(每个服务一个库)
缺点
- 跨库无法直接join
- 运维成本高,架构复杂
- 分布式事务处理复杂(例如订单创建+库存扣减)
- 无法解决单表数据量过大的问题
七、微服务架构
概念
微服务架构是将单一应用程序拆分未多个小型,自治服务的软件设计方式,自行调用工具完成特定业务能力构建,可独立开发,扩展。每个微服务之间对数据的之间访问进行隔离
例如:Spring Cloud、Dubbo
特征
- 服务独立性:每个服务有自己的代码库,数据库和技术栈
- 轻量级通信:服务间通过标准化API交互,提升相应速度
- 弹性强:根据业务负载动态调整单个服务的实例数量,资源利用率高
优点
支持快速迭代:单个服务可独立发布,上线周期短
适配高并发:热点服务可独立扩容
缺点
- 运维复杂度高
- 测试调试困难:测试要模拟多服务交互,环境搭建成本高
八、容器编排架构
概念
- 容器编排架构---解决如何自动部署、调度、扩缩容、故障恢复容器,本质是容器集群的管家
特征
- 自动化部署和滚动更新和回滚
- 根据CPU、内存等指标自动调整实例数量