【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
应用系统上线运行后，随着系统数据量的不断增长、访问量的不断上升，系统的响应速度通常会越来越慢，尤其日常峰值情况下常不能满足业务需要，甚至出现应用服务中断的现象，给企业造成巨大的品牌损失和经济损失。大量数据表明，每0.1秒的核心体验响应时间延长会导致1%的营收下降。企业应用系统上云，如何在云端利用云的优势进行性能优化，是一个值得深入分析的重点问题。
性能优化的价值与策略
1、性能优化价值
性能是一个应用系统最重要的指标，除非没有选择，否则没有用户会忍受一个响应缓慢的应用系统或网站。大量数据表明，每0.1秒的核心体验响应时间延长会导致1%的营收下降。
应用系统上线运行后，随着系统数据量的不断增长、访问量的不断上升，系统的响应速度通常会越来越慢，尤其峰值情况下常不能满足业务需要，甚至出现应用服务中断，给企业造成巨大的品牌损失和经济损失，因此性能优化会显得至关重要。
通过性能优化，可以用更少的硬件资源，支撑更大量的业务发展，从而达到节省硬件成本的目的；同时，可以在有限资源的情况下，提升系统的响应能力，为用户带来更好的使用体验，促进业务增长。
2、性能优化策略
对于应用系统来说，用户从浏览器发出请求到数据库完成事务操作，中间需要经过很多环节，如果系统响应慢，必须对请求经过的各个环节进行分析，排查可能出现性能瓶颈的地方，定位问题。
排查瓶颈的方法通常是检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超出预期；然后检查监控数据，分析影响性能的主要因素是CPU，还是内存、磁盘、网络等基础设施资源的问题，还是架构设计的问题，或是慢SQL语句的问题等。
定位出导致性能问题的具体原因后，再做针对性的性能优化。
云上性能优化体系
1、性能优化体系
性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行的更快，完成特定功能所需的时间更短。
性能优化的维度很多，综合来看可以从下面五个方面展开性能优化：资源层、架构层、应用层、数据库层、中间件层。性能优化体系如下图：
2、资源层优化
云资源层的优化包括云资源水平方向和垂直方向扩展，资源层面优化的依据可来自云监控的量化指标数据。
云监控可实时监控云资源动态指标，是所有云产品的监控管理总入口。可以通过云监控查看最全、最详细的监控数据。云监控能够实时对云服务器、云数据库、负载均衡等云产品进行监控，提取云产品关键指标，以监控图表形式展示。可以通过使用云监控全面地了解资源使用率、应用程序性能和云产品运行状况。
水平方向扩展是增加云服务器、云数据库等实例数量，垂直方向扩展是升级云服务器、云数据库等云资源的规格配置，比如CPU、内存、磁盘、带宽等参数配置，从解决资源瓶颈的角度来优化系统的访问性能。
3、架构层优化
系统的性能问题也有可能是系统架构设计不合理造成的。比如在架构设计上，没有考虑做读写分离、数据库分库分表、动静分离、CDN加速、缓存加速、弹性伸缩等。
读写分离与数据库分库分表解决的是数据库访问性能问题，在云上实现读写分离非常方便，创建只读实例后，在应用程序中配置读写分离地址，就可以使写请求自动转发到主实例，读请求自动转发到各个只读实例。
动静分离、CDN加速、缓存解决的是静态文件或热点数据快速读取问题，比如图片、视频、热门商品、库存等等，企业上云时需要尽可能使用一些成熟的云原生解决方案，从架构设计层面去优化访问性能的问题。
弹性伸缩解决的是应用服务器自动扩展的问题，通过提前配置伸缩规则与策略，在业务需求增长时自动增加云服务器实例以保证计算能力，避免访问延时和资源超负荷运行。
4、应用层优化
应用层优化的关键是首先快速诊断出应用的问题瓶颈。
互联网业务的高速发展带来了日益增长的流量压力，业务逻辑也日趋复杂，传统的单机应用已经无法满足需求。越来越多的网站或系统逐渐采用了分布式部署架构。
同时，随着 Spring Cloud/Dubbo 等基础开发框架不断成熟，越来越多的企业开始对应用架构按照业务模块进行垂直拆分，形成了更适合团队协同开发、快速迭代的微服务架构。
分布式的微服务架构在开发效率上具备先进性，但给传统的监控、运维、诊断技术带来了巨大挑战。主要挑战包括：
定位问题难：
微服务分布式架构一个业务请求通常要经过多个服务/节点后返回结果，一旦请求出现错误，往往要在多台机器上反复翻看日志才能初步定位问题，对简单问题的排查也常常涉及多个团队。
发现瓶颈难：
当用户反馈系统出现卡顿现象，很难快速发现瓶颈在哪里：是用户终端到服务端的网络问题，是服务端负载过高导致响应变慢，还是数据库压力过大？即使定位到了导致卡顿的环节，也很难快速定位到代码层面的根本原因。
架构梳理难：
在业务逻辑变得逐渐复杂以后，很难从代码层面去梳理某个应用依赖了哪些下游服务（数据库、HTTP API、缓存），以及被哪些外部调用所依赖。业务逻辑的梳理、架构的治理和容量的规划也变得更加困难。
通常，需要使用性能压测工具（比如PTS）、应用实时监控服务（比如ARMS）等工具，基于前端、应用、业务自定义等维度进行链路追踪，实现完整的调用链路还原、调用请求量统计、链路拓扑和应用依赖分析等。链路追踪能够帮助快速分析和诊断分布式应用架构下的性能瓶颈，提高微服务时代下的开发诊断效率。
定位瓶颈问题后，展开针对性的优化工作，比如优化慢SQL语句、优化调用报错程序代码、优化调用异常API等。通常应用优化后可结合性能压测工具对系统性能、容量水位进行再次压力测试，通过压测结果进一步分析系统瓶颈，对应用不断迭代优化。
5、数据库优化
影响数据库系统性能主要有如下几个因素：系统的硬件配置、数据库文件的物理分布、数据库实例的参数、数据库的物理设计、应用的SQL语句。
数据库性能优化，首先需要进行下述数据内容采集：
系统软硬件环境：包括服务器的操作系统设置、硬件配置、网络配置、软件环境、启动选项、进程信息、性能信息、磁盘使用情况等。
硬件运行情况：包括CPU、内存、磁盘、网络的运行数据。
数据库实例的配置： 实例配置参数。
数据库配置：包括恢复模式、自动收缩、空间增长等信息。
数据库磁盘使用：包括数据库大小、表大小、记录数、索引大小、占用空间等。
索引及碎片情况：包括表上的索引、索引的碎片情况、索引的维护计划等。
SQL语句执行情况：包括SQL 语句执行时间、启动时间、所在数据库、语句内容、死锁、阻塞等情况。
应用程序运行状况：包括系统高峰时段、晚间的数据库维护任务、用户报告比较慢的业务、系统运行特点。
数据库性能主要优化项见下图：
6、中间件优化
在信息系统中，不少性能问题是由不起眼的应用中间件造成的。应用中间件之所以诞生，是为了帮助应用程序的编码人员处理与业务逻辑没有太大关系而又必须处理的经常性事物，比如处理应用程序和数据库之间的关系，设置开启多少个session来处理客户请求，session的超时时间等等。
然而在享受便利的同时，应用中间件也会成为系统性能问题的缔造者，开发人员和测试人员往往忽视了中间件本身对性能的影响，这种影响包括交易吞吐量的制约、响应时间的影响、交易成功率的影响等等。
中间件优化的目标是把耗费在中间件的时间缩短（提升用户体验），提高整个应用服务器的吞吐量。中间件优化，调什么参数，一定要了解其含义、原理、调整后的收益和风险是什么，最好是N个参数能在脑子里缠绕为一个整体。
高优先：调整JDBC连接池大小、线程池、JVM虚拟机的heap size。
中优先：会话数、垃圾回收GC策略。
另外还有高速缓存、数据源语句缓存大小。
不当的配置也会导致中间件处于假死状态。比如某类资源（session或jdbc）被应用完全占满了，并且短期不释放，这样新的请求就没法执行，造成了假死的情况。这类情况，要做好超时放弃的参数配置。
性能优化的进一步思考
性能优化是一个复杂的系统工程，首先需要定位性能瓶颈，然后从云资源、系统架构、应用程序、数据库、中间件等方面进行综合分析和优化；性能优化的最终目的是为了改善用户的体验，离开这个目的而追求技术上的所谓高性能是舍本逐末，没有任何意义。
随着系统数据量、访问用户量的不断增加，以及系统功能的不断迭代，系统需要持续进行性能优化，性能优化是一场持久战，只有这样才能让用户拥有更好的访问体验，从而支撑业务增长。
作者：龚华兵
优质文章
来源：oschina
链接：https://my.oschina.net/u/4026796/blog/3154524