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