首页 存档 技术 查看内容

互联网性能与容量评估的方**和典型案例 五、性能评估参考标准

2018-3-30 13:00 |来自: 互联网 297 0

摘要: 作者丨李艳鹏,支付平台架构师 主页丨http://www.jianshu.com/u/581f548ef0ec 一、背景 武林中,“天下武功出少林”指中国各门各派的武功都与少林武学有一定的渊源,技术也是相同的道理,所有的技术最终体现在计算 ...

作者丨李艳鹏,支付平台架构师

主页丨http://www.jianshu.com/u/581f548ef0ec


一、背景

武林中,“天下武功出少林”指中国各门各派的武功都与少林武学有一定的渊源,技术也是相同的道理,所有的技术最终体现在计算机知识的基本功上,这些基本功是技术的易筋经,是“内功”,一些年轻的攻城狮更热衷于追崇高大上的框架,过去在炒SSH,现在在炒Spring Cloud,这些对框架掌握的程度体现在“剑术”上,我推荐每个技术研发人员在修炼好内功的基础上,再去练“剑术”。回头看IT行业的发展,先有传统行业,再有互联网,传统行业和互联网是少林与武当的关系,他们的技术相辅相成,并不一定是互联网的技术要比传统行业的技术高深很多,而是它们有自己的侧重点,传统行业更偏向于企业级开发,项目具有业务复杂、流程丰富、中心化管理、企业级抽象度高、业务重用率高的特点,而互联网倾向于把复杂的业务进行拆分成单一的职责,对于单一职责模块的非功能质量进行大幅度的优化,这包括高可用性、高性能、可伸缩、可扩展、安全性、稳定性、可维护性、健壮性等。

这篇文章提供一个基本的面向互联网技术评审的方法论,它主要论述在互联网的行业里,如何在完成产品功能的前提下,更好的满足非功能质量的需求,是每个互联网程序设计人员和架构设计人员都应该掌握的一项基本技能。

本文的目的是为了初入互联网或者有意愿踏入互联网的研发人员起到抛砖引玉的效果,如果想全面了解互联网非功能质量设计的方方面面,可以参考美国互联网方法论Architecture Tradeoff Analysis Method:http://www.sei.cmu.edu/architecture/tools/evaluate/atam.cfm,相关的书籍可以从这里下载ATAM: Method for Architecture Evaluation:http://cloudate.net/?page_id=1604

二、目标

2.1 非功能质量需求的概述

通过参考技术评审指标,保证系统架构设计满足用户和系统对非功能质量的需求:

核心非功能质量:

核心质量 描述
高性能 运行效率高,性价比高
可用性 持续可用性,缩短宕机时间,出错恢复,可靠性
可伸缩 垂直伸缩,水平伸缩
可扩展 可插拔,组件重用
安全性 数据安全,加密,熔断,防攻击

其他非功能质量:

其他质量 描述
可监控性 快速发现,快速定位,快速解决
可测试性 可灰度,可预览,可Mock,可拆解
鲁棒性 容错性,可恢复性
可维护性 易于维护,监控,运营,扩展
可重用性 可移植性,解耦
易用性 可操作性

2.2 非功能质量需求的具体指标

主要分为4部分:应用服务器、数据库、缓存和消息队列。

2.2.1 应用服务器

应用服务器是服务的入口,请求流量从这里进入系统,数据库,缓存和消息队列的访问量取决于应用服务器的访问量,对应用服务器的访问量进行评估至关重要,应用服务器主要关心每秒请求的峰值,请求响应时间等指标,通过这些指标可以评估需要的应用服务器资源的数量。

全面考虑下列指标:

指标分类 部署结构 容量和性能 其他
1 负载均衡策略 每天请求量 请求的内容是否包含大对象
2 高可用策略 各接口访问峰值 GC收集器的选型和配置
3 IO模型(NIO/BIO) 平均请求相应时间
4 线程池模型 最大请求相应时间
5 线程池线程数量 在线用户量
6 是否多业务混布 请求大小
7
网卡IO流量
8
磁盘IO负载
9
内存使用情况
10
CPU使用情况

2.2.2 数据库

根据应用层的访问量和访问峰值,计算出需要的数据库资源的QPS,TPS,每天的数据总量等,由此来评估所需数据库资源的数量和配置,部署结构等。

全面考虑下列指标:

指标分类 部署结构 容量和性能 其他
1 复制模型 当前数据容量 查询是否走索引
2 失效转移策略 每天数据增量(预估容量) 有没有大数据量的查询
3 容灾策略 每秒读峰值 有没有多表关联,关联是否用到索引
4 归档策略 每秒写峰值 有没有使用悲观锁,是否可以改造成乐观锁,或者是否可以利用数据库内置行级锁
5 读写分离策略 事务量 事务和一致性级别
6 分库分表(分片)策略
使用的JDBC数据源类型,连接数等配置
7 静态数据和半静态数据是否使用缓存
是否开启JDBC诊断日志
8 有没有考虑缓存穿透压垮数据库的情况
有没有存储过程
9 缓存失效和缓存数据预热策略
伸缩策略(分区表,自然时间分表,水平分库分表)
10 缓存失效和缓存数据预热策略
水平分库分表实现方法(客户端,代理,Nosql)

