高并发环境下的MBOSS 系统架构优化方案

邓晓蓓

（中国电信广东公司企业信息化事业部，广东广州 510081）

0 引言

广东公司MBOSS 核心系统承载着营业一线的业务受理、服务开通等关键服务，系统运行的稳定性、高效性直接影响着营业一线对外服务的质量和效率。由于广东公司的业务量大，特别是每月月底业务高峰期，业务量比平常时间业务量更增涨30%～100%，突增的业务量，造成大量并发的服务调用，对MBOSS 核心系统网络连接负载造成很大的冲击，容易造成响应延时、服务排队等问题。针对此类问题，常规的解决方案是针对核心系统按业务进行分拆，部署到新的系统硬件架构上，以提高系统的并发访问性能，但需增加大量的硬件设备投资，实施周期长，对业务运行影响大。针对此类高并发引起的系统延时问题，本文从问题的源头开展深入分析，全面核查业务量的变化情况、应用服务的运行情况、系统平台的资源情况，并准确定位各个系统性能瓶颈，制定出高并发环境下的IT 架构优化方案。

1 问题分析

1.1 系统架构

按照均衡用户数原则，广东电信MBOSS 核心系统采用分大区部署模式。每一个大区的数据库使用两节点的Oracle 数据库RAC，为了尽可能避免RAC 实例之间出现过多的数据传输，采用一部分地市接入RAC 一个节点，另一部分地市接入RAC 的另外一个节点的办法。应用节点包含TUXEDO 和WEBLOGIC 中间件应用，按地市应用域分别部署，通过千兆以太网络连接访问数据库。应用主机及数据库主机集群均部署在同一生产机房内。以其中一个大区为例，系统部署架构如图1所示。

图1 系统架构

我们首先选取了延时问题最为突出的A 大区地市2 和同一大区的地市1 进行对比分析。地市2 的业务量远低于地市1，系统架构部署和地市1 基本相同。但地市2 在月末出现服务延时问题极为突出，其中堵塞最为严重的OSQ 服务，5—7 月共出现121 次堵塞，其中最长一次的堵塞时间长达285min，对营业一线业务受理造成较大的延时影响。而地市1 业务量虽然基数大，但极小出现堵塞问题。

由于此类性能问题影响因素众多，堵塞出现的时间不确定，难以在测试环境下重现，因此需要从业务量、应用部署、数据库、主机、网络等层面展开多维度分析，对性能瓶颈进行定位，分析的方法主要包括数据比对法和硬件排除法。

1.2 业务量分析

由于此类问题一般在月末出现较多，跟月底业务量增长存在一定的关联关系。我们选取了A 大区的各个分公司的月末业务量与平日进行了对比分析，结果见表1。可见各地市月底的业务量增涨20%～100%。其中地市1 平日业务量基数大，月底增幅相对较小，约20%左右，地市2 平日业务量基数小，月底增幅相对较大，超过100%。

表1 各地市业务量统计

1.3 应用部署分析

地市1 和地市2 的应用服务部署在同型的中端小型机上，由于地市1 业务量大，单独部署在2 台小型机上，地市2 和地市3、地市4 业务量较小，合并部署在另外2 台小型机上。这四个地市的数据库服务部署在同一套OracleRAC 数据库上，地市1 单独部署在RAC 实例节点1，地市2 和地市3、地市4 以及数据交换服务部署在RAC 实例节点2。

1.4 主机资源分析

数据库主机和应用主机CPU、内存资源都比较空闲，基本在80%以内。分析情况如图2 数据库主机CPU使用率和图3 应用主机CPU 使用率所示。

图2 数据库主机CPU 使用率

图3 应用主机CPU 使用率

1.5 数据库资源分析

从表2 数据库连接数分析情况可以看到，地市2数据库服务与多个地市及交换节点部署在RAC 实例节点2 上，主机的网络连接数比RAC 实例节点1 大将近2 倍。

表2 数据库连接数分析

1.6 网络资源分析

