全球知名技术盛会－全球软件开发大会（简称QCon）于2017年4月16日在国家会议中心盛大召开。作为全球颇具影响力的技术盛会，自2007年3月份首次举办以来，已经有超过万名高级技术人员参加过QCon大会。
光大银行信息科技部系统运维中心高级经理彭晓在QCon“听云新一代APM技术专场”发表了题为《光大银行应用性能管理实践》的演讲，现场分享了光大银行建立的全方位的应用监控体系和应用系统容量管理机制，以及通过应用监控和生产系统容量分析实现应用系统性能问题的预警，驱动应用系统的应用架构、交易处理模式优化，提升应用系统应对大交易量、高并发的处理能力与效率的技术实践。
以下为分享正文：
互联网跟传统之间的区别，相对比较少。今天，我作为一个传统行业的IT工作者很高兴能够与大家做一些交流，我分享的题目是《是什么优化，让我们坦荡》。作为一个IT人员，我们关注的是什么，我们关注的是系统的稳定，服务好我们的客户。那么到底怎么做才能让我们放心？今天我会和大家分享一下整个光大银行性能管理的实践。和前两位分享不同的是，我会讲到两点差异，一个是传统行业，第二个不讲具体的技术，涉及的面比较多一些。
一、夯实基础，安全运营，优质服务
银行经常会面临很大的挑战，包括交易量的突增，客户服务要求的不断的增强，监管的要求，还有运营成本的压力，这些对于传统银行业来说确实都是很大的挑战。具体来说，面对这样的挑战，到底是做救护队长，还是曲突徙薪，也就是防患于未然，其实最终目标都是为了服务好客户。从光大来说，总体思路是安全运营从源头，从架构、开发、测试、运维，全面把控风险与质量管理，从源头解决好每一个环节的交付质量。以下几个词，虽然有一些虚，但是很重要，尤其从某一个角度来说，如履薄冰，还有举轻若重，举轻若重就是对每一个环节都需要关注。
二、系统稳定运行是提供优质服务的基础
稳定运行是提供优质服务的基础。尤其是在当前的复杂信息的脉络之下如何准确对问题进行定位，这就需要做好监控管理。如果降低成本的情况下做好运维关系，就需要对性能进行优化。这里附图，是恰当的一个比喻。
三、银行应用性能管理机制
Gartner 将应用性能管理概念框架分为：终端用户体验、应用运行架构、业务交易监控、深度监控、报告分析。
首先，这里要提到扁鹊三兄弟，他们人几个有不同的特点，扁鹊是治急症，中兄是治初症，大哥治未病，在没有生病之前防患于未然。为什么在这里要提到扁鹊三兄弟，在我们的几个体系当中，建立完善的监控体系，利用监控发现问题，这就像在治急症。第二，是建立适度的容量的管理体系，利用管理手段解决问题。第三是监控全面的架构治理和研发的一个体系，包括利用一些非功能性标准的模型来量化优化的效果。下面实际上是和扁鹊三兄弟相关，我们认为我们监控，治急症、容量及问题管理体系是治初症，架构开发规范及非共嫩体系是治未病。
看一下ODD，涉及到四个方面:
（1）数据采集，通过数据的长期的一个采集来建立一个生产系统的运行档案，这个和监控管理和事件管理密切相关。
（2）定位，从时间的维度建立分析诊断的模型，通过趋势分析建立性能基线，实现应用性能问题定位，其中包括容量的分析和问题的发现。
（3）发现的问题以后，进行相关的优化。通过事件关系，问题管理驱动优化，直接优化以后，按照非功能性测试的标准进行相关的测试。
（4）最终优化完毕，投产运行。在投产运行之后，用修复以后进入新一轮的性能管理，在此基础上也会对于周期性的对相关的制度和规范来进行一个重检，这就是ODD的模型。
再看全方位的监控体系，包括人员的分工，一线二线监控人员，包括运维质量的人员，二线技术人员。这是应用的监控指标，我们将性能分为几个维度，比如说交易量（应用服务的负载量）、响应时间（应用服务核心性能指标）、成功率（应用服务核心可用性指标）、返回码（应用服务可用性状态）、交易类别（区分交易、子交易类别）、交易渠道（区分交易发起的渠道），通过监控发现问题。
看一下容量体系。容量体系从光大来说，是从2011年建立的一个基本型容量管理，，2012年到2013年是充裕型管理。2014年到现在叫做适度型管理，在这里容量、投入、需求和业务需求尽量的匹配。它主要通过几个管理的环节，包括自评估环节，就是由运维人员对生产各领域情况进行评估，再进行是专家评估环节，再到组织级评估环节，每月会对重要的系统进行容量评估，形成改进计划。容量评估域，包括多维度9个领域的评估，存储、网络、系统、数据库、中间件、应用、批量、备份清理、事件等，涵盖了基础设施、基础软件、运行状态、运行状态。
再就是架构非功能标准应用规范问题，从架构、基础软件、网络、容量，各个维度建立标准的专家模型，涉及到十多个领域，包括一百多项的标准。而且每年也会对非功能的专家模型进行修订，同时也建立了交付体系。我们可以看到，这就一个控制过程的前移，运维包括我们的专家，数据库专家，中间件专家逐步参与到前期过程中，那么包括需求分析阶段、设计阶段、开发阶段、测试阶段，这些阶段通过非功能性的标准覆盖掉，在此之后才进行一个应用投产的交付标准以及验收的交付的阶段。之前可能会出现这样的一个问题，一个系统上线了，运维说不能上，这个有问题，这个在传统企业容易出现的问题，我们在前期在设计阶段已经参与到这个系统的过程中，建设过程当中。最终实现应用性能管理机制，全面覆盖总分行全部生产系统，管理机制严格执行，推动改进。
再看一下管理工具，跟业务性能有关的监控。一个是BPC，部署原则，是联机交易系统部署BPC，批量类系统和非交易系统不部署。第二个涉及到加密，报文是有加密的，那么有加密的系统，没有加密的系统建立这个BBC的监控。那么再往下看，就是具体的应用。
红色反映的是历史上每一分钟，这一类交易或者系统的峰值。蓝色是反映的截止到当前，系统的交易量，峰值是什么，从这非常直观的可以看到系统的运行状况，来看到这是从业务层交易的监控。再往下就是利用了数据库的同步复制的一个技术。实现的交易流水的在线的分析。主要的策略是对于重要系统当中的链接交易系统进行监控的覆盖，同时根据OGG，流水表，当然还有一个要求，流水表不会对历史数据的删除和分析的操作，这是具体的应用。
这是总线系统，以及前台的渠道服务，后端的服务系统，这表示的是什么呢？这个红色是表示这个渠道系统，我从这个渠道它截止到当时的时间点，交易量什么情况。历史上的峰值的交易量什么情况，这是当前交易量的情况。从这张图也是实际上是一个业务层的监控，能够非常形象直观看出一个总线系统、渠道系统、服务系统当天交易量的情况。
TOPA是自行开发数据库监控的一个工具。主要的原理是对不同时段和不同系统的数据分析对比，利用历史数据定义系统的正常状态趋势基线，通过趋势基线反映系统是否异常。原则样本足够多，尽可能减少极值对趋势基线的影响。第二个基于时间度量，以时间维度分析何时优化，如何优化。这其中有数据应用、数据库压力，反映数据库的活动进程和CPU资源匹配的关系；还有渠道系统，不同的颜色浅绿表示压力很低，紫色是压力很高，渠道系统是9-10点压力相对比较高，下午14点到16点系统压力比较高。再往下看就是后台系统，后台系统可以看到压力相对渠道系统相对小一些，也是在上午，下午某一些时段压力相对大一些。再往后就是总线系统，总线系统资源相对充裕，因为总线系统只是一个交换系统，没有复杂的数据库的压力，所以压力并不大。
四、传统银行架构下的应用系统调优实践
光大银行的应用系统调优实践分为两部分，一个是应用性能调优关联因素分析，第二个是关联因素的调优实践。性能问题的解决是靠综合治理才能解决的，不是单一的，单一的脚步解决这个问题。
这里将电子支付作为案例来分析如何进行应用性能的调优，这是电子支付整体业务的架构，第三方商户和其他的一些商户是通过专线的方式接入到电子支付系统，普通商户通过互联网介入电子支付系统。交付以后进行一些预处理，然后进入总线系统，对互联网行业来说没有总线系统，对传统的银行这种传统企业总线系统是存在的。接着进入到电子支付的后台的相关的业务处理，最终通过总线处理进入到账户管理，客户管理，信用卡等相关的业务。
另外，从总线系统来看银行业务和支付业务的快速增长－交易量增值的变化及TPS增值的变化。首先是交易集中分发，交易转换枢纽，交易量比较大，连接前端渠道系统，服务系统，所以它的交易量非常大，交易增速快，年交易增长已经到了十几倍。交易并发大，包括电商促销，银行内部促销交易并发大。另外交易处理时间非常快，对业务响应时间要求高。
总线系统呈两个趋势，一个高并发，高增长的两个趋势。这里会涉及到基础设施，包括网络设备。然后是操作系统、数据库，包括中间件，包括业务系统，业务系统之间的关联关系。关联因素涉及的面非常广，涉及了具体的调优时间有哪些。
首先看网络层，一个是交易竖井的优化，由于专线介入的商户，存在交易路径非常长，跨越安全的域非常多，而且节点多，地址转换非常复杂，拆除机制不同，有些拆链时间不及时，会造成有一些端口无法及时释放，所以给支付交易相关的成功率的提升和相关故障诊断带来困难。
在具体的优化做了几个事。一是减少电子支付的交易路径的网络域和相关的节点，之前看相关的节点减少很多。第二个解决商户的快捷交易会话不拆除和源端口复用问题。我们发现有一些商户地址转换，原地址转换成一个地址，这样大量的交易使用同一个源地址，对银行进行访问，造成端口的重用会导致问题。为了解决这个问题，我们是和相关的商户进行沟通，要求在原地址转换方面用多个地址进行访问。第二个就是在断链的时候，有些商户断链不及时，有的时候会自己在防火墙上强制设定断链的时间点提升交易的效率。这样通过这些优化的措施以后，最终带来的一个收益是支付掉单率降低50%。
这是一个多互联网出口的改造，这一块对于互联网企业相对来说是相对比较简单的。主要是对于不同的客户电信的用户走电信的相关的接入口，对于联通的走联通接入口，这个相对比较简单一些。另外包括对异地，光大银行两地三中心，北京两个同城中心，武汉异地中心，南方有一部分客户也是通过南方直接接入到武汉异地中心提升客户的感受和效率，这是多出口网络的优化。
说一下存储层的优化。
首先从交易的处置来看，从CPU，CPU性能非常高，在CPU的指令需要消耗一个使用周期。为了支持这个指令，可能找到相关的数据，它需要的时间是100倍，100个使用周期。如果在CACHE没有，就要到内存里面找，如果内存里面还没有，那需要到存储上去找，或者甚至到磁盘上去找，所以它需要少好的是十万倍甚至更长。我们能看到的性能优化有一个关键点就是在IO层面，调优工作可以：首先是IO条带化，这个在操作系统和存储的层面进行一个密切的配合，而且一般采用两极条的设置。第二个通过充分的压力测试选择合适的条带大小和条带的宽度。光大银行的交易特别普通的数据库日志卷一般建议带大大小K，数据卷使用XXXK。
第二个根据IO特征进行分组分策略设置，对于不同IO对象的识别进行合理的分组来避免相互的干扰。对于IO性能要求高的相关的一些组件和数据库的日志卷会配置单独IO通道。第三个对IO并发使用大的组件使用到磁盘尽量做到分离。如何消除IO链路的瓶颈?IO链路的环节涉及到HBA无卡、交换机、存储前端口、后端口，包括磁盘都有相关的使用率。对于IO要求高的系统，我们一般要求使用率控制在50%以下。然后通过搜集喜爱路径上各个环节性能的指标找到性能的瓶颈。同时，需要资源使用和IO性能之间要找到相干的平衡点。当然除了自身，就是设备的设置存储的分配等等，还有应用的优化，主要是来减少不必要的IO。第一个是优化，从数据库的角度，优化数据库表的设计，建立合适的索引，减少全表扫描。第二个将频繁处理的数据缓存到内存中，减少直接对磁盘的IO，通过这些工作之后，确实明显感受到应用优化在IO的优化中最为显著。主要的思路通过不同的效应补齐短板。
存储层的优化与数据库也密切相关，包括数据的分级应用和数据的分级存储。具体来看，我们把数据从时间维度分成三个部分，一个是历史数据、一个近线数据、一个是当前数据。从操作维度我们分为只读数据、读写数据，还有静态的数据。对于从时间维度来看，基于大数据技术建立历史数据查询系统，对历史数据，我们一般是把十几个月之前的历史数据根据访问放到大数据里面，提升数据的存取访问，提高历史数据查询效率，减少对生产联机数据库的压力。使用中高端存储进行数据存放，采用传统的关系型数据库进行数据处理访问。数据存放在高端存储当中，对高热度在存储的使用SSD磁盘，采用传统关系型数据库可内存数据库相结合的方式进行数据的处理。
从操作的维度对只读数据、读写数据、静态数据的处理。对只读数据，通过数据库的复制技术，建立只读数据库，分散联机数据库的运行压力，在应用交易级别实现读写分离。这一部分特点读写访问量比较大，事务一致性要求高，一般采取传统关系数据库加高端存储处理方式，静态一般是参数的配置的数据，它的修改的频度低一点，访问并发量大，对这一般数据，一般采用内存数据库方技术，在应用服务器端缓存数据来提高处理性能。总体来说去除热点，分散压力。
依据运行经验，制定OS参数标准。不限制应用使用OS资源，系统的资源就是给应用来使用的，这是一个大前提。第二个是一般不采用更改OS原有调度方式的参数，来确定系统的稳定性，就是稳定性还是优先的，这是操作系统。
光大数据库的优化，具体的数据库实例是在几百个，总存储空间千TB，每年运行的SQL百亿次，每天读取数据百TB，修改每天十个TB。这是总线系统，它有反交易，反交易是在凌晨出现反交易，比如大家住酒店会做预授权，操作预授权。第二个分区字段上的存在低效索引，在当前表中查询历史数据。第三个特点是绑定变量的窥视特性和统计信息计算后，使用低效索引。为什么会出现这样？第一个是量变了，原来在凌晨这个交易相对比较少，就几笔，甚至几十笔，突然出现了一个特点是说在凌晨有大量的反交易，所以原来的性能，原本可以接受的，由于数据量或者是并发量的变化，导致了整体的性能变差。第二个是从原来应用设计的阶段，所谓基于原有的应用逻辑和数据库设计，不存在高效的数据访问方式，存在低效的数据访问方式，这是一个背景。第二个是执行计划，原来本来存在高效的数据访问方式，但是由于数据库的统计特性等发生变化，而没有使用到高效的方式。
那么如何解决？对于量的变化，我们通过容量管理机制不断发现性能的变化，通过定期发送SQL性能报告。从应用设计方面，包括分区、合理索引、物化视觉，利用数据库本身的特性，包括表内压缩，为什么表内压缩，因为CPU性能是足够的。我们用CPU来换IO的性能，来解决这个问题。我们叫分区1.0，2.0。分区1.0，清理历史数据。分区2.0是用于清理历史数据，用于性能优化分散热点和加快表连接。从优化的程序逻辑上看，限制用户的条件，减少不必要的数据访问。从架构层面，数据库，转到MPP平台，还有一部分转到大数据平台。针对大表全表扫描及其他低效SQL，DBA将提交问题单。对执行计划方面，规范数据库参数配置稳定优先，关闭部分动态功能，开发统计信息搜集工具。
具体来说一下分区。说到分区，第一前面提到按照数据的生命周期进行分区，分区以后会发现数据的导入压缩清理发生了较大的变化。第二个是包括HASL分区，HASH目的采取相关的自段作为关键的索引，使用了这个分区，我们的交易流水，交易流水是流水号是一个关键数据，交易流水表承受的压力比较大，那采用HASH无分区以后把一些连续的交易插到不头的磁盘分散热点的数据。分区之三是Range+HASH二级分区，分区键即连接条件，关联表分区键相同，分区值相同。主要是加速大数据量连接。通过这个分区之后，对于刚才说的一万条数据，两个一万条记录的数据库表的连接，一千条数据库表的连接完全是不一样的。这通过分区技术加速表的连接。
对于中间件，依据运行经验制定了MW参数标准。具体两个标准，第一个中间件的参数设置从应用需求出发，中间件资源一次配置到位，避免自动调整带来的冲击。我们有一些经验，中间件的参数自动拓展，在拓展当中带来运营系统不稳定，所以就需要尽量一次性配置到位，避免自动调整带来冲击。
与应用相关的关联，这是支付系统，主要采取的措施包括服务的拆分、对于支付网关的分离部署、对于较大的第三的网关进行独立的部署。负载均衡，这个是比较常用的，我们通过实现负载均衡多个机制。
接下来是总线系统，第一是负载均衡，第二是异步提交，我们用日志支持系统异步，其中包括两种提交方式：应用日志文件异步提交，应用日志数据库异步批量提交，支持在线实施策略调整。另外是一个是存储转发，针对时效性低，重要性高的业务设置存储转发策略，将业务要事先存储，后转发。一笔交易，有可能冲10笔甚至更多，这样对应用系统带来了很大的压力，无论对存储转发或者机制都有限制，是一笔，三次，接下来靠对账机制解决问题。
总线系统采取几个措施，一个是服务分组，按照后台系统，业务特点进行服务分组，降低系统之间不同业务之间相互的影响。第二个是流量控制，这个是比较常用。多维护限流，可以按照重要系统，重要业务重要交易来设置限流策略。第三个在线生效，动态限流策略调整。信用卡通过双活总线分流提高信用卡系统容量，包括分流交易负载，互为高可用备份可以实时进行站点切换。前面提到的接入层渠道实现交易度，客流量的控制。交易处理层按业务分层降低耦合度。
总线系统按需分流，按照BIN分流，按照功能类别分流，还有一个代处理的机制，后台的系统，前面有代授权，非金融平台可根据交易码代处理查询交易，金融前置可进行代授权，冲突比较大的时候，把交椅分到前端系统来进行代处理。
这是基于微服务的架构，主要是核心系统，参考类似集装箱货运模式，按同类交易打包，通过联机批量方式实现业务集中处理，对应用系统服务进行联机批量的微服务拆分，按批量的任务、按业务的特点进行分组。像核心系统会采取两种方式进行并发处理，一个是按营业机构将批量任务拆分成小的业务处理单元。第二个按照待处理任务总量每多少万笔交易进行分组。
这是我们的核心系统，是按业务类型对业务进行分组，对同类业务对应的交易分配到一个服务商。对某类业务相关的交易商统一分配到某组服务，此类分组可以降低整个系统的服务的耦合度，而且避免各服务之间出现资源的争抢，同时在应对某类业务突增的时候可以通过灵活调整核心系统的服务署来提高系统的处理能力。
光大银行使用的性能管理，包括相关的机制，从监控，从容量管理，从规划和架构，对未来的展望主要涉及到三个方面，第一个是基础应用平台的持续优化和全面推广。我们对于基础平台的相关的持续优化以后，把它全面推广，这样来提升优化的效果和减少成本。第二个是考虑的是自主可控和新技术应用带来的挑战，包括自主可控、自主可控中间件、自主可控数据库，资质可控操作系统等。
这些应用会给我们带来什么样的变化？第一个对它的特性不了解，对它的相关的标准不了解，我们可能也缺少相关的一些工具，所以这一块会给我们带来新的一个挑战，那我们会加大这一块的投入，包括新技术的应用带来的挑战提高自主可控的能力。优质服务，客户体验各环节的提升，对传统银行业而言，我们之前更多关注后台的系统，对前端客户体验的投入不如在座的各位包括很多互联网企业考虑那么多，所以后续我们对于客户体验各个环节整体的一个性能的提升来提升我们的服务能力，这是应用性能优化的一个对未来的展望。