2.2.3 缓存

根据应用层的访问量和访问峰值,通过评估热数据占比,计算出的缓存资源的大小,存取缓存资源的峰值,由此来计算所需缓存资源的数量和配置,部署结构等。

全面考虑下列指标:

序号/指标分类 部署结构 容量与性能 其他
1 复制模型 缓存内容的大小 冷热数据比例
2 失效转移 缓存内容的数量 是否有可能缓存穿透
3 持久策略 缓存内容的过期时间 是否有大对象
4 淘汰策略 缓存的数据结构 是否使用缓存实现分布式锁
5 线程模型 每秒读峰值 是否使用缓存支持的脚本
6 预热方法 每秒写峰值 是否避免了Race Condition
7 分片Hash策略
缓存分片方法(客户端,代理,集群)

2.2.4 消息队列

根据应用层的访问量和访问峰值,计算需要消息队列传递的数据内容和数据量,计算出的消息队列资源的数量和配置,部署结构等。

全面考虑下列指标:

指标分类 部署结构 容量与性能 其他
1 复制模型 每天平均数据增量 消费线程池模型
2 失效转移 消息持久的过期时间 分片策略
3 持久策略 每秒读峰值 消息的可靠投递
4
每秒写峰值
5
每条消息的大小
6
平均延迟
7
最大延迟

三、技术评审提纲

业务项目千差万别,没有一个统一的方法论完成架构设计和技术评审,架构设计只需要从某些关键点来表达系统即可,提纲就是用来帮助大家做架构评审的工具,帮助大家整理思路并形成可实施的方案,因此在做系统设计时,可有选择性的参考此提纲,根据业务特点来完成一个可实现的有效的架构设计。

3.1 现状

业务背景

  • 项目名称

  • 业务描述

技术背景

  • 架构描述

  • 当前系统容量(系统调用量平均值)

  • 当前系统调用量峰值

3.2 需求

业务需求

  • 要改造的内容

  • 要实现的新需求

性能需求

  • 预估系统容量(预估系统调用量平均值)

  • 预估系统调用量峰值

  • 其他非功能质量,例如:安全性、可伸缩等

3.3 方案描述

方案1

整个方案需要参考技术评审指标提出的各方面指标来考虑满足系统的非功能质量需求。

  • 概述

    一句话概括方案的亮点,比如说: 双写,主从分离,分库分表,扩容,归档等。

  • 详细说明

    方案的具体描述,文字描述不清楚的话可以结合图(任何图:UML,概念图,框图等)的方式说明,如果是改造方案最好突出变动的地方,以下列举了几种描述的角度:

    • 中间件架构(应用服务器、数据库、缓存、消息队列等)

    • 逻辑架构(模块划分、模块通信、信息流、时序等)

    • 数据架构(数据结构、数据分布、拆分策略、缓存策略、读写分离策略、查询策略、数据一致性策略)

    • 异常处理,容灾策略,灰度发布

  • 性能评估

    给出方案的基准数据,并按性能需求评估需要使用的资源数量。

    • 单机并发量

    • 单机容量

    • 按照预估性能需求,预估资源数量(应用服务器、缓存、存储、队列等)

    • 伸缩方式

  • 方案优缺点

    列出方案的优缺点,优缺点要具有确定性,不要有“存在一定风险”这种描述,也就是要量化。

方案2

整个方案需要参考技术评审指标提出的各方面指标来考虑满足系统的非功能质量需求。

......

3.4 方案对比

对比可选方案,并给出选择这种方案的理由,选择倾向的方案,

3.5 风险评估

标识所选方案的风险,提出解决此风险发生时候的应对策略,比如:上线失败时的回滚策略。

3.6 工作量评估

描述使用所选方案需要做的具体工作,并评估开发、测试等细化任务需要的时间,形成可实施的任务计划表,任务计划表推荐采用简单的表格形式,减少工具使用和学习的成本。

四、性能和容量评估经典案例

4.1 背景

物流系统包含如下两个质量优先需求:

  1. 维护会员常用地址,下单时提供会员地址列表。

  2. 下单时异步产生物流订单,物流系统后台任务从第三方物流轮循拉取物流状态,已经下单用户查询订单的物流订单和物流记录。

由于会员数量较大,可能有较快的增长速度,订单数量更是巨大,促销期峰值的订单产生量可能很高,这两个业务模块的数据存储需要分库分表,并借助消息队列和缓存抗写和读的流量,因此,本方案主要涉及这两个业务的容量评估。

4.2 目标数据量级

声明:文章版权归原作者所有 部分文章转自互联网 如有侵权请联系 [邮箱地址] 删除

路过

雷人

握手

鲜花

鸡蛋

相关分类

返回顶部