架构其实是经验的累积

前言

• 在很多人眼里架构好像是特别厉害的存在
• 一个好的其实架构是经验的累积
• 不谈场景的架构设计都是耍流氓
• 架构没有对不对，只有合不合适

---

架构与框架的区别

• 架构：系统的宏观设计的标准
• 框架：具体实现的规则

架构师解决问题

问题

• 如：大量文件数据读写 影响到磁盘IO 导致数据库查询出现高延迟

经验较少的架构解决方式：

• 新增redis节点 通过redis高吞吐特性 来完成这些无事物的处理 和数据交互工作
• 京东在618也是采用类似的方案 使用redis 进行数据的持久化与提取工作

缺点

但是对于公司来说 有几点问题

• 1、架构复杂了 多了一个redis中间件，多一个中间件就会多一个可能出问题的风险，并且没有部署redis的哨兵以及集群 一旦节点出现问题系统就崩了 这样做出问题的可能性就增加了
• 2、数据一致性问题 数据存储在redis里面，关系型数据库不支持事物，redis存储的数据 mysql也需要存储一份，那我们又需要解决数据一致性问题

虽然这样可以解决目前的问题但是又给后人埋下许多坑。

经验比较足的架构解决方式

功力深厚，就分析源码，以及从架构来做些调整

1. 在web 容器层面增加拦截器 阻挡重复无效的请求穿透到数据库。如：订单重复提交、频繁请求等 我们可以做幂等性校验
2. 分析业务代码中SQL是否存在全表扫描以及索引选择、慢SQL等问题，我们在全表扫面加入索引加快搜索，加入慢SQL监控 优化SQL
3. 增加InnerDB引擎的Buffer_Pool 缓存池 提高查询的缓存命中率 让查询更多的命中缓存，这样处理时更多的数据直接充内存中提取，不在进行底盘的磁盘IO
4. 在系统层面，解决文件IO问题，增加文件系统的缓存，提高了单次处理的吞吐量，减少文件IO次数。
   这样处理系统没有新增任何组件，就解决了磁盘IO导致查询缓慢的问题

总结：

新架构往往偏向外向行组件解决。

• 就像衣服磨破了，我打个补丁

老架构往往是从问题源头分析问题

• 这件衣服怎么磨破的，新衣服选择更耐磨的面料来杜绝这个问题。

---

• 架构是经验的累积，继续努力吧少年！