学网站建设需要多长时间,做同城信息网站怎么赚钱,网站开发用什么书,环保公司网站架构怎么做Java全能学习面试指南#xff1a;https://javaxiaobear.cn
今天聊一聊大家常听到的高性能系统架构。
高性能系统架构#xff0c;主要包括两部分内容#xff0c;性能测试与性能优化。性能优化又可以细分为硬件优化、中间件优化、架构优化及代码优化#xff0c;知识架构图如…Java全能学习面试指南https://javaxiaobear.cn
今天聊一聊大家常听到的高性能系统架构。
高性能系统架构主要包括两部分内容性能测试与性能优化。性能优化又可以细分为硬件优化、中间件优化、架构优化及代码优化知识架构图如下。 性能测试
先看系统的性能测试。性能测试是性能优化的前提和基础也是性能优化结果的检查和度量标准。
关于性能测试有一句著名的论断叫作“你不能优化一个你未经测试的系统你也不能优化一个你不了解的系统”。所以要进行性能优化首先要进行性能测试看系统的当前各项性能指标是什么样子的问题在哪里从哪些方面进行优化。
而具体在优化的时候又必须要了解系统。系统的架构是什么样子的系统的关键技术点、瓶颈点在哪里为何会产生这样的瓶颈点以及如何对它进行优化也就是说必须要在了解系统的基础之上才能进行优化。所以性能测试以及了解系统是性能优化的两个关键前提。
关于性能的标准在不同的视角下性能的度量标准是不同的性能优劣也是不同的性能标准有主观和客观两种视角。 主观标准是说使用者在体验上的快慢用户在使用系统的时候它主观上感觉快还是慢那么就会得到一个性能好还是差的主观标准 客观标准也就是在客观上性能指标到底是好还是差。
主观标准和客观标准虽然它们本质上是统一的但是也并不是完全一致的。比如客观性能指标相同的两个系统其中一个系统通过页面渲染通过一些动画提示通过更良好的用户交互体验可以使用户主观感觉系统响应更快。而另一个如果没有做任何交互上的设计优化仅仅是直接向用户输出内容那么用户可能会感觉等得更久一些在主观体验上性能也更差一点。
客观性能指标
在客观视角上性能优劣的指标主要有响应时间、并发数、吞吐量以及性能计数器。这些指标通常也是我们技术上要进行优化的主要指标后面我们的性能讨论主要是围绕这些客观上的性能指标展开的。 响应时间
第一重要的就是响应时间。所谓响应时间是指应用系统从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标最直接地反映了系统的快慢。
并发数
第二个指标是并发数。并发数是指系统同时处理的请求数这个数字反映了系统的负载特性。对于互联网系统而言并发数就是同时访问系统的用户数也就是指同时提交请求的用户数目。和并发用户数相对应的还有在线用户数也就是当前登录系统在使用系统的用户数当前登录系统在使用系统的用户数并不是并发用户数因为登录系统在使用的时候它可能在查看页面内容在填写页面信息这个时候只要不提交请求虽然它当前在系统上是在线的但是它并不是并发用户数而是在线用户数。另外还有系统总用户数指可能访问系统的总用户数。一般说来系统的总用户数远大于在线用户数在线用户数远大于并发用户数对系统性能产生影响的主要是并发用户数。
吞吐量
另一个性能指标是吞吐量。吞吐量是指单位时间内系统处理请求的数量体现的是系统的处理能力。我们一般用每秒的请求数、每秒的事务数这样的一些指标来衡量也就是 HPS、TPS 这些HPS 是每秒的 HTTP 数目TPS 是每秒事务数。还可以用 QPS即每秒的查询数来表示总之就是单位时间内处理的请求数目。
吞吐量、响应时间和并发数三者之间是有关联性的响应时间足够快那么单位时间的吞吐量也会相应的提高。比如说响应时间如果是 100ms对于一个并发用户并发数是 1那么 TPS 就可以是 10。如果响应时间是 500ms用户并发数还是 1那么 TPS 吞吐量就变成了 2。
性能计数器
最后一个性能指标是性能计数器。指的是服务器或者操作系统性能的一些指标数据包括系统负载 System Load、对象和线程数、内存使用、CPU 使用、磁盘和网络 I/O 使用等指标。这些指标是系统监控的重要参数反映系统负载和处理能力的一些关键指标通常这些指标和性能是强相关的。这些指标很高成为瓶颈通常也预示着性能可能会出现问题。在实践中会对这些性能指标设置一些报警的阈值。当监控系统发现性能计数器超过阈值的时候就会向运维和开发人员报警以便及时发现、处理系统的性能问题。
性能测试方法
再来看性能测试的方法。通常我们说性能测试的时候指的是一个总称是广义上的性能测试具体可以分为狭义上的性能测试、负载测试、压力测试和稳定性测试。
性能测试
狭义的性能测试是指以系统设计初期规划的性能指标为预期目标对系统不断施加压力验证系统在资源可接受的范围内是否达到了性能的预期。所以性能测试主要是测试系统的性能是否达到了设计预期这样一个目标对系统的压力相对比较小的。
负载测试
负载测试则是对系统不断施加并发请求增加系统的压力直到系统的某项或多项指标达到安全临界值。比如某种系统资源已经呈现饱和状态这个时候继续对系统施加压力系统的处理能力不但不能提高反而会下降。所以简单说负载测试是指通过不断施加负载压力寻找系统最优的处理能力最好的性能状态达到最大的性能指标。通常说来负载测试的结果比性能测试的结果高一点。
压力测试
第三个压力测试是指在超过安全负载的情况下对系统继续施加压力直到系统崩溃或者不再处理任何请求以此获得系统的最大压力承受能力。压力测试也就是将系统压崩溃需要多大的负载压力或者是并发请求压力测试系统在最坏的情况下可以承受多大的访问压力。
稳定性测试
稳定性测试则是指被测试的系统在特定的硬件、软件和网络环境条件下给系统施加一定的业务压力使系统运行较长一段时间以此检测系统是否稳定。在生产环境中请求压力是不均匀的、呈现波浪的特性因此为了更好地模拟生产环境稳定性测试也应该不均匀地对系统施加压力看系统在这种持续的、长时间的、不均匀的访问压力之下能否稳定地提供响应特性系统性能是否保持稳定。
性能特性曲线
吞吐量特性曲线
前面提到的性能测试、负载测试和压力测试它的测试曲线如下图所示。横轴是系统资源或者并发用户数对于性能测试系统资源和并发用户数本质上是一样的因为随着并发用户数的增加系统资源消耗是线性增加的。纵轴是它的吞吐量 TPS。 在性能测试阶段随着并发访问逐渐的增加系统资源的不断消耗TPS 是在不断上升的。
到了负载测试阶段这种上升的斜率会变小直到达到了系统负载能力的最大点也就是 c 点。而过了 c 点以后继续施加压力继续提高并发请求的数量系统资源消耗进一步增加TPS 吞吐量不增反降会呈现下降趋势。直到到达了某个点d 点系统超过了它的最大承受能力系统崩溃。
压力测试的时候吞吐量之所以会下降是因为更多的并发请求、更多的用户请求进入系统以后系统已经无法正常处理这样多的用户请求系统的资源消耗情况会更加恶化系统不能够有效地处理用户的正常请求却又不得不分配出大量的资源来调度用户的访问请求。这时候系统资源虽然被更多的消耗但是响应时间在不断地加长它的 TPS 在下降。
响应时间特性曲线
和 TPS 相对应的响应时间曲线则是相反的如下图。随着并发用户数的增加以及系统资源的不断消耗系统的响应时间在不断增加。在性能测试阶段系统的响应时间几乎没有太多的变化但是到了负载测试的时候系统的响应时间就开始增加当超过了它最大负载点——c 点以后继续增加压力系统的响应时间会急剧增加系统的性能状况急剧恶化最后到达了它的崩溃点——d 点。 一般说来性能测试是通过增加并发数不断测试各项性能指标获得的。如下图性能测试结果表所示并发数不断地增加响应时间也不断地增加TPS 先增加后下降而错误率超过了某些点以后开始增加后来增速加剧同时系统的负载也在不断增加。通过这个表绘制出来的性能特性曲线就如上面的图中所示。 性能测试就是要测试出性能特性曲线看当前的系统是否达到了性能目标以及系统最好的性能特性是什么能达到的最大负载压力是多大。从而做到对自己的系统心中有数面对高并发访问的时候心中不慌从容应对。
系统性能优化
现在我们已经了解了系统的各项性能指标那么如何对系统进行性能优化呢
分层优化系统性能
通常当说起对系统性能进行优化的时候大家一般想到的是对系统内自己写的代码进行优化或者大不了对系统的架构进行优化但实际上对系统的性能优化可以有更高层次的思考。如下图所示将系统的性能优化分为七层可以在不同的层面对系统进行性能优化。 第一层是机房与骨干网络的性能优化
对于高并发的、大流量的、海量用户访问的一个互联网应用而言通常它可能是全球级的它的用户可能分布在全球各个地方我们知道即使是以光的速度进行传输从地球的另一面对一个数据中心进行数据访问它的一次请求响应的网络通讯时间都需要几百毫秒的时间而我们对一个成熟的应用进行性能优化通常是难以获得几百毫秒的响应时间优化的。所以对于大型互联网应用它们通常会进行全球各地的多机房部署就近为当地用户提供访问服务即使是只针对国内的用户使用的一些大型互联网应用为了提高不同地区的用户的访问体验也会进行多机房架构设计。比如说像新浪微博它们在上海、北京和广州建设了 3 个机房分别为中国不同地域的用户提供服务。
所以机房与骨干网络的性能优化主要手段就是采用异地多活的多机房架构同时为了联通这些异地多活的多机房架构会建设自己专用的骨干网络并且自主进行 CDN 建设。
第二层是对服务器内的硬件进行优化
我们前面讨论过系统伸缩有垂直伸缩和水平伸缩两种互联网应用主要使用的是水平伸缩。但是某些情况下垂直伸缩实际上带来的性能优化也是不可忽视的。在成本允许的情况下考虑使用垂直伸缩提高服务器硬件的性能对系统性能的提升会有很大的好处。
比如说我们用 SSD 硬盘代替传统的机械硬盘就可以使磁盘的访问读写特性得到数量级的提升。
如下图所示这是一个 Spark 性能优化的案例。因为 Spark 是一个大数据处理平台所以需要处理大量的数据在作业处理过程中不同的服务器之间需要传输大量的数据。经过性能指标分析我们发现在一次作业运行中大量的时间消耗在网络传输上。对这种情况进行性能优化如果要是从程序或者代码的层面进行优化那么主要手段就是使用数据压缩将数据压缩以后进行传输这样可以减少数据的传输量减少网络传输的性能压力降低网络传输花费的时间。但是对数据进行压缩和解压缩需要消耗大量的 CPU 资源事实上大数据计算通常也是 CPU 密集型将宝贵的 CPU 资源花费在数据压缩和解压缩上最后的性能结果可能会变的更差。 但是我们可以对硬件进行优化如上图例子中看到的。在优化前我们使用的是如图这种 1G 的网卡里面的曲线表示的是网卡读写性能在某些阶段网卡的读写传输能力已经达到了它的极限需要几十秒的时间去完成数据传输然后再进入下一个计算阶段。
我们通过硬件优化的方法将网卡更换为 10G 网卡如下图得到了这样一条网卡传输的性能曲线我们看到系统在最大的数据传输压力情况下它依然没有触发到网卡处理能力的极限而网络传输的时间也从以前的几十秒缩短到了十多秒。 硬件与服务器性能优化再下面一层是操作系统的性能优化
这里我们再看一个案例依然是 Spark 的性能优化案例。下图中是 CPU 的使用率我们看到其中红色的是用户程序使用的表示的是 CPU 的用户态紫色部分是 CPU 的系统态红色部分是 User 状态紫色部分是 sys 状态。紫色部分表示的是当前 CPU 被操作系统占据执行操作系统的指令。但是为什么在一个大数据处理作业过程中有这样多的 CPU 时间花费在系统处理上 经过进一步的性能分析发现部分 Linux 版本在缺省状况下打开了 tranparent huge page 这样一个参数当我们关闭参数的时候发现处于 sys 状态 CPU 的消耗得到了极大的优化也就是下图。如图所示关闭 tranparent huge page 后处于 sys 状态消耗的指标也就是紫色部分消耗的 CPU 指标得到了极大的改善而整个的系统作业时间也从 200 多秒优化到了 150 多秒。 第四层是虚拟机的性能优化
目前主流的像 Java、C# 这样的一些互联网 Web 应用都是运行在虚拟机之上的那么对虚拟机的性能优化也会对系统的整个性能产生巨大的影响。
最典型的就是垃圾回收器对系统的性能优化如下图我们看到 Java 的几种不同垃圾回收器从最早的串行垃圾回收器到目前比较新的 G1、ZGC 等垃圾回收器每一类的垃圾回收器都会对系统性能有不同的影响。 在互联网应用中使用的主要的垃圾回收器是 CMS 垃圾回收器。CMS 垃圾回收线程和用户的线程在很多时候是并发运行的这也是 CMS 被称为并发垃圾回收器的原因。因为用户线程和垃圾回收线程并发运行所以在垃圾回收的时候对用户的性能影响相对比较小一点。而在未来主流的垃圾回收器应该是 G1。
在虚拟机之下是基础组件的性能优化
我们的 Web 应用主要是运行和部署在 Web 容器组件上比如像 Java 运行在 Tomcat、Jetty 或者 JBossWildFly这样的 Web 容器之中那么 Web 容器本身的性能也一定会对我们这些系统性能产生很大的影响。举一个现实的例子在阿里巴巴曾经使用 Jetty 代替 JBoss通过这样一种替换实现了系统性能的极大的提升特别是节省了大量的服务器在替换后阿里巴巴全站下线 1/3 的应用服务器。主要原因是 Jetty 比 JBoss 的架构更轻量配置更加简单使用较少的 Jetty 容器就可以实现原来 JBoss 能够提供的处理能力如下图所示。 在基础组件性能优化之下才是软件架构性能优化
事实上我们整个课程都是围绕着架构性能优化的各种工具和技术展开的。在这里面我们精简一下抽象了关于软件架构性能优化的三板斧。这三板斧也是互联网系统架构的最主要的三个技术分别是缓存、异步和集群。
缓存
通过缓存可以减少数据库的负载压力。缓存使用内存中的数据比数据库访问磁盘中的数据要有更好的性能同时缓存中存储着的计算结果数据也比数据库中存储的原始数据计算速度更快资源消耗更小。此外还有一点缓存减少了数据库的负载压力从而可以使数据库提供更多的数据访问支撑更大的系统访问压力从而提升整体的系统性能。 异步
通过异步的方式通过分布式消息队列使系统不同应用之间、不同服务之间异步调用可以使调用者尽快的返回用户响应使系统能够得到更好的响应特性。同时分布式消息队列的异步架构还有削峰填谷的作用在访问高峰期通过异步将用户请求数据写入到消息队列中在访问低谷的时候还在继续消费处理这些消息避免对数据库等产生较大的负载访问压力使系统能够维持在一个较好地响应曲线上。 集群
通过负载均衡的手段将多种应用服务器构建成一个集群共同提供服务以提高系统整个的处理能力提升系统的响应性能。 在性能优化的最底层才是软件代码的性能优化
关于代码的性能优化有这样一些实践可供参考。
第一点是遵循面向对象的设计原则与设计模式编程避免烂代码。
很多时候我们应用程序性能不好并不是性能上有什么技术挑战或者是缺陷仅仅就是因为代码太烂了系统之间调用耦合严重很多已经不用的代码无法清理下线执行逻辑混乱导致系统性能差。使用良好的原则与模式编程编写清晰、灵活、健壮的代码对性能优化有长远的好处。 第二点是并发编程可以在程序并发运行的时候使用多线程。 第三点是资源的复用。
对于一些比较昂贵的资源比如说线程或者数据库连接通过线程池或者数据库连接池对外提供服务。通过资源池复用对象或者是线程供应用程序使用应用程序每次需要资源的时候从资源池获取用完了放回到资源池中继续复用而不是每次使用的时候都去创建用完了以后就销毁。
第四点是用异步编程。
在程序内部使用消费者生产者以队列数据结构的方式实现程序内的异步架构以此来提高系统性能。
第五点是要使用正确的数据结构进行编程。
要熟悉数组、链表、栈、队列、Hash 表、树等常用数据结构熟悉它们的特性、优缺点以及使用场景正确地使用它们来管理和访问程序数据。
性能优化案例
我们以 Spark 为例看一个代码的性能优化案例。如下图我们通过对 CPU 的性能指标的分析发现在 Spark 作业过程中有一个计算阶段 Stage运行时间特别长消耗时间 14 秒。CPU 和网络也都有一定的开销研究应用代码发现这段代码仅仅是做了一个数组的初始化不应该需要花这么长的时间那么时间究竟花在哪里呢 进一步对 Spark 的源代码进行分析发现 Spark 的任务初始化加载应用代码的时候每一个执行器 Executor 都要加载一次可执行的应用代码当时每台服务器启动了 48 个 Executor每个应用程序的代码包是 17M所以每一个服务器需要下载 48×17M而集群有 5 台服务器。通过网络传输这么大的代码包导致网络阻塞性能劣化。后来我们对 Spark 的源代码进行了优化主要优化手段就是在 Executor 加载应用程序的时候启动了本地文件的缓存模式先检查本地文件中是否有需要执行的应用程序代码如果没有远程从 Driver 服务器上去加载如果有直接拷贝本地代码到自己的执行路径下通过这种优化我们使第一个运行阶段从 14 秒下降到了不到 1 秒如下图所示。 优化代码如下图所示在 Spark 源码增加基于缓存的文件加载函数十多行代码获得极大的性能提升。 总结回顾
性能优化的前提和基础是性能测试通过性能测试了解系统的性能特性才能进行优化而性能测试主要就是要测试出来系统的性能曲线通过对性能曲线进行分析了解系统的瓶颈点和系统资源消耗再进行性能优化。性能优化的时候需要建立一个整体的思维要从整体系统的层面去思考优化而不只是仅仅关注自己的代码或者是自己设计的架构。
最上层的优化是硬件优化包括骨干网络、数据中心服务器硬件这样的优化然后是基础组件的性能优化包括操作系统、虚拟机、应用中间件这几个方面这之后才是架构的优化包括核心的三板斧缓存、异步和集群最后才是代码的优化代码优化的主要手段有并发、复用、异步以及正确的数据结构当然最重要的是设计清晰、易维护、易懂、简单、灵活的代码也就是说最重要的是要遵循面向对象的设计原则和设计模式进行编程。
