很多企业的核心系统随着业务的快速发展，一段时间后会出现运行缓慢、运行卡顿等非正常情况。对于这类性能问题的解决大多受系统本身架构限制，除了对资源进行优化外，大多处于被动状态。资金和技术雄厚的传统企业可以采取比较激进的做法，进行服务化重构，或升级系统的当前版本，但激进的做法往往面临的高风险，本文将结合实际优化过案例，从整体解决方案的角度剖析该类问题的优化经验及技巧。

【作者】zhanxuechao，系统架构师

很多传统企业的核心应用系统大多是单体应用：1-2台APP应用，后端1个数据库实例，如下图：

稍微好一点的可能会有一台单独的服务器用来部署报表类应用(报表业务与应用实现应用层面的解耦)，但数据方面大多还是与APP共用统一数据库，如下图：

这实际上是由于企业的业务实际情况和行业属性导致的，该类核心应用系统大多为外采的、成熟的商业产品(迭代较慢，1~2年可能才有新版本推出)，可以满足企业的正常业务系统，但大多会随着企业自身业务的快速发展，一段时间后会出现系统运行缓慢、运行卡顿等非正常情况。相信很多传统企业的IT工程师都会面临该类问题(就我本人随机与几家不同区域的传统企业信息负责人沟通后，全部面临或是曾经面临过)，对于这类性能问题的解决大多受系统本身架构限制，除了对资源进行优化外，大多处于被动状态。另外对该类应用系统的性能问题进行分析后，大多的问题点也都集中在了数据库层面，诚然，即使中大型传统企业的核心系统其使用人数和并发量也基本上处于一个较低的值，单体应用、一台Tomcat可以满足应用层面的并发(有一些情况除外，另外，据简单访谈，使用Tomcat的也相对少一点)。当然，资金和技术雄厚的传统企业可以采取比较激进的做法，即对现有核心系统进行服务化重构，或是冒高风险、花大价钱升级系统的当前版本(因为传统企业信息化建设相对闭塞滞后，同时也处于求稳的出发点，系统版本几年不更新很常见)，激进的做法往往面临的高风险，也见过太多传统企业在所谓互联网转型和核心系统重构方面全面失败的案例。

结合实际优化过的几个企业案例，从整体解决方案的角度剖析一下该类问题的优化经验及技巧。总的来说，可以分为技术优化和业务优化。其中技术优化包括硬件升级、参数类优化;业务优化是指结合业务细节，对数据库的sql、程序代码以及架构等方面进行优化工作，具体如下。

一、技术优化

技术优化可以分为对硬件进行升级和对各类操作系统、中间件等进行参数优化两类。其中在系统部署上线前，就应该对系统响应的用户量、并发量、数据量等进行评估，选择适合的硬件配置、操作系统、中间件等并对其进行相应的安全加固和参数优化。

实际上当系统出现性能问题时，大多第一时间想到的是对硬件进行升级，如：增加内存、升级存储(如HDD升级到SSD等)、升级网络交换机扩大带宽、升级服务器等。这是一种简单有效但不治本的方法，甚至在治标方面也难以得到持久，因为系统的性能问题在硬件和应用之间，还有操作系统、中间件等，需要与之相互配套，之前也遇到过32位操作系统跑64G内存的情况(实则真的有一些老旧的应用真实地运行在32位操作系统上)。

在对硬件资源进行升级的同时，还应配套对操作系统、中间件、数据库等的参数进行优化，确保最大化、最合理地使用硬件资源，从而做到在吞吐量、并发量以及响应速度、处理速度等方面得到显著的提升。参数类优化整体可以分为如下：

(1)OS级别的优化：包括操作系统类型选择(Windows/Linux)、内核更新升级(如需)、内核参数、网络参数、安全参数等(如：系统打开文件最大数、最大进程数、关闭路由包转发、处理无源路由包、优化消息队列长度、设置最大内存共享大小、Timewait数量、优化swap、最小化安装操作系统关闭无用软件服务和端口等)，另外OS级别的优化还可以根据业务类型将日志类、备份类的存储硬盘与业务盘隔离划分，降低读写压力，提高存储的IOPS。

