系统稳定性

1.重要接口 2.重要场景 3.压测方案 4.构造测试数据 5.去掉免登去模拟请求，压测自己的接口 6.评估压测 历史高峰值三倍 或预估流量三倍 7.执行压测，线上服务器 8.晚上10点以后 9.压测时关注 系统监控，业务监控，cpu,内存，容量上限 压到系统报警 10.整理压测报告 11.压测接口列表 rt,内存，cpu 12.提交审核前提前沟通，有没有问题 常见问题： 1.慢sql,sql包含业务逻辑，多表联合查询，索引不合理，使用like 统计可以用like，主业务不能用like,不用select *,只查单表 2.读写比高的用redis,秒杀分布式锁，不要用数据库，用redis 统计数据不用数据库实时查，用定时服务 3.内部服务调用用prc,不用http 4.静态资源 5.资源消耗到ecs,别消耗到数据库中，数据库扩容比较麻烦，ecs更容易扩容 6.http也是有连接池的 来源： https://www.cnblogs.com/liuqiyun/p/12509534.html

九、网站高可用建设：大型网站的稳定性建设 稳定性是决定网站生死的命脉 1、故障带来的影响 导致极差的用户体验、严重影响公司声誉 2、网站的可用性指标 网站可用性即网站正常运行时间的百分比，业界用N个9来量化可用性，最常说的是“4个9（99.99%）”。 网站可用性如果对达到4个9基本上就算及格了，即网站一年的不可用时间不超过52分钟。为了保障整个网站的全部服务完全不出错，有必要对服务进行分级，以保障服务的高可用性。 3、稳定性建设思路 稳定性的建设，有两个重要因素：一是思想上重视，开发人员对稳定性的重视可以避免70%-80%的故障；二是规范和工具的建设，用以保障稳定性。 架构阶段的稳定性建设项目：避免单点、分组隔离、异地容灾。 编码阶段的稳定性建设：错误捕获、异步线程、超时处理、限流保护。 测试阶段的稳定性建设：自动化对比测试、Beta测试。 发布阶段的稳定性建设：分批发布、多版本发布。 运行阶段的稳定性建设：实时监控报警、过载保护和自动降级、实时数据对账。 故障发生时的稳定性建设：故障定位、快速恢复。 4、高可用体系化建设 包括压测体系、管控体系、监控体系、恢复体系和度量体系。 压测体系：分为单系统压测和全链路压测。 全链路压测的技术难度并不大，技术手段主要由流量的制造、流量的标记、测试数据的处理。 管控体系主要是遇到一些异常情况时提供保护系统的措施，包括开关系统、预案系统

修改时间 修改内容 修改人 2016.6.20 创建 刘永志 2016.6.29 完成 刘永志 Monkey 简介： Android SDK 自带的命令行测试工具，向设备发送伪随机事件流，对应用程序进行进行稳定性测试。 Monkey 的优势与缺陷： 优势： 脱离Case的依赖 可封装自动化执行 可封装后作为客户端性能测试的驱动 缺陷： 完全随机，不可控 不支持IOS系统 Monkey 命令及参数： 基本语法如下： $ adb shell monkey [ options ] < event - count > 如果不指定options，Monkey将以无反馈模式启动，并把事件任意发送到安装在目标环境中的全部包。下面是一个更为典型的命令行示例，它启动指定的应用程序，并向其发送500个伪随机事件： $ adb shell monkey - p your . package . name - v 500 一些常用的参数信息。 Category Option Description General --help Prints a simple usage guide. 获取帮助信息。 -v Each -v on the command line will increment the verbosity level. Level 0 (the default) provides little

Sentinel 是什么？ 随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。 Sentinel 具有以下特征: 丰富的应用场景 ：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 完备的实时监控 ：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。 广泛的开源生态 ：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 完善的 SPI 扩展点 ：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 以上是官网对sentinel的一个介绍，本篇文章不讲原理，只讲搭建和使用。官网: https://github.com/alibaba/Sentinel/ 正式开始之前我们先来看一下sentinel提供的dashboard界面： 通过 https:/

