插话：系统设计是一个不断迭代的过程，在迭代过程中发现问题并修复问题，这是一个持续的过程，目前没有什么完美架构银弹，场景、时间不同，即使相同的需求系统设计也会不同。
但是如果设计系统前，能有一些好的基础系统设计能力，能够让你在未来更容易达到一个比较满意的目标
一个好的设计要做到，解决现有的需求和问题，把控实现和进度的风险，预测和规划未来，但不要过度设计，在迭代中演进和完善

12306型系统设计 - 只是一些原则，并不是规定，可自行根据自己的业务场景拆分和组合

1. 高并发原则
   1. 无状态 - 可简单理解无共享资源
   2. 服务拆分
   3. 分布式服务化
   4. 消息队列
   5. 数据异构
   6. 缓存银弹
   7. 并发话
2. 高可用原则
   1. 降级
   2. 限流
   3. 切流量
   4. 可回滚

• 无状态：可简单理解无共享资源，如果设计的应用是无状态的，那么应用比较容易进行水平扩展。像数据源这种就是有状态的，这时可通过配置文件或配置中心指定，方便应用水平扩展
• 服务拆分：一般刚开始用户量不大的时候，为了快速开发业务，基本所有的功能都是在一个系统中，当随着业务快速发展，用户量渐渐增多，系统越来越庞大，快速迭代就变得越来越不现实了，有时候为了开发一个小功能，可能会造成牵一发动全身，因此就需要进行服务拆分，一般拆分的考虑维度如下几种
  • 系统维度：按照系统功能／业务拆分
  • 功能维度：对一个系统进行功能再拆分。比如：抽奖系统可以拆分为后台创建奖品系统、奖品发放系统等
  • 读写维度：根据读写比例拆分。比如商品系统，可以拆分成商品读服务，商品写服务，不同的服务设计不同
  • AOP维度：根据访问特征，按照AOP进行拆分。比如。商品详情页可以分为CDN、页面渲染系统
  • 模块维度：按照基础或者代码维护特征进行拆分。代码结构一般按照三层架构（Web、Service、DAO）进行拆分
• 分布式服务化：
• 消息队列：使用消息队列可以实现服务解耦、异步处理、流量削峰／缓冲等
• 数据异构：
  • 数据异构：订单分库分表使用订单ID做分片策略，这时有通过用户ID进行查询，每次都要对所有表进行查询并聚合数据，效率太低，可通过数据异构解决，耦合一份数据使用用户ID做分片策略，简单就是用数据耦合的方式解决该问题
  • 数据闭环：当一个页面需要查询10几个接口才能完整的显示，可以通过将这10几个接口的数据聚合起来存储，这样前端只需要调用一次即可完成展示
• 缓存银弹：
  • 浏览器端缓存
  • APP客户端缓存
  • CDN缓存
  • 接入层缓存
  • 应用层缓存
  • 分布式缓存
• 并发化：比如一个接口中需要调用很多个接口，尽量将这些接口并行化，而不是串行调用

• 降级：降级思路如下：
  • 开关集中化管理
  • 可降级的多级读服务：比如服务抵用降级只读本地缓存、只读分布式缓存、只读默认降级数据
  • 开关前置化：比如可以在前端请求时就消减流量
  • 业务降级：保障核心接口，将一些非核心接口直接关闭或者不处理
• 限流：限流的目的是防止恶意请求流量、恶意攻击、或者防止流量超出系统的峰值。可参考如下思路-越早限流越好
  • 恶意请求的流量只访问到cache
  • 对于穿透到后端的应用流量可以考虑使用一些 limit 的技术
  • 对于恶意IP可使用nginx 进行屏蔽
• 切流量：
  • DNS
  • HttpDNS
  • LVS/HaProxy
  • Nginx
• 可回滚:当程序或者数据出现问题时，如果有版本化机制，那么就可以通过回滚恢复到最近一个正确的版本，比如事物回滚、代码库回滚、部署版本回滚、数据版本回滚、静态资源版本回滚等。通过回滚机制可保证系统某些场景下的高可用

设计系统时，应多思考墨菲定律

1. 任何事都没有表面看起来那么简单
2. 所有的事都会比你预计的要长
3. 可能出错的事总会出错
4. 如果你担心某种情况会发生，那么它就更有可能发生

系统划分时，应多思考康威定律

1. 系统架构是公司组织架构的反映
2. 应该按照业务闭环进行系统拆分／组织架构划分，实现闭环／高内聚／低耦合，减少沟通成本
3. 如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整
4. 在合适时机进行系统拆分，不要一开始就把系统／服务拆分的非常细，虽然闭环，但是每个人维护的系统多，维护成本高