(2)中间件参数优化：主要是应用系统所运行的中间件环境，如Weblogic、Tomcat等。选型方面在这里不对Weblogic和Tomcat进行详细对比，但大多情况下，可以使用Tomcat对Weblogic进行替代(切身经验，一般更换起来不难)，省钱，维护且方便。以Tomcat为例，主要参数优化有：对线程池、最大线程数、JVM、连接器方式(bio、nio 和 apr，三种方式性能有差别，一般来说apr 的性能相对最优)、日志优化(减少debug日志输出等)、日志切割(日志如未优化切割，单文件较大，超过10几G时，写入读取会降低)等。

(3)数据库参数优化：在OS参数优化的前提下，对数据库参数进行优化，主要包括(以Oracle为例)sga、pga、shared_pool_size、db_cache_size、sort_area_size、processes、session等。另外还需要对密码大小写、密码失效次数、动静态监听、数据库备份等方面进行相应的优化设置。

实际上，技术方面的优化多在系统部署上线前进行的，与业务方面关系不是很大，切多为通用的最佳实践，按照相应的官方手册文档结合自身实际经验，大多可以调整优化为一个相对不错的环境。但在日常工作中，当出现性能问题的时候，很多人会选择优化硬件升级而忽略参数方面优化，导致硬件升级的成效不大，这一点是要额外注意的，需要通过操作系统、中间件和数据库等方面的参数优化，最大化、最合理的挖掘和使用硬件资源，为应用系统和数据提供最佳、最优运行环境。

二、业务优化

业务优化是指在业务人员和业务场景的配合下，提供相关技术手段对应用系统、数据库等进行优化，整个优化过程与业务逻辑规则联系密不可分。大致可以有：sql优化、代码优化、架构优化等几个方面。

1、sql优化

sql方面的优化除了监控数据库运行缓慢的sql对其进行索引优化外，还包括sql改写、hint函数等方面的优化。对sql进行监控(慢查询、AWR等)和优化索引(索引的添加、重建或删除等，索引的类型选择等)可以独立持续进行，但也要避免单表索引太多(单标超过5个)、索引类型滥用(B-tree索引和位图索引)、索引失效未及时重建等情况。另外可以在开发的配合下，对慢sql进行优化改写、拆分以及hint函数(特别是并发函数/*+parallel(t,4)*/，但也注意不要滥用)的调试，这一块实际上在运行时间较久的传统企业核心系统上比较难以实现，正如对于运行的系统，对数据库的库、表设计方面的优化设计已难以实现。所以，大多sql层面的优化在索引优化处即截停。

2、代码优化

代码优化主要指在系统研发人员的主导配合下进行，包括两个方面的优化：一个是配合上述sql优化对代码中的sql进行优化改写，提高sql执行的效率，获得优化收益;另外一个是对代码中的逻辑架构进行优化，包括复杂逻辑架构拆分、串行业务并行执行、代码类型简洁等等。代码层面的优化如数据库的库表设计优化一样，就多数传统企业来说，在系统产品进行部署上线后，改变较难。

3、架构优化

架构优化包括两方面：业务架构优化和系统架构优化，是标本兼治的方法，但也正如前面所言，对于业务量和业务方向变化不大、且无明显可带来赢利创新的大多传统企业而言，架构优化应该是一种较为激进的做法，激进之处在于对传统企业的业务架构和系统架构进行了全面的推翻重构，尤其是在业务人员尚能接受系统缓慢、卡顿的前提下，对业务和系统进行大规模的优化和重构，大多会带来不稳定的因素。

如果剥离业务优化只是对系统架构方面进行优化，特别是盲目推崇微服务对传统企业进行重构变革的，大多可能会以失败告终。可能是由于自身几次工作经验和所处行业有关，对系统的架构优化、重构和升级多以保守、谨慎的态度，见过太多传统企业欲凭借IT进行业务重构，最终业务和技术双失败的案例。业务和系统是围绕企业健康发展相辅相成的两个紧密元素，任何一个方面的超速发展，都将对另一个方面造成重大的影响。

本着严谨的态度，如果要对架构(包括业务架构和系统架构)进行优化，那么有如下几个问题建议优先考虑清楚：

