《架构真经》笔记

《架构即未来》和《架构真经》是架构姊妹篇，本来想两本都买来学习，但是《架构即未来》看了一下目录，感觉偏“道”一些，理解和应用有些难度，没有《架构真经》的实战性这么强。以下内容是基于《架构真经》中的一些架构原则做了整理，方便阅读。

架构设计原则.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