架构设计
2019-03-21 10:26:31 0 举报AI智能生成
架构设计汇总
作者其他创作
大纲/内容
三原则
合适原则
合适优于业界领先
简单原则
简单优于复杂
演化原则
演化优于一步到位
基本问题
高可靠
可拓展
复杂度来源
高性能
常见方案
水平拓展(负载均衡)
单个业务横向加机器水平拓展
注意状态或竞争资源
垂直拓展
单机硬件性能提升
业务模块垂直拆分
注意拆分粒度
粒度过下会导致接口间调用指数级增长
衡量
QPS
TPS
高可用
冗余拓展
分类
存储高可用
计算高可用
状态决策
独裁式
决策者收集上报者的信息然后决策
协商式
主备模式
民主式
选举模式
主备方案
集群方案
分支主题
可拓展性
预测变化
应对变化
低成本
安全
规模
步骤
识别复杂度
复杂度
需要解决的复杂度只可能是其中一两点
设计备选方案
评估和选择备选方案
方案质量属性
性能
可用性
硬件成本
项目投入
安全性
版本兼容性
为每个方案质量属性赋值权重
详细方案设计
负载均衡方式
库表设计
日志表
业务表
mysql 数据复制方式
SDK设计
通信协议
数据传输格式
Json
Protocol buffer
常见架构模式确定
高性能架构模式
数据存储
高性能mysql集群
读写分离
本质是分散了访问压力，但无法解决存储海量数据的存储压力
即一主多从，主写从读
表的索引要合适，否则经常会出现主从同步宕机或主从数据不一致的问题
复杂度点
复制延迟
可达到1秒钟左右
常见解决方法
1.写操作后的读操作发给主服务器
2.读从机失败后再读一次主机
3.关键业务读写都指向主机，非关键业务采用读写分离
分配机制
1.程序代码封装
即抽象一个数据访问层
开源方案
TDDL(Taobao Distribute Data Layer)
特点
实现简单，根据业务可定制化
不支持多语言，多个语言的子系统需要重复实现
故障情况下，如果主从发生切换，需要修改所有系统配置并重启
2.中间件封装
即独立一套系统出来，中间件对业务提供SQL兼容的协议，业务服务器无需做读写分离
支持多种语言
SQL兼容协议实现复杂度高，短期内不稳定
中间件的性能要高，稳定性要高
数据库主从切换对业务无感知
MySQL Proxy
Atlas
单台数据库服务器的存储瓶颈体现
读写性能下降，因为随着数据量增大，索引变大
数据库的备份和恢复耗时变得很长
数据丢失的风险变高
分库分表
业务分库
引入的问题
1.join连接查询问题
2.事务问题
3.成本问题
分表
垂直分表
适合将表中某些不常用且占了大量空间的列拆分出去
水平分表
适合表行数特别大的表
根据表的复杂度及访问性能决定分表数据量
1000W
5000W
路由
范围路由
有序数据列
ID
时间戳
复杂点
分段大小的选取
建议单表范围100W-2000W
考虑数据增长率
分布不均匀
随着数据量增长易于平滑增表拓展
hash路由
初始表数量选取
分布均匀
随着数据量增长拓展麻烦，即增加表需要做数据迁移重新分布
高性能NoSQL
K-V存储
Redis
解决关系数据库无法存储数据结构问题
文档数据库
Mongo
解决关系数据库强schema约束问题
列式数据库
Hbase
解决关系数据库大数据下的I/O问题
全文搜索引擎
ElasticSearch
解决关系数据库的全文搜索性能问题
高可用架构模式
可拓展性架构模式
架构设计
0 条评论
回复 删除
下一页