在微信公众号上偶然看到一篇关于如何进行稳定性测试的文章，文章标题为 “面试官说：请你说一下软件稳定性怎么测试”， 在此转载分享： https://mp.weixin.qq.com/s/u3VEmGX7GbbkFEVeMTRkpw 1.对软件多次测试，长时间运行，是否正常运行 2.长时间对软件开启关闭软件和系统是否正常 3.软件长时间执行某个业务后切换到别的不同的业务操作是否受影响 4.软件长时间开启但是不执行任何操作，然后检查能否正常执行业务操作 5.软件长时间对日常的用户数进行操作运行，观察系统内存占用率是否越来越大，可用内存是否减少，内存是否溢出，饱和运算内存是否占用过大、是否溢出 6.软件长时间开启正常运行，观察系统CPU是否使用率是否越来越高,在饱和运算时,观察系统cup使用率，饱和运算结束时，CPU使用率能否回到正常值 7.在系统运行过程中，对系统饱和施压，观察系统的各种性能指标，以及服务器的指标、观察服务器电源电压是否降低、机箱、内存、硬盘、CPU等硬件指标来观察系统的稳定性 8.模拟平常的压力，模拟实际中日常的用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写 9.模拟饱和压力测试，模拟实际中日常最大用户数进行操作。要存、取、建、查数据，验证数据库是否正常读写，系统运行是否受影响 10.多个关联软件，存在接口访问数据交流，关闭其中的一个软件

1. Monkey是什么 Monkey 是一个运行在模拟器或者Android设备中可以产生类似用户点击、触摸、手势以及一些系统级的伪随机事件流的程序。我们可以通过命令让monkey向模拟器或者Android设备发送伪随机事件流来对我们开发的App进行压力测试。 1.1. Monkey程序由Android系统自带，使用Java语言写成，在Android文件系统中的存放路径是： /system/framework/monkey.jar，包名：com.android.commands.monkey.Monkey； 1.2. Monkey.jar程序是由一个名为“monkey”的Shell脚本来启动执行，shell脚本在Android文件系统中 的存放路径是：/system/bin/monkey； 内容为： # Script to start "monkey" on the device, which has a very rudimentary # shell. # base=/system export CLASSPATH=$base/framework/monkey.jar trap "" HUP exec app_process $base/bin com.android.commands.monkey.Monkey $* app_process是Android的系统启动进程

稳定性测试的概念有2种， 一， 稳定性测试，对应于异常性测试，即发生异常情况时，系统如何反应的测试。包含： 　　1 交互性测试，被打扰的情况，如来电，短信，低电量等。这些其实在上章的功能测试中有提到。 　　2 异常性测试，断网，断电，服务器异常等情况 二，稳定性测试指的是性能测试，压力测试 　　2 大数据测试，在特定环境下，客户端一次性更新大量数据及人员列表 另有其它文章，提到性能测试，为评估APP的时间和空间特性（真是高深啊，时间和空间，再来个4维，5维？），包括： 　　1 极限测试：在各种边界压力情况下，如电池，存储，网速等，验证app是否能正确响应 　　--内存满时安装app 　　--运行app手机断电 　　--运行app时断掉网络 　　这几点倒是与第一条的内容重复 　　2 响应能力测试：测试app中的各类操作是否满足用户响应时间要求 　　--app安装 ，卸载的响应时间 　　--app各类功能性操作的影响时间 　　3 压力测试：反复、长期操作下，系统资源是否占用异常 　　--app反复进行安装卸载，查看系统资源是否正常（弄个几次就行吧，正常人，谁反复安装卸载啊） 　　--其它功能反复进行操作，查看系统资源是否正常（这倒是应该的） 　　4 性能评估：评估典型用户应用场景下，系统资源的使用情况 　　这里要定义，什么是典型用户应用场景 　　5 benchmark测试（基线测试）

