系统设计的步骤

• 系统设计面试：内幕指南链接

系统的需求

• 功能性需求
  • 系统包含哪些功能
• 非功能性需求
  • 性能和QPS，TPS等

对系统进行抽象设计

考虑系统目前需要优化的点

系统设计三要素

• 高性能架构设计：熟悉系统常见性能优化手段比如引入读写分离、缓存、负载均衡、异步等
• 高可用架构设计：CAP理论和BASE理论，通过集群来提高系统的稳定性、超时和重试机制、应对接口级的故障：降级、熔断、限流、排队
• 高扩展架构设计：如何拆分系统和模块，尽可能做到低耦合高内聚

一些常见软件的QPS

• Nginx： 30w+
• redis : 单机QPS 8W+
• mysql： 单机QPS 4k
• Tomcat： 单机 2w

高性能

热点数据的处理

• 热点数据的分类
  • 静态热点数据：可以提前预测到的热点数据比如要秒杀的商品
  • 动态热点数据： 不能够提前预测的热点数据，需要通过一些手段动态监测系统运行情况产生
• 问题的关键在于如何找到这些热点数据，然后将它们存在jvm内存中。

静态资源的处理

• CND

高可用

• 集群化
• 限流
  • 接口限流
  • 对用户、IP限流
• 问题，验证码
  • 降低用户的请求频率
• 提前预约
• 流量削峰
• 降级
  • 根据当前业务情况，对一些服务和页面进行有策略的降级
• 熔断

高可用的七大原则

• 少依赖原则：能不依赖的，尽可能不依赖，越少越好
• 弱依赖原则： 一定要依赖的，尽可能弱依赖，越弱越好
• 分散原则：鸡蛋不要放一个篮子，分散风险
• 均衡原则： 均匀分散风险，避免不均衡
• 隔离原则： 控制风险不扩散，不放大
  • 隔离是有级别的，隔离级别越高，风险传播扩散的难度就越大，容灾能力越强
  • 是以上原则的前提，隔离没做好，上面四个原则都是收效甚若的
• 无单点原则: 要有冗余或其他版本,做到有路可退
  • 快速止血的方式是切换，回滚，扩容等；回滚和扩容属于特殊的切换，回滚指的是切换到某个版本，扩容指的是将流量切换到新扩容的机器上。
  • 无单点原则和分散原则的区别：
    • 当节点无状态的情况下，打散拆分成N份，每份都是相同的功能，互为冗余，即：节点无状态情况下，分散原则和无单点原则等价，满足一个即可。
    • 当节点有状态的情况下，打散拆分成N份，每份都是不相同的，每份都没有冗余，需要针对每份再做冗余，即：节点有状态情况下，既要满足分散原则又要满足单点原则
• 自我保护原则： 少流血，牺牲一部分，保护另外一部分

软件系统风险的来源

• 系统资源的变化
  • 系统运行所依赖的服务器资源（如CPU，MEM，IO等），应用资源（RPC线程数，DB连接数等），业务资源（业务ID满了，余额不足，业务额度不够等）的负载等都会影响系统运行的风险期望。
• 存储系统变化
  • 系统运行所依赖的服务器资源（如CPU，MEM，IO等），存储资源（并发数等），数据资源（单库容量，单表容量等）的负载和数据一致性等都会影响存储系统运行的风险期望。
• 人的变化：变更出错
• 硬件变化：损坏
• 上游变化：请求变化
  • 网络流量过大会造成网络堵塞，影响网络通道中的所有网络流量请求
  • API请求过大会造成对应服务集群过载，影响整个服务机器上的所有API请求，甚至往外传播。
  • KEY请求过大（俗称“热点KEY”）会造成单机过载，影响单机上所有KEY请求，甚至往外传播。
• 下游变化： 响应变慢，响应错误
  • 下游服务的数量，服务等级，服务可用率等影响下游服务的风险期望。下游响应变慢可能会拖慢上游，下游响应错误可能会影响上游运行结果。
• 时间变化：
  • 时间到期往往被人忽视，但它往往具有突然性和全局破坏性，一旦时间到期触发故障会导致非常被动，所以要提前识别，尽早预警，如：秘钥到期，证书到期，费用到期，跨时区，跨年，跨月，跨日等。

一致性

• 接口幂等

系统设计的原则

• 原则一：关注于真正的收益而不是技术本身
  • 关于收益的定义
    • 是否可以降低技术门槛加快整个团队的开发流程
    • 是否可以让整个系统运行的更稳定，是否可以提升真个系统的SLA
    • 是否可以通过简化和自动化降低成本，成本关注度从高到低分别为人力成本，时间成本，资金成本
• 原则二：以应用服务和API为视角，而不是以资源和技术为视角
  • 现在很多技术和组件已经分不清是dev还是Ops了，所以需要合并Dev和Ops
• 原则三: 选择最主流和成熟的技术
• 原则四：完备性比性能更重要
  • 使用最科学严谨的技术模型为主，并以不严谨的模型作为补充
  • 性能上的东西都是多解的
• 原则五：制定并遵循服从标准、规范和最佳实践
• 原则六：重视架构扩展性和可运维性
  • 微服务架构的一些建议
    • 所有团队的程序模块都要以通过Service Interface方式将其数据与功能开放出来。
    • 团队间的程序模块的新系通信都要通过这些接口
• 原则七：对控制逻辑进行全面收口
• 原则八：不要迁就老旧系统的技术债务
• 原则九：不要依赖自己的经验，要依赖于经验和学习
• 原则十：千万要小心X - Y问题，要追原始需求
• 原则十一： 激进胜于保守，创新与使用并不冲突