(1)此次架构优化或重构的目的是什么，要获得一个什么样的收益。即建议结果为导向，结果指导思路和方法。

(2)为完成此次架构的优化或重构，达到预定目标，优化或重构的方案是什么，需要投入的成本是多少，时间成本、人力成本、学习成本等。

(3)结合IT发展规律和生命周期，此次架构的优化或是重构，可以满足企业多久的发展需要。

(4)结合投入成本和预定目标，是否有一个科学、合理，对企业有益的投入产出比。

其实架构的优化重构也不是很难，在牛逼的业务专家配合下，理清各个业务逻辑和相互之间关系，再由研发工程师根据积木式的业务块进行服务化改造，为进一步降耦、提高系统并发，辅之以缓存、消息队列、前后端分离和动静分离等常规手段进行，一套分布式、服务化的架构也就基本完成了对经典单体应用的重构，如果后续业务变化较频繁，系统更新发布频率较高，还可以进一步完善微服务基础设施，如：配置中心、链路监控、基于Jenkins的持续发布以及容器化等。

综上所述，就大多传统企业核心系统优化的业务优化方面而言，除了在慢sql上加加索引外，其代码优化、架构优化等相对较为复杂、可执行性较低，且存在一定风险。实则，还有一种基于数据库方面的优化办法，该方法是在一定业务规则条件下，持续地保持生产数据“瘦身”，不断压缩生产数据库的数据量，达到在小数据量下的快速查询响应，具体如下：

对数据库进行两步拆分，第一步实现数据库的主备同步(Oracle可使用DG，Mysql可使用Replication)，主库实现读写(R+W)功能，备库或从库主要实现读的功能;第二步通过ETL的方式，将主库中的历史数据、可按时间或按业务规则进行归档的数据抽取至数据历史库中。通过两步实现数据库的读写分离和数据归档，将主库的数据量减少降低，实现数据“瘦身”，两个方面来有效地提升数据库的响应速度。

在落地实施方面，正如前面介绍的，第一步搭建数据库的同步备库，相应搭建部署方式可以参考附件;第二步实施需要分为三步：ETL的部署，抽取规则执行，ETL定时执行。相信在业务规则配合下，可以快速的完成数据的抽取和数据处理，将原来庞大的主库在较短时间内瘦身成敏捷的小库，在业务量发展较为稳定的情况下，可以使得系统快速运行2-3年。

在上述基础上，还可以对数据库方面在做文章，如将主库改造为Cluster集群(Oracle为RAC，MySQL为Cluster)的方式，实现读写负载均衡，在集群的基础上搭建同步备库，实现读写分离，特别是mysql的情况下，可以充分利用数据库中间件进行读写分离、负载均衡等，同时也可以在数据库层面进行分库分表。历史库也可以再次剥离历史数据，形成历史库的历史库。具体架构可参考如下：

基于数据瘦身的优化思路，其优化演进路线可参考如下：

该优化思路主要在一定业务规则下，对主数据库的数据进行持续的数据瘦身，同时结合数据库的主备同步实现数据的读写分离，有效地减缓主库的读写压力，进而达到系统优化的目标。严格来说，这也不是一种治根的方法，但就优化过的几起案例来看，行之有效，其实一家传统企业基于该模式，系统正常运行已经超过3年(前提是其业务未有大的增长)。

三、总结

系统优化从来都是一个持续渐进的过程，而且往往难以衡量，有的时候一个sql索引的添加，系统就变得飞速，也有的时候用尽一些列优化套路，系统终究没有明显改观，这是一个痛苦的过程，大家应该平常心对待，持续优化、持续总结，逐渐形成自己的优化思路。当然，对业务和系统进行重构是一个大招，但也并不是标本兼治的绝招，服务化的系统相对传统的、变化不大的业务来说会增加维护的复杂度，因此需要在回答了上述3架构优化的4个问题后在进行架构的重构工作，可能收效会好一些。

除了上述优化方法外，实际上还有一些其他的路数，如增加数据库的锁等待监控、定时清除inactive的链接、将虚拟化部署改为物理机部署、优化备份方式等等。