大型系统容量评估和性能保障（一）

综述：为方便阅读和整体把握，把整个系统性能方面学习整理为四篇，建议按顺序学习，如下：

第一篇（本篇）—架构设计考虑的要素

第二篇—提出的一个需求设计系统

第三篇—对设计的系统进行测试方案

第四篇 —常用的测试工具

===========本文主要内容===========

1，架构设计要素及概念

——核心因素

——非核心因素

2，各服务器的具体参考指标

——应用服务器

——数据库

——缓存

——消息队列

3，记忆方法与总结

==================================

一、架构设计要素及概念

首先说明一下，本模块说的性能及设计都是与项目具体功能无关(或关系不大)，而是从外部考虑设计和性能评估，避免篇幅过长，本模块也不对解决这些问题进行具体说明。

核心考虑的要素有5个：高性能、可用性、可伸缩性、可扩展性、安全性。这几个问题解决了，架构方法的大部分挑战就解决了，下面分别介绍。

1，高性能：一般是单个节点的吞吐量（单位时间内处理的请求量）和响应时间（一个请求出去到回来花费时间）。高性能追求运行效率高、性价比高。

2，可用性：用一个公式衡量，k=（全年时间-故障时间）/全年时间，全年时间有些也用7*24替代，效果都一样。可用性追求可靠、故障/宕机少、可持续好，如一台故障，不影响整体。

3，可伸缩性：用户增加，访问上升，通过增加节点手段缓解高并发和数据存储的能力/也可理解为能否可以构建集群或向集群中添加新的服务器（可以是应用，可以是数据库服务器）解决高并发和数据问题，提高服务能力。可伸缩性追求节点增加，服务能力增加。

4，可扩展性：在系统运行基础上，可添加新业务和新功能。可扩展性追求功能不断扩展，架构能够快速响应。主要手段：解耦，如分布式、消息队列。

5，安全性：服务能防止攻击和数据泄露。安全性追求安全，可靠应对恶意访问。

非核心考虑的要素一般有6个：可监控性、可测试性、可维护性、可重用性、鲁棒性、易用性。下面简单说明：

可监控性：运行的系统能够监控，遇到问题可以定位问题，解决问题，最简单就是日志

可测试性：服务能供提供多个角度测试方法，如：基准，负载等。

可维护性：系统易于监控、运营、扩展。

可重用性：服务模块化，可移植。

鲁棒性：系统容错能性、健壮性、可恢复能力，如集群中的一台故障，服务不受影响。

易用性：用户使用方便，用户体验好。

二、各服务器的具体参考指标

上面从整体上说明一个架构系统的指标。而一个系统性能指标主要看4个部分构成：应用服务器、数据库、缓存、消息队列。

各部分对应性能评估指标分别有三块，部署结构、容量与性能、其他指标，介绍如下：

1，应用服务器：开发的应用部署在这里，是请求的入口。

部署结构指标5个：负载均衡策略、高可用策略、I/O模型（NIO/BIO）、线程池模型及线 程池中线程数量、是否多业务混合部署。

容量和性能大概有10个指标：每天请求量、各接口的访问峰值、平均的请求响应时间、最大请求响应时间、在线用户量、请求大小、网卡I/O流量、磁盘I/O负载、内存使用情况、CPU使用情况。

其他指标：请求内容是否包含大对象、GC收集器的选型和配置。

2，数据库：存储数据。

部署指标：复制模型、失效转移策略、灾难策略、归档策略、读写分离策略、分库分表（分片）策略、静态数据和半静态数据缓存策略、有没有考虑缓存穿透并压垮数据库情况、缓存失效及数据预热策略

容量和性能指标：当前数据容量、每天数据增量、美秒的读/写峰值、美秒事物峰值

其他指标：索引、大数量的查询、有没有多表关联及关联是否使用索引、有没有悲观锁及是否可改为乐观锁及行级锁、事物和一致性级别、使用JDBC数据源类型及连接数配置、是否开启JDBC诊断日志、有没有存储过程、伸缩策略（分区表、自然时间分表、水平分库分表）、水平分库分表实现方法（客户端、代理、NoSQL）

3，缓存：内存存放数据，提高访问速度。

部署结构：复制模型、失效转移、持久策略、淘汰策略、线程模型、预热方法、哈戏分片策略。

容量与性能：缓存内容大小、缓存内容数量、缓存过期时间、缓存数据结构、美秒读写峰值。

其他指标：冷热数据比例、是否有可能发生缓存穿透、是否有大对象、是否使用分布式锁、是否使用缓存支持的脚本Lua、是否避免了Race Condition、缓存分片方法（客户端、代理、集群）。

4，消息队列：实现架构解耦。

部署结构：复制模型、失效转移、持久策略。

容量与性能：每天平均数据增量、消息持久的过期时间、每秒读写峰值、每条消息的大小、平均延迟、最大延迟。

其他指标：消费者线程池模型、哈希分片策略、消息可靠投递、消费者处理流程和持久机制。

三、记忆方法

================= END ==================