地市2 和地市1 应用服务器与数据库服务器之间的网络架构基本一致。通过排除法将应用服务器与数据库服务器之间的主机、网络交换机端口逐个进行重启排除故障，均无发现硬件问题。通过网络监控软件分析如图4 所示，网络流量未超过百兆，未达到网卡最大流量。

图4 网卡流量分析

1.7 分析结论

通过大量的性能比对和测试排查工作，排除了部分影响因素，例如主机CPU、内存，存储IO，网络带宽等资源都是相对富余的，同时我们通过关联分析地市2的OSQ 服务排队和以下因素关联度非常高的。Ping 延时：服务排队期间，从应用主机ping 数据库主机存在明显的延时，服务排队期间，应用程序执行的SQL 语句较为简单，在数据库端执行时间很短，但执行频率非常高。

因此可以得出以下结论：地市2 数据库服务与多个地市及交换节点部署在同一台主机服务器上，数据库主机的网络连接数明显高于其他数据库主机。地市2总体业务量不大，但月底业务量增幅较大，经分析是由于后台提交批量业务较大。此类业务会导致应用程序频繁发起大量的数据库并发访问，进而导致出现类似网络风暴的性能问题，使应用服务器和数据库之间的网络访问出现较为明显的延时。由于该核心业务OSQ需要连接访问数据库非常频繁，一旦出现网络延时将会明显影响数据处理速度，进而导致严重的业务堵塞。

2 优化方案

由于此类性能问题特殊性，并不能按照常规的手段单纯靠硬件扩容手段来解决。因此考虑重点从以下三方面着手。

2.1 扩展网络并发连接访问能力

针对排队问题最为突出地市2 的OSQ 服务全面排查，定位到性能瓶颈在于应用服务器到数据库服务器之间网络访问延时。产生问题的主要原因在于高并发量的数据库连接访问。解决此类问题需要从应用程序、数据库、主机、网络架构综合考虑，增加新的数据库连接通道，从而扩展系统并发连接访问能力。

由于此类问题涉及面较广，目前并无成熟可用的解决方案，通过多次反复尝试，创新性使用多通道方案实现数据库访问连接。

在Oracle 数据库系统架构中，通过监听器（LISTENER）管理Oracle 数据库服务器端与客户端之间的通信。监听器通常部署在数据库主机对外提供服务的特定网卡端口上，进行监听连接请求，并将连接转发给数据库。在常规的部署方案中，单台数据库服务器通过唯一的网卡对外提供连接服务。而在此案例中的高并发环境下，控制网卡连接的部件已成为系统瓶颈之一，因此需进一步增加对外提供服务的网卡并配置相应的数据库监听服务，具体实现方案如图5 所示。

图5 系统架构优化方案

通过以上创新性的多通道连接方案，能极大地优化应用服务与数据库连接效率，分流高并发的网络访问。

2.2 改造应用实现错峰业务处理

通过数据分析发现批量业务处理也是导致此类高并发访问的关键因素之一，因此通过应用程序改造，实现对批量业务错峰处理功能，在日间业务高峰期对批量业务进行拦截，错峰安排至夜间业务相对空闲的时间进行处理，避免在业务高峰期产生高并发的数据连接访问。

2.3 优化SQL 执行减少阻塞事件

通过优化SQL 语句执行计划，数据库表碎片整理，调整表分析策略等手段，提高应用SQL 语句执行效率，避免由于高消耗SQL 造成的阻塞事件。

3 优化效果

优化方案第一阶段首先在分公司2 实施取得明显效果，其中核心OSQ 服务处理性能提升5 倍以上，OSQ服务处理耗时比对如图6 所示。

图6 OSQ 服务处理耗时比对

后续逐步推广至全省其他分公司，系统关键性能指标也得到了较大的提升。有效解决了月底业务高峰期由于高并发调用引发的系统访问延时问题，改善一线营销人员的使用感知。且该方案较常规的硬件扩容方案节约了数百万的硬件设备投入，对业务运行影响非常小。该优化方案由于技术创新、实施效果显著，获广东电信劳动竞赛、岗位创新等奖项。