孔庆龙，一线架构师，多年金融架构、SOA服务、服务治理、系统优化、分布式系统项目经验。目前专注于互联网金融技术架构设计、分布式架构、微服务架构、DevOps实践、大数据等领域。1、什么是系统优化系统优化，一方面对IT系统或交易链中的每一个环节进行系统的分析和优化，另一方面对单个系统的瓶颈点进行分析和优化。这两个方面的优化目标大致相同，无非就是提高系统的响应速度和吞吐量，降低各层的耦合度，从而灵活应对市场需求。系统优化主要在以下三个层面进行。IT系统治理层：这一层的优化不仅是性能优化，还包括应用架构优化（如应用分层、服务治理等），以适应业务架构的变化。系统层：这一层的优化包括业务流程优化和数据流优化（如增加系统负载、降低系统开销等）。基础设施层：这一层的优化主要是提升IaaS平台的能力（比如让弹性集群具备水平扩展能力，支持资源快速上线下线和流转等）。2、系统优化的方法论、思路和原则什么是方法论？我个人的理解是，听起来很厉害，做过的人觉得是废话，但能指明行动的方向。下面根据多年的经验，从系统优化的常用方法论、优化思路和优化原则三个方面进行简要分享。2.1常用的方法论常用的方法论如下。阿姆达尔定律：根据公式S=1/(1?a+a/n)，分析每次对整体效果影响最大的点，并进行优化。不访问不必要的数据：减少交易线上不必要的环节，减少故障点和维护点。就近加载，缓存为王。故障隔离：不要因为系统瓶颈而压垮整个交易平台。扩展性好：合理利用资源，提高处理效率，避免单点故障。优化交易链提高吞吐量：减少串行同步调用，合理拆分（垂直/水平拆分），预规则。性能和功能同样重要：如果链上的5笔交易成为设计时的90%，则整体性能将是设计时的59%。2.2优化思路根据以往经验，系统优化思路总结如下：(1)认清现状，发现问题。(2)确定明确的优化目标，分析现状与目标的差距，确定实施路线。(3)对系统进行拆分，分别对逻辑层（Web层、业务层、持久层）和物理层（客户端、网络、应用服务器、数据库服务器）进行优化。(4)使用工具对系统进行监控和测试，并对监控和测试的结果进行分析。（五）科学优化制度。遵循一定的流程：监控/性能测试→分析瓶颈→列出瓶颈因素→验证瓶颈因素→修改系统→确认是否达到优化目标。确定影响性能的因素：CPU、内存、I/O、网络或其他因素。确定主要瓶颈，确定关键因素的优先级，并重复监控或测试验证。避免过度优化，一次解决一个瓶颈，不要在不需要的地方优化。提高CPU性能：编写更快的代码，设计更好的算法，减少寿命短的对象。提高内存性能：减少长寿命对象。提高I/O性能：重新设计应用程序以减少I/O交互。缓存为王：适当的缓存，最大限度发挥数据库缓存、应用端缓存、客户端缓存的作用。2.3优化原则系统优化的原则如下：在应用系统的设计和开发过程中，始终要考虑性能。确定清晰明确的绩效目标是关键。性能优化伴随着整个项目周期。最好分阶段设定目标。达到预期的性能目标后，可以对本阶段的工作进行总结和知识迁移，进入下一阶段的优化工作。必须保证优化后的程序能够正确运行。性能更多地取决于良好的设计，而优化技术只是一种辅助手段。优化过程是一个迭代、渐进的过程，每次优化的结果都要反馈给后续的代码开发。性能优化不能以牺牲代码的可读性和可维护性为代价。3.性能优化3.1常见的性能问题大多数常见的性能问题都是由于资源不足或资源竞争激烈引起的。下面将简要介绍三个方面：客户端性能、J2EE系统性能和数据库性能。常见的客户端性能问题常见的客户端性能问题如下。加载缓慢：首次启动速度慢或重新加载速度慢。反应迟钝：突发事件导致页面冻结。受网络带宽影响严重：由于需要下载大量资源文件，在部分网络环境较差的地区页面加载缓慢。JS（JavaScript）内存溢出：对对象属性的频繁操作导致大量内存被占用，最终溢出。常见的J2EE系统性能问题常见的J2EE系统性能问题如下。内存泄漏：在运行过程中，内存不断被占用且无法回收，内存使用量随着时间的推移或负载的增加而线性增加，系统的处理效率随着时间的推移或增加而降低并发性，直到分配给JVM的内存耗尽。资源泄漏：打开资源后没有关闭或关闭不成功导致的问题。这些资源包括数据源连接、文件流等。当这些资源被频繁打开但没有成功关闭时，就会发生资源泄漏。数据源连接泄漏是一个常见的资源泄漏问题。过载：过度使用系统，超出其处理负载的能力。资源瓶颈：资源瓶颈是由资源过度使用或分配不足引起的。线程阻塞、线程死锁：当线程执行某段代码时，无法获取到相关的同步锁，导致通信阻塞。应用系统响应慢：由于应用算法未优化、大量数据读取不合理、SQL缺少索引、表关联过多等原因导致响应时间过长，执行缓慢。应用系统不稳定：应用系统响应时快时慢。应用系统出现各种异常情况：有的是中间件服务端抛出的，有的是数据端抛出的。数据库常见问题以往在做核心业务系统的技术支持时，遇到的常见数据库问题如下。死锁：由于线上服务过早启动数据库事务，第三方服务没有及时响应，导致锁和事务无法提交，造成数据库死锁。I/Obusy：由于糟糕的SQL或糟糕的业务逻辑设计，导致大量I/O等待。CPU占用率居高不下：由于高并发或缓存穿透导致数据库CPU占用率居高不下或波动。3.2性能优化的具体工作“天下功夫，唯快不破”，性能优化的首要任务是提高系统的响应时间（响应时间=业务处理时间+排队时间）。如图16.1中经典的响应时间曲线所示，我们要做的是通过优化程序来减少服务时间，通过提高系统的吞吐量来减少系统的排队时间。图16.1中的纵轴代表响应时间，是服务时间和排队时间之和；横轴表示到达率。随着单位时间内进入系统的交易数量的增加，曲线逐渐向右滑动。随着到达率的增加，排队时间会在某个时刻激增，此时响应时间也会激增，性能会受到影响，用户会变得非常沮丧。图16.1下面用以往项目中的案例来分析性能优化的具体工作。事务线优化事务线用于从服务消费者的角度来查看事务在各个层级应该完成的功能以及功能点之间的关系。功能点之间的关系由有向路径表示，如图16.2所示。图16.2交易线路优化原则如下：最短路径：减少不必要的环节，避免失败点。交易完整性：通过抵消或补偿交易来保证交易线上所有环节交易的一致性。故障隔离快速定位：屏蔽异常情况对正常交易的影响，通过交易码或错误码快速定位问题。流量控制原理：可以对业务通道进行流量控制，结合优先级设置，优先处理高级别的业务。超时控制漏斗原则：尽量让交易线上前端系统的超时设置大于后端系统。CircuitBreaker和故障隔离原则：避免因为某个服务商的故障导致整个交易线路不可用。随着架构的演进，逐渐从孤岛系统发展为以服务为单元可以灵活构建的分布式服务系统，如图16.3所示。在服务治理的过程中，将原有的核心业务系统分解为各个独立的业务组件。一些中间平台系统逐渐基于这些业务组件和流程服务构建业务服务，并提供前端应用的快速构建。贸易支持。在这个过程中，服务识别和构建是基础，交易线路的规范是保障。通过事务线的规范，可以确定服务治理的范围，因为在软件版本迭代的时候，很少有人能够清楚地考虑到系统的所有细节，所以我们必须依靠规范来确定治理的范围，不在人身上。图16.3开发一个订单查询功能A，服务集成平台的服务B和C都可以完成这个功能的开发，不同的是B在C的基础上增加了一些额外的校验。根据最短的原则路径，A应该直接调用C的服务，如图16.4所示。图16.4流量控制的目的之一就是保证各个系统的健康稳定运行。一般使用计数器根据交易类型来检测交易的并发数，不同的交易类型使用不同的计数器。当交易请求到达时，计数器加1；当请求响应失败时，计数器减1。流量控制是对服务提供者的一种保护机制，那么服务消费者如何避免因服务提供者不可用导致自身不可用，并将这种不可用放大到事务的调用者环环相扣，最终拖垮整个交易环节造成的雪崩呢？服务的消费者一般可以通过以下三种方式防止“雪崩”，实现对交易环节的保护。隔离机制：资源池隔离。如果线程池、数据库连接池等独立分配，即使某一类服务出现问题，也只会影响一个单独的资源池。熔断机制：当调用失败触发预设阈值时，应快速返回预设结果，避免大量同步等待。熔断检测请求会周期性检测服务状态，并进行服务状态转换。监控报警：监控服务调用状态，设置预警值。当出现异常时，可及时通知相关人员进行干预，缩短异常范围。客户端优化图16.5从web请求时序（如图16.5所示）可以看出，客户端优化的首要目标是加快页面显示和响应速度，其次是减少对服务器的调用。常见的解决方案如下：分析瓶颈点，针对性优化。缓存为王，通过在客户端缓存静态数据来提高页面响应时间。通过gzip、deflate压缩减少客户端网络的下载流量。进行压缩的好处是可以将文本文件占用的空间减少60%左右。但是在执行过程中需要注意HTTP请求的解析。Accept-Encoding头决定是否支持压缩，Content-Encoding编码格式在响应中设置。使用压缩工具对JS进行压缩，减少JS文件占用的空间。删除和合并脚本、样式表和图像以减少GET请求。*非阻塞加载JS。预加载图像、CSS样式、JS脚本。按需加载JS脚本。优化JS处理方式，提高页面处理速度。某企业内部应用系统客户端HTTP请求监控记录如图16.6所示。图16.6从图16.6中，我们可以看到总共发送了25个请求（21个命中缓存，4个与服务器交互）。从图16.7的统计信息可以看出，请求一共耗时5.645s，进行了4次网络交互，接收了5.9KB的数据，发送了110.25KB的数据，使用gzip压缩保存了8KB的数据.图16.7通过优化后端请求、合并压缩JS/J??SP文件等操作，将页面响应时间优化到2s左右。前端优化，最好了解浏览器和HTTP的原理。服务器端优化服务器端涉及的方面非常广泛。图16.8梳理了服务端优化过程中可能存在的问题，以及使用的辅助分析工具、分析思路和常用解决方案。图16.8