面试题： 假如您是公司架构师，如何设计高性能，高并发，高可用的系统？ 1，使用微服务框架，抽离出高并发的业务，做单独部署； 2，区分高cpu和高io场景，使用流行的中间件技术，分散系统压力，比如nginx负载，队列技术、redis等削峰； 3，在业务划分方面采用最小流程原则，区分实时和非实时业务进行编码指导； 4，接口设计，遵循单一职责原则，保证接口的高效和扩展性； 5，在系统中集成接口检测框架，持续检测主要业务场景的方法、接口性能； 6，结合业务场景，考虑设计数据库，保证可扩展性和表查询高效性； 思路，为保证系统高性能，高并发，高可用。 按照软件和硬件分，分两方面；按照微观和宏观分也分两方面。 主要是结合业务场景，系统流量，公司可投入资源等做有针对性的规划和实施。 参考文章： 高性能高并发系统的稳定性保障 该文章有很多干货，需要仔细阅读。 来源： https://www.cnblogs.com/Tpf386/p/11757707.html

原文链接： http://www.cnblogs.com/longronglang/p/9879570.html 概念 首先来说说性能测试：性能是软件的一种非功能特性，他关注的不是软件是否完成了特定的功能，而是软件在完成特定功能是展示出来的及时性。 及时性从不同的视角代表不同的指标： 用户：响应时间 系统管理员：资源利用率，可扩展性，系统稳定性，系统容量 开发人员：系统架构，数据库设计，设计和代码实现 可见，系统稳定性对系统管理员的意义重大，稳定性的好坏也可以直接影响到最终用户所关心的“响应时间”，所以说稳定性测试时性能测试中非常重要的一环。 稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7x24小时），检测系统是否能够稳定运行。 如何实施 一、识别并确认软件主要业务（是否需要稳定性测试） 将稳定性测试的重心放在软件最有Value的地方，比如说一个抢票系统，它最有value的地方是当有一定数量的用户同时进行买票操作是系统的相应时间，资源利用率等是否能够正常且稳定，而不是用户如何添加新的联系人，修改个人信息等 二、罗列主要用户场景及相应负载量 1、用户场景可以根据软件主要业务进行设定 2、对主要场景负载量需要有一个清晰的定义（或者通过负载测试验证了用户场景的负载量，这将作为一个标准的负载在稳定性测试中使用） 三、制定稳定性指标模型

https://blog.csdn.net/paolei/article/details/94390330 背景简介 　　对于大型应用后台系统来说，稳定性至关重要。目前越来越多的大型应用系统采用微服务架构，更加需要关注稳定性的技术能力建设。稳定性是服务系统基础能力的体现。 　　基础知识 　　在介绍稳定性技术策略主题之前，我们首先梳理一些基础概念和知识。 　　针对我们业务后台系统建设，任何大型业务后台系统绝对不是一蹴而就。它是伴随着业务不同阶段，不断进行演进的过程。如果经历过从 0 到 1 建设一个业务后台系统的同学，都会有类似的体会。 　　启动阶段 　　启动阶段，业务模型相对简单，用户量少，这时候我们可以将所有的系统模块耦合在一个工程里面，进行单机部署。这时候可能仅仅需要将业务系统与数据库进行隔离。 　　探索阶段 　　探索阶段，业务模型不断演进，用户量增加，单机服务能力瓶颈凸显。这时候就需要由单机服务部署向集群服务部署来优化，利用负载均衡将请求合理分配，减少单机服务压力。另外一个方面，数据量不断的增加，也需要考虑针对数据来进行水平的扩展(主从部署，读写分离)。 　　在这一阶段，我们仅仅是做了集群扩展，但所有的业务代码都在同一个工程维护，所有的数据信息都在同一个数据库中存储。随着团队的扩充与业务交互不断复杂化，在工程维护上存在很大的风险，工程研发效率受到制约