传统企业核心系统架构优化行动指南

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

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

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

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

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

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

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

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

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

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

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

二、业务优化

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

1、sql优化**

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

2、代码优化**

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

3、架构优化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、总结**

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

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