架构设计原则
2020-01-07 13:55:34 2 举报AI智能生成
提供架构设计思路，覆盖架构、分布式、数据库、故障容灾等方面
作者其他创作
大纲/内容
数据库
评估规则
数据量、存储量
响应时间长短
关系
关注明锁和监控暗锁
最大化数据库并发和吞吐量
禁用分阶段提交事务
容易阻塞其它事务
永远不要为确认操作是否有效而读取刚刚写入的数据
no sql
no select for update
no select *
缓存设计
利用CDN缓存
加快访问速度
动静分离
http header
max-age
Expires
cache-control
Last-Modified
ETags
应用缓存
缓存命中率>85%
分布式系统设计
CAP要求不能同时满足
一致性C
从客户角度看，一组操作同时发生
可用性A
每个操作必须都能收到预期的响应
分区容错性P
即使个别消息丢失，操作仍然可以完成
解决
BASE思想
基本可用BA
软状态S
最终一致E
放宽时间约束
放宽一致性可以使我们在解决扩展问题时有更大的灵活性
无状态实施方案
方案设计
采用帕累托原则简化范围
80-20原则，收益的80%来自于20%的工作
考虑成本优化和可扩展性简化设计
扩展性设计
DID方法
Implement(I) 实施3倍的容量
Design(D) 设计20倍的容量
Deploy(D) 部署1.5倍的容量
依靠其他人的经验来简化部署
拆分和扩展
水平扩展(X轴)
复制服务或者数据库分散事务处理负载
数据库读写分离
多部署服务实例
事务的ACID属性
原子性 Atomicity
一致性 Consistency
隔离性 Isolation
持久性 Durability
拆分(Y轴）
垂直拆分，面向数据或者服务
服务拆分，例如拆分会员、商品、积分等
拆分(Z轴)
分片，把数据或者服务分割成几块
例如扩大客户基数，按照用户ID取模或者散列算法分片
数据分片，理论上可以无限扩存储
避免工具被过度使用
缺乏实验和使用新技术的勇气，结果导致工具被锁定和过渡使用
我们都试图使用熟悉的工具解决问题，类似技能的人员解决仍然会得到一致的答案，过度
需要拿出一部分资源主动分析、试验和采用新工具
花时间学习新事物，保持开放心态
避免过度设计
通过测试人员是否能够轻松的理解解决方案来验证
过度设计分类
产品的设计和实施超过实际的需求
把事情做得过于复杂和以复杂的方式去实现
好工程师的度量
多快简化一个复杂的问题，然后构思出一个易于理解并可以维护的解决方案
流量风险
空前极具增长的大量用户请求
用户行为都集中在少数热点上
发现问题
从失败而不是成功中能学习到更多的东西
若隐藏失败，结果必然是反复失败
观察客户或用A/B Test验证
QA的作用以较低成本发现问题
提升工程速度和增加缺陷检出率
QA不提升质量
代码评审和测试驱动开发(TDD，提前编写测试代码)可以提升质量
代码支持回滚能力
大部分回滚问题出现在数据库
数据库结构的变更仅可以增加，而不应该删除列或者表
测试
单元测试
系统测试
回归测试
完全自动化
故障
设立故障隔离域建立“泳道”
不允许跨越泳道边界进行同步调用
例如支付网关，每个客户独立网关泳道
沿物理服务器边界划分泳道
消除单点故障(SPOF)
避免系统串联
串联电路和并联电路的优劣势
减少串联组件或增加并联组件降低故障风险
增加上下线开关
监控
监控目的
1)有问题吗？
2)问题在哪里？
3)有什么问题？
监控内容
应用监控
告警无法确定对于客户的实际影响
业务监控
硬件监控
监控预测问题是否可能发生
控制图的统计工具
神经元网络或贝叶斯网络这样的机器学习算法
日志
使用自动化的工具监控日志
ELK
检索目标行、统计错误
超过预警阈值告警
日志是监控、事件管理、应用调试的重要工具
数据中心
系统部署3个或更多活的数据中心
使用云平台来解决突发增长
双活迁移三活数据中心，云可做第三数据中心
批量处理、测试环境、或者峰值容量，可以考虑放云环境
分析
归纳
是从数据中形成假设的过程
演绎
是对数据进行假设检验以确定有效性的过程
数据梯级存储策略
RFM方案
Recency 数据多久前被访问过
近因
Frequency 数据多久被访问一次，即数据访问频率
频率
Monetization 特定数据对业务的价值
货币化分析
存储数据无价值
不被访问的时间越久
访问的频率越低
数据对业务价值越低
风险评估模型
风险=问题发生的概率*发生的影响
发生的影响
服务不可用时间/数据损失百分比/受影响的响应时间
影响的百分比
影响客户的百分比
受影响功能的百分比
浏览器访问
减少域名解析
浏览器对每个服务器或者网关代理的最大持久并发连接数有限制
不要把所有对象放在同一个域里
减少页面元素
浏览器允许每个子域名拥有自己的最大并发连接数
通过添加域名最大化并发连接数量
gzip压缩
重定向
重定向使用服务器配置实现，避免代码的解决方案
重定向不利于搜索引擎收录
http状态码 301/302
使用cookie保存会话数据
cookie越大，页面加载速度越慢
使用https发送cookie
硬件网络
采购
尽可能采用小型廉价的硬件
处理器最多最大的设备往往是利润最高
防火墙
不要用在低价值的静态内容防护上
防火墙失败是仅次于数据库的第二大网站瘫痪黑手
异步通信
非关键请求
请求以非阻塞方式发出，而且调用方不阻止等待响应
与MQ交互调用注意异步
使用原则
外部API/第三方调用
长期运行的进程
进程长时间运行容易缓慢
经常改变且易出错/过于复杂的方法
避免将关键代码与复杂而且经常改变的代码捆绑在一起
时间约束
两个进程之间不存在时间约束，列如注册成功和发送邮件，不能耽误注册页面结果反馈给用户
同步调用方式必须设置超时
0 条评论
下一页
