目录
架构设计之“道”
架构设计之“术”
系统高性能设计
1）缓存
2）负载均衡
3）读写分离、分库分表
4）分布式文件系统
5）NoSQL数据库
6）服务拆分
7）消息队列
系统高可用、高可靠设计
1）冗余、灾备
2）监控、告警
3）应急预案
4）限流
5）降级
6）熔断
架构设计之“道”
架构设计之“术”
系统高性能设计
1）缓存
使用缓存存储频繁访问的数据，以降低访问数据库、文件系统带来的延迟。其中，应用服务器本地缓存访问速度最快，但容量有限；分布式缓存（如Redis）访问速度次之，容量较大。
为避免滥用缓存资源，可根据业务特性使用以下缓存过期策略：
- 缓存自动过期
- 缓存触发过期（例如在用户登出系统时删除缓存的用户信息）
2）负载均衡
应用服务器部署多个节点（集群化），并利用负载均衡服务器（如Nginx）对外提供服务。
3）读写分离、分库分表
数据库服务器以主备方式部署多个节点，其中主库用于写入数据，备库用于读取数据，主备之间实时同步数据。应用服务器通过中间件（如Sharding-JDBC）访问主从数据库。
分库分表则分为水平切分和垂直切分，水平切分是对一个数据库特大的表进行拆分，例如用户表按用户ID的哈希值切分为若干分表。
垂直切分则是根据业务的不同来切分，如用户业务、商品业务相关的表放在不同的数据库中。
4）分布式文件系统
用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求，这时就需要分布式文件系统的支撑，例如FastDFS。
5）NoSQL数据库
对于海量数据的查询和分析，我们使用 NoSQL 数据库加上搜索引擎可以达到更好的性能。
常用的 NoSQL 有 MongoDB、HBase、Redis，搜索引擎有 Lucene、Solr、Elasticsearch。
6）服务拆分
- 拆分
随着功能的增加，单个应用服务变得越来越臃肿，这时候需要按业务进行拆分，将互不相关的功能拆分为多个子系统，将存在依赖关系的功能拆分为上下游子系统，上下游之间通过RPC接口或者消息中间件（如RocketMQ）通信。
业务拆分作用：提升为子系统可由专人负责，专业的人做专业的事，解决模块之间耦合以及扩展性问题；每个子系统单独部署，避免集中部署导致一个应用挂了，全部应用不可用的问题。
- 定级
根据业务子系统进行等级定义，可分为：
- 核心系统（如用户、产品、订购）
- 非核心系统（如监控、告警、经营分析）
等级定义作用：用于流量突发时，对关键应用进行保护，实现优雅降级；保护关键应用不受到影响。
7）消息队列
使用消息队列，可达到如下效果：
- 异步I/O
利用消息队列的发布-订阅机制，将数据库写入、文件写入等耗时的操作改为异步方式处理，从而大大提高对外接口的响应速度。
- 流量削峰
将突发的大流量请求缓存到消息队列中，避免过高的并发导致下游子系统瘫痪。
- 子系统解耦
利用消息队列的发布-订阅机制，消息生产者只负责发布可能有人感兴趣的消息，消息消费者只订阅自己感兴趣的消息，子系统之间无需调用任何接口即可完成数据的传递，从而实现基于弱关系的松耦合架构。
系统高可用、高可靠设计
1）冗余、灾备
- 负载均衡服务器的冗余部署
为防止负载均衡服务器出现单点故障，可采用主备方式冗余部署。
例如，可使用LVS（Linux虚拟主机技术）+Keepalived技术，实现Nginx服务器的主备部署。
- 应用服务器的冗余部署
应用服务器部署多个节点（集群化），并利用负载均衡服务器（如Nginx）对外提供服务。
当某个应用服务器发生故障时，负载均衡服务器会将外部请求转发到其他应用服务器，使得平台可提供7*24小时不中断的服务。
- 分布式缓存Redis的主备部署
Redis采用高可靠的哨兵集群方式部署；Redis服务开启本地持久化功能，将数据定期同步到磁盘，防止重启服务后数据丢失。
- 数据库的主从部署
数据库采用主从方式部署。主节点提供写操作，从节点提供读操作。主从节点之间实时同步数据。
- 消息中间件的主从部署
消息中间件采用多主多从方式部署。多个主节点组成集群，每个主节点管理消息队列的若干分区；每个主节点拥有一个从节点，用于数据备份。
- 文件的冗余存储
采用分布式文件系统（例如FastDFS）实现文件的冗余存储。
- 数据库、文件的灾备
建设同城或异地的灾备机房，将重要的文件、数据库数据定期备份到灾备机房。
2）监控、告警
对软硬件实施全方位的监控，包括外围设备、网络、服务器负载（CPU、内存、I/O等）、应用服务负载（内存、并发数等）、中间件负载（内存、连接数、并发数等）、各种业务指标（例如某个接口的QPS）等，并对各种指标设定安全边界，当超出安全边界时触发告警。
对告警信息定义不同等级，对应于不同的响应策略。
3）应急预案
针对网络故障、数据库故障等严重故障的告警信息，制定合适的应急预案。
尽可能利用主备容灾机制，自动化切换到备用设备或软件。
当必须人工干预时，需要制定详细的操作指导，防止因人为误操作导致故障影响范围放大。
4）限流
对于核心系统（如用户、产品、订购等），应启用限流机制，防止突发的流量异常导致服务器瘫痪。
限流机制可配合消息队列使用，以起到削峰的效果。
5）降级
针对特定的监控指标异常告警（例如服务器负载超标），可触发自动化的降级机制，优先降低非核心系统（如监控、告警、经营分析）的资源使用率，将服务器资源腾挪出一部分以支撑核心系统的正常运作；或者配合限流机制，减少部分核心系统的入口流量。
业务分级：
可根据收入影响、时间敏感度等指标将业务请求分为多个等级，当系统负荷较高触发告警时，可优先限制低等级业务请求的流量，从而避免影响高等级业务请求的响应速率。
6）熔断
当某个下游子系统的某个微服务发生故障，导致响应严重延迟时，上游子系统应触发熔断机制，防止延迟问题波及到更上游的子系统，造成雪崩效应。
熔断发生后，根据不同的业务场景，可采取不同的处理策略。比如由用户触发的操作可考虑提醒用户稍后重试，由系统内部触发的操作可考虑将请求信息发布到消息队列，交给特定的子系统进行重试。
