原文地址：https://www.douyacun.com/article/f3001599ffb501015479de963e377bcf

高并发通用设计方法

• 分流
• 缓存
• 异步

架构分层

为什么分层

• 简化系统设计，让不同的人专注某一层
• 分层提高复用性
• 分层更容易横向扩展

如何分层

• 客户端显示层
• 网关层
• web层 一般参数校验 ，validate的封装
• service层
  • 业务封装
  • 复杂业务验证，依赖数据库存值得验证逻辑
• manager
  • 通用逻辑
  • 第三方接口的封装
• DAO数据存储层

todo:各层功能界限不明确

系统设计目标

高并发设计三大目标

• 高性能
  • 响应时间 毫秒级
  • QPS
• 高可用
  • 稳定性
• 可扩展
  • 快速应对峰值流量

高性能

性能优化原则

• 问题导向
• 八二原则：20%精力解决80%的性能问题
• 数据支撑：数据监控，时刻了解性能优化以后响应时间减少了多少，提示了多少吞吐量
• 制定目标，持续优化，业务逻辑复杂的系统，也会有多方面的问题

性能度量指标

吞吐量 和 响应时间

99分位值的响应时间控制在200ms以内，不超过1s请求占比控制在99.99以内

平均值 少量的慢请求无法反映

最大值 过于敏感

分位值 能很好反应一段时间的性能状况，例如90分位(100个请求响应时间排序，排在90的就是分位点)，分位值越高，对于慢请求越敏感

性能优化

• 增加系统的核数
• 减少单次请求时间
  • linux性能分析工具
    • cpu
    • memory
    • i/o
  • go pprof

高可用

系统无故障运行的能力，系统可用行需要从系统设计和系统运维来保证

系统设计

系统设计时考虑如何自动化发现故障，出现故障如何解决。具体的优化方法故障转移、超时控制、限流

故障转移：

• 检测主备机器是否故障，心跳检测 ping，定时请求，一段时间没有响应，判定机器故障，报警并触发选主操作
• nginx 异常重试

proxy_next_upstream

超时控制： 不让请求一直保持，经过一段时间后让请求失败，释放资源

内网服务

• 连接超时100 - 300ms
• 读超时 1- 3s

降级: 保证核心服务的稳定而牺牲非核心服务的做法

限流: 对并发请求进行限速来保护系统

系统运维

运维可以从灰度发布，故障演练来考虑提升系统的可用性

灰度发布： 业务稳定运行过程，系统是很少发生故障，90%的故障时发生在上线变更阶段，除了提供回滚方案就是灰度发布

故障演练： 模拟线上事故,比如：在线上随机关闭节点

可扩展

系统扩展会增加系统设计的复杂度，设计思路有：存储层扩展、业务层扩展

易扩展得复杂性

• mysql存储瓶颈
• 带宽的瓶颈
• 第三方依赖的瓶颈

存储层扩展

第一步 做业务服务化拆分，减少单一主库压力

第二步 系统运行一段时间后，单一的业务数据库仍然会超过在容量和请求量仍然会超过单机的限制，这次就需要按数据特征做水平拆分，问题时节点不是随意增加的

业务纬度拆分

• 按业务纬度拆分，各服务独立部署，拥有独立的数据库
• 按业务重要程度进行分级，流量激增时优先扩容核心业务，保证稳定性