2019 年 4 月
总 第一期
我们正处在一个金融与互联网融合的越来越紧密的时代，一切都发生着变革。作为一个金融人我们能想到金融业在向互联网延伸，作为一个科技人我们也能看到金融科技不断在触碰互联网科技，金融行业对科技的要求已远超以往。无锡农商行视信息科技为企业发展的基石，在自主可控、科技先行的理念的引导下，在10几年的发展中培养了这样一支科技先锋军，在科技探索、引领业务方面发挥了重要作用。
自主可控、探索创新一直以来是无锡农商行科技的重中之重。自主可控是对技术能力掌握深度的延伸，在出现复杂问题的情况下有能力自行发现并解决问题，维护着业务连续性；创新探索则是在高度上的拓展，体现了科技对业务的支撑及引领能力。深度和高度相结合，使我行科技在人工智能、大数据、区块链、云计算爆发式增长的今天可以做到游刃有余，成为业务发展的助推器，进而推动我行的高速高质量的发展。
习近平总书记"大力发展科学技术，努力成为世界主要科学中心和创新高地"，"坚持科技创新和制度创新'双轮驱动'，以问题为导向，以需求为牵引，在创新主体、创新基础、创新资源、创新环境等方面持续用力，强化国家战略科技力量，提升国家创新体系整体效能"是对国家的要求，我行从自我做起，积极响应，不断加快科技进步，以自身的努力为总书记重要讲话践行。
本期刊《锡银科技》以技术分享为主线，汇聚了科技信息部各专业技术人员在解决疑难技术问题、科技规划、成果展示、新技术探索等方面的文章，希望将知识共享，供大家学习和参考，共同打造一个相互借鉴、共同进步的氛围，从而推动行内及同行间信息科技发展。
introduction
序 / 言
INTRODUCTION
目录
Contents
机器学习入门：模型评估指标 04
开发中心--杨晨
基于solr的hbase二级索引性能优化 13
开发中心--刘力
一根光纤引起的"不安" 18
运维中心--高晓峰
Linux性能问题排查之TOP命令详解 34
运维中心--王旭
性能调优怎么调-核心系统优化 44
质量中心--张波
探索新形势下的银行业务逻辑攻防价值 53
安全中心--潘林波
浅谈负载均衡实现健康检查的几种方式 75
运维中心--鲍一鸿
复杂状态转换分析的小手段 90
运维中心--沈志浩
DataStage应用高可用性浅谈 99
开发中心--顾琪冰
证书链浅析 107
开发中心--戈珺
机器学习入门：模型评估指标
文章：开发中心--杨晨
1.当前形势
近几年各界对人工智能的兴趣激增，自2011年以来，开发与人工智能相关的产品和技术并使之商业化的公司已获得超过总计20亿美元的风险投资，而科技巨头更是投资数十亿美元收购那些人工智能初创公司。人工智能领域的相关报道铺天盖地。前两天，特朗普签署行政命令，旨在推动美国在人工智能(AI)领域的发展，同时削弱中国在这一领域的强劲势头。 可见人工智能的研究竞争已经进入白热化阶段，已经上升到国家竞争的层面。
2.项目背景
我行对前沿科技始终保持着高敏锐度，在这科技变革的大时代里，争作科技变革的引领者。在去年年底的百度助贷项目中，成功将机器学习应用于贷前准入，在降低不良率的同时，提升了贷款准入的通过率。体现出了机器学习的巨大应用价值。然而，当模型建好之后，如何体现模型的价值，如何向业务人员解释模型的优越性对于模型开发者来讲是个头疼的问题。
01 / 概述
我行于2018年底成功地将机器学习与百度助贷项目结合，实现了第一个人工智能场景的落地。由于机器学习入门难，理论性强，向他人解释训练好的模型便是个麻烦事儿。本文将为您解除这样的烦恼。
锡 / 银 / 科 / 技 第4页
降低不良率的同时，提升了贷款准入的通过率。体现出了机器学习的巨大应用价值。然而，当模型建好之后，如何体现模型的价值，如何向业务人员解释模型的优越性对于模型开发者来讲是个头疼的问题。
02 / 原理
模型训练好，必须要通过各种指标去衡量模型的好坏，也就是模型的泛化能力。模型的评估指标有很多，笔者在刚开始学习的时候，也是焦头烂额，有时候自己理解了，但又很难跟别人解释清楚，本节将以理论知识结合图片的形式，详细介绍分类模型的各种评估指标以及ROC和AUC值。
1.混淆矩阵
对于二分类的模型，预测结果与实际结果分别可以取0和1。我们用N(negative)和P(positive)代替0和1，T(true)和F(false)表示预测正确和错误。将他们两两组合，就形成了下图所示的混淆矩阵（注意：组合结果都是针对预测结果而言的）。
图一：混淆矩阵
则图中的四种结果解释为：
(a) TP：预测为1，实际为1，即预测正确；
(b) FP：预测为1，实际为0，即预测错误；
(c) FN：预测为0，实际为1，即预测错确；
(d) TN：预测为0，实际为0，即预测正确；
2.准确率
准确率的定义是预测正确的结果占总样本的百分比。
公式：准确率=(TP+TN)/(TP+TN+FP+FN)
即，绿色部分和 / （ 绿色部分和 + 红色部分和 ）
图二：准确率
实际应用场景中，由于样本不平衡的问题，导致了得到的高准确率结果含有很大的水分。即如果样本不平衡，准确率就会失效。这样就衍生出了另外两个指标：精准率和召回率。
锡 / 银 / 科 / 技 第5页
则图中的四种结果解释为：
(a) TP：预测为1，实际为1，即预测正确；
(b) FP：预测为1，实际为0，即预测错误；
(c) FN：预测为0，实际为1，即预测错确；
(d) TN：预测为0，实际为0，即预测正确；
2.准确率
准确率的定义是预测正确的结果占总样本的百分比。
公式：准确率=(TP+TN)/(TP+TN+FP+FN)
即，绿色部分和 / （ 绿色部分和 + 红色部分和 ）
图二：准确率
实际应用场景中，由于样本不平衡的问题，导致了得到的高准确率结果含有很大的水分。即如果样本不平衡，准确率就会失效。这样就衍生出了另外两个指标：精准率和召回率。
锡银科技
Company dynamics
返回目录
锡 / 银 / 科 / 技 第6页
3.精准率
精准率（Precision）又叫查准率，是指在所有被预测为正的样本中实际为正的样本的概率。
公式：精准率=TP/(TP+FP)
即，绿色部分 / （ 绿色部分 + 红色部分）
图三：精准率
4.召回率
召回率（Recall）又叫查全率，是指在实际为正的样本中被预测为正样本的概率。
公式：召回率=TP/(TP+FN)
即，绿色部分 / (绿色部分 + 红色部分)
图四：召回率
以信用卡逾期为背景，召回率越高，代表实际逾期用户被预测出来的概率越高，它的含义类似：宁可错杀一千，绝不放过一个。所以召回率的提高，往往意味着精准率的下降。
5.灵敏度、特异度、真正率、假正率
灵敏度(Sensitivity) = TP/(TP+FN)，即实际为正样本预测成正样本的概率
特异度(Specificity) = TN/(FP+TN)，即实际为负样本预测成负样本的概率
真正率(TPR) = 灵敏度 = TP/(TP+FN)，即实际为正样本预测成正样本的概率
假正率(FPR) = 1- 特异度 = FP/(FP+TN)，即实际为负样本预测成正样本的概率
锡 / 银 / 科 / 技 第7页
以信用卡逾期为背景，召回率越高，代表实际逾期用户被预测出来的概率越高，它的含义类似：宁可错杀一千，绝不放过一个。所以召回率的提高，往往意味着精准率的下降。
5.灵敏度、特异度、真正率、假正率
灵敏度(Sensitivity) = TP/(TP+FN)，即实际为正样本预测成正样本的概率
特异度(Specificity) = TN/(FP+TN)，即实际为负样本预测成负样本的概率
真正率(TPR) = 灵敏度 = TP/(TP+FN)，即实际为正样本预测成正样本的概率
假正率(FPR) = 1- 特异度 = FP/(FP+TN)，即实际为负样本预测成正样本的概率
不难看出：召回率 = 灵敏度 = 查全率 = 真正率 = TPR = TP/(TP+FN)它们都是指实际正样本中预测为正样本的概率。
灵敏度、真正率：绿色部分 / (绿色部分 + 红色部分)
图五：灵敏度、真正率
(1- 特异度)、假正率：绿色部分 / (绿色部分 + 红色部分)
图六：特异度、假正率
真正率和假正率这两个指标跟正负样本的比例是无关的。所以当样本比例失衡的情况下，准确率不如这两个指标好用。
6.ROC曲线
ROC（Receiver Operating Characteristic）曲线，又称接受者操作特征曲线。ROC曲线的横坐标是假阳性比值（假正率），纵坐标是真阳性比值（真正率）。
锡 / 银 / 科 / 技 第8页
(1- 特异度)、假正率：绿色部分 / (绿色部分 + 红色部分)
图六：特异度、假正率
真正率和假正率这两个指标跟正负样本的比例是无关的。所以当样本比例失衡的情况下，准确率不如这两个指标好用。
6.ROC曲线
ROC（Receiver Operating Characteristic）曲线，又称接受者操作特征曲线。ROC曲线的横坐标是假阳性比值（假正率），纵坐标是真阳性比值（真正率）。
锡银科技
Company dynamics
图七：ROC曲线
假正率反应了模型虚报的响应程度，真正率反应了模型预测响应的覆盖程度。所以我们希望，假正率越小，真正率越高越好，即虚报的少，覆盖的多。也就是说，TPR越高，FPR越低，模型就越好。反应到ROC图形上，也就是取现越陡峭，越朝着左上方突出，模型效果越好。
7.AUC值
AUC是基于ROC曲线的，被称为曲线下面积（Area Under Curve）。
图八：不同AUC值效果展示
如上图所示，在ROC曲线图上，如果我们连接对角线，它的面积正好是0.5。对角线的实际含义是：随机判断响应与不响应，正负样本覆盖率应该都是50%，表示随机效果。ROC曲线越陡越好，所以理想值就是1，一个正方形，而最差的随机判断都有0.5，所以一般AUC的值是介于0.5到1之间的。
百度助贷项目中，我们将机器学习算法应用于贷前准入规则中。旨在降低贷款不良率，同时能够让更多的客户准入。在经过业务访谈、特征筛选、特征工程、数据处理等环节后，我们采用GBDT算法建模，得到最终的模型。
锡 / 银 / 科 / 技 第9页
假正率反应了模型虚报的响应程度，真正率反应了模型预测响应的覆盖程度。所以我们希望，假正率越小，真正率越高越好，即虚报的少，覆盖的多。也就是说，TPR越高，FPR越低，模型就越好。反应到ROC图形上，也就是取现越陡峭，越朝着左上方突出，模型效果越好。
7.AUC值
AUC是基于ROC曲线的，被称为曲线下面积（AreaUnder Curve）。
图八：不同AUC值效果展示
如上图所示，在ROC曲线图上，如果我们连接对角线，它的面积正好是0.5。对角线的实际含义是：随机判断响应与不响应，正负样本覆盖率应该都是50%，表示随机效果。ROC曲线越陡越好，所以理想值就是1，一个正方形，而最差的随机判断都有0.5，所以一般AUC的值是介于0.5到1之间的。
百度助贷项目中，我们将机器学习算法应用于贷前准入规则中。旨在降低贷款不良率，同时能够让更多的客户准入。在经过业务访谈、特征筛选、特征工程、数据处理等环节后，我们采用GBDT算法建模，得到最终的模型。
锡 / 银 / 科 / 技 第10页
模型虽然得到了，但是作为开发人员，你必须向业务人员证明，为什么你的模型会比专家规则好。经过上一节的理论介绍后，我们知道可以从召回率、精准率和通过率三个模型评估指标来介绍我们的模型。
召回率在该项目中的意义是：模型预测的真实坏人数（即会产生逾期的用户）与总的真实坏人数的占比。也就是说，在一群真实的坏人里面，模型能抓出多少真实坏人。召回率为1时，代表模型预测的坏人覆盖了所有真实的坏人，没有放过一个坏人。
精准率在该项目中的意义是：模型预测的真实坏人数与模型预测的总坏人个数的占比。也就是说，模型预测的总坏人数里有多少是真的坏人。精准率为1时，代表模型预测的坏人都是坏人，没有"错杀"一个好人。
通过率在该项目中的意义是：模型预测成好人的个数与总人数的占比。即贷款申请成功的人数占总人数的比。一样的，该值越高越好。
在现实中，召回率和精准率总是相违背的。这也很好理解。因为实际真实坏人数是固定的，如果我们希望提高召回率，那么只要提高预测成坏人的个数即可，然而提高预测成坏人的个数，意味着模型会将更多的好人预测成坏人，这样精准率就降低了。所以召回率和精准率在实际应用场景中是鱼和熊掌，很难兼得。
项目中模型最终的表现结果如图9所示：
锡银科技
Company dynamics
03 / 项目
百度助贷项目中，我们将机器学习算法应用于贷前准入规则中。旨在降低贷款不良率，同时能够让更多的客户准入。在经过业务访谈、特征筛选、特征工程、数据处理等环节后，我们采用GBDT算法建模，得到最终的模型。
锡 / 银 / 科 / 技 第11页
图九：模型表现
很明显，采用机器学习建模来判断客户是否给与准入的表现要远好于传统的专家规则。
通过本文的介绍，不管是人工智能的研究者还是普通的业务人员都可以很好的评估一个模型的表现效果。知道如何评价模型，那么如何建立好的模型呢？这就需要我们理解业务知识，掌握各种算法，不断学习，不断专研。
04 / 总结
锡银科技
Company dynamics
在现实中，召回率和精准率总是相违背的。这也很好理解。因为实际真实坏人数是固定的，如果我们希望提高召回率，那么只要提高预测成坏人的个数即可，然而提高预测成坏人的个数，意味着模型会将更多的好人预测成坏人，这样精准率就降低了。所以召回率和精准率在实际应用场景中是鱼和熊掌，很难兼得。
项目中模型最终的表现结果如图9所示：
锡 / 银 / 科 / 技 第12页
返回目录
集群环境描述：集群采用华为FusionInsight HD C70SPC200，Solr版本为6.2.0、Hbase版本为1.0.2，集群管理节点2台，数据节点3台。
基于solr的hbase二级索引性能优化
文章：刘力
01 / Hbase的rowkey设计
Hbase作为海量数据的高速存储和读取的分布式数据库解决方案，在金融、互联网等行业得到广泛的应用。Hbase是以keyValue的形式存储的分布式数据库，通过hbase的rowkey读取value的值，HBASE按单个Rowkey检索的效率是很高的，耗时在1毫秒以下，每秒钟可获取1000~2000条记录，不过非key列的查询很慢，所以hbase的rowkey设计影响到后面数据的读取性能。Rowkey设计原则为长度原则（越短越好）、散列原则、唯一原则。Hbase的查询可以通过rowkey直接查询或者通过API提供的filter、scan进行相应的条件查询，在数据量很大的情况下进行全表扫描会消耗大量性能。除了Hbase本身提供的API查询外，还有Hbase通过创建本身二级索引，也可以借助solr、Elasticsearch创建二级索引提高查询性能。当查询条件过多的情况下很难进行高效率的查询，因此本次案例介绍的历史库查询中的应用场景是采用solr创建二级索引。
返回目录
锡 / 银 / 科 / 技 第13页
预分区可以有效的防止热点问题以及因此导致的磁盘I/O问题。Hbase表的预分区是通过创建hbase表进行分区，在此处确定rowkey的取值范围和构成逻辑。 建表语句如下：
create 'tbl_tran_detail','TRAN_DETAIL',SPLITS => ['00|','10|','20|','30|','40|','50|','60|','70|','80|','90|']
在保证数据唯一性的前提下尽量缩短rowkey的长度，采用账号、交易流水和账单流水、交易日期以"|"作为分隔符进行rowkey设计。Rowkey的形式如下：
"00100100002878795|170510000049|2910000042|20190212"
如果rowkey不进行散列处理，首字段直接使用账号作，很可能数据集中到几个交易较多的regionServer当中。会使负载集中到几个regionServer中导致热点问题，影响查询效率。通过哈希函数算出账号哈希值，截取前两位作为rowkey的首字段。结果如下：
"00|00100100002878795|170510000049|2910000042|20190212"
从Zookeeper中取下managed-schema文件，命令如下
solrzkcli.sh -zkhost bigdatae:24002 -cmd getfile /solr/configs/confWithSchema/managed-schema managed-schema
在文件managed-schema中添加要创建索引的字段，如下：
图一：managed-schema配置文件
上传到zookeeper集群创建相应的solr表，并重启solr服务使配置生效。上传文件命令如下：
solrzkcli.sh -zkhost bigdatae:24002 -cmd putfile /solr/configs/confWithSchema/managed-schema managed-schema
通过java实现从hbase读取数据并创建solr索引，针对存量数据需要对全表数据进行创建索引，对于增量数据只需要通过filter过滤rowkey后面的交易日期便可以读取。以下谈一下针对存量数据创建solr索引出现的问题，存量数据约有5亿左右。
开始初始化数据全量存储在hbase一张表中，程序在读取hbase数据时通过全表扫描的形式读取。
02 /Solr索引创建
锡 / 银 / 科 / 技 第14页
图一：managed-schema配置文件
上传到zookeeper集群创建相应的solr表，并重启solr服务使配置生效。上传文件命令如下：
solrzkcli.sh -zkhost bigdatae:24002 -cmd putfile /solr/configs/confWithSchema/managed-schema managed-schema
通过java实现从hbase读取数据并创建solr索引，针对存量数据需要对全表数据进行创建索引，对于增量数据只需要通过filter过滤rowkey后面的交易日期便可以读取。以下谈一下针对存量数据创建solr索引出现的问题，存量数据约有5亿左右。
开始初始化数据全量存储在hbase一张表中，程序在读取hbase数据时通过全表扫描的形式读取。
锡银科技
Company dynamics
图二：ROC曲线
锡 / 银 / 科 / 技 第15页
这种形式solr会创建部分索引，但中途就会报错，因hbase单表数据量过大导致请求超时。从以下日志中可以看到hbase在对数据进行scan时出现ScannerTimeout-
Exception,程序一直尝试所以错误日志一直在打印。
图三：报错信息
考虑过修改缓存量改的小一些，设置客户端hbase.rpc.timeout时间为900000，也调整过hbase集群内存。最终都没有避免读取数据导致的超时情况。
返回目录
最后查到关于hbase起止键的一些方案。hbase的数据以表为分片以行为粒度，以rowkey范围进行拆分，每个分片成为一个region。一张表可分为多个region，每台服务器有多个region，因此hbase服务器为RegionServer。一行数据的分布分为2层路由：rowkey到region，region到RegionServer。一个Region相对于rowkey是一个左闭右开区间，所以我们可以通过指定startkey和stopkey快速的定位到相应的数据。Scan中添加如下代码：
scan.setStartRow(Bytes.toBytes("00|#"));
scan.setStopRow(Bytes.toBytes("10|:"));
Scan在扫描表中数据时会定位到rowkey为"00|"开头的数据，"#"和"："是为了锁定取值范围。Rowkey的排序是按照对应的ASCII码表排序的，ASCII排序中："#"< "0-9" < "："。所以在此次针对rowkey的查询可以取到以"00|"开头到"10|"开头的所有数据。随后分批次将"10|"到"99|"的数据添加到solr索引中。
后续对于每日增量的数据，是通过rowkey的交易日期进行过滤查询并创建索引。因每日增量数据相对全量数据少之又少，从全量数据中通过filter抽取当日数据对于hbase来说比较耗时，对集群本身也存在压力。通过调节hbase JVM的内存可以提高查询效率，但是对于这次效果甚微。为使增量数据在创建索引时减少对目标表的压力，在目标表之前创建子表，用于存放每日增量数据创建索引使用。创建完索引之后将子表数据导入到目标表。
锡 / 银 / 科 / 技 第16页
region到RegionServer。一个Region相对于rowkey是一个左闭右开区间，所以我们可以通过指定startkey和stopkey快速的定位到相应的数据。Scan中添加如下代码：
scan.setStartRow(Bytes.toBytes("00|#"));
scan.setStopRow(Bytes.toBytes("10|:"));
Scan在扫描表中数据时会定位到rowkey为"00|"开头的数据，"#"和"："是为了锁定取值范围。Rowkey的排序是按照对应的ASCII码表排序的，ASCII排序中："#"< "0-9" < "："。所以在此次针对rowkey的查询可以取到以"00|"开头到"10|"开头的所有数据。随后分批次将"10|"到"99|"的数据添加到solr索引中。
后续对于每日增量的数据，是通过rowkey的交易日期进行过滤查询并创建索引。因每日增量数据相对全量数据少之又少，从全量数据中通过filter抽取当日数据对于hbase来说比较耗时，对集群本身也存在压力。通过调节hbase JVM的内存可以提高查询效率，但是对于这次效果甚微。为使增量数据在创建索引时减少对目标表的压力，在目标表之前创建子表，用于存放每日增量数据创建索引使用。创建完索引之后将子表数据导入到目标表。
返回目录
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第17页
返回目录
2019 年 1 月 12 日 17：28 到 17：29，核心系统由于链路不稳定，数据写入存储超时并重传，导致数据库在写redo log时发生105秒的等待，，前置发往核心交易在这105秒时间内全部失败。Tuxedo db service超时时间为 70,导致服务在 70 秒内未完成后多个Tuxedo db service重启。
虽然过程不是很复杂，但由于技术水平有限，排查还是花了较多的时间。下面是排查的整个经过，及对部分原理的个人理解。
一根光纤引起的"不安"
文章：高晓峰
01 / 事件回顾
2019 年 1 月 12 日 17：28：06 到 17：29：51，核心系统发生故障，前置发往核心动账类交易在 105秒时间内全部失败。Tuxedo db service超时时间为 70,导致服务在 70 秒内未完成后多个Tuxedo db service重启。
查看Tuxedo日志如下：
02 / 排查经过
锡 / 银 / 科 / 技 第18页
锡 / 银 / 科 / 技 第19页
锡银科技
Company dynamics
UBB 配置如下:
Tuxedo应用重启是由于ubbconfig配置 SVCTIMEOUT=70，当服务请求超过70s时会导致服务异常重启。经核查本次Tuxedo DB服务重启涉及前置 10 笔，核心 6 笔，且仍有部分Tuxedo DB服务未重启，部分查询类交易正常进行，以往也时有发生重启现像，只是 2019-01-12 服务重启比较集中。所以初步怀疑是后端超时导致了Tuxedo DB service重启，从而影响业务。
目前Tuxedo应用到后端的架构如下图所示：
Tuxedo服务器后端连接网络、DB服务器、SAN网以及存储这4个方面。首先分析当时网络情况，分析故障发生时网络流量包，部分截图如下：
锡 / 银 / 科 / 技 第20页
2019-01-12 服务重启比较集中。所以初步怀疑是后端超时导致了Tuxedo DB service重启，从而影响业务。
目前Tuxedo应用到后端的架构如下图所示：
Tuxedo服务器后端连接网络、DB服务器、SAN网以及存储这4个方面。首先分析当时网络情况，分析故障发生时网络流量包，部分截图如下：
锡 / 银 / 科 / 技 第21页
故障发生时Tuxedo与核心DB之间的数据包，发现在17：28 到 17：29间有大量非正常的包，同时也有正常的包。筛查后发现其中有一笔交易等待105秒后，核心DB端才给核心tuxedo端回包，怀疑是后端数据库端处理慢。
数据库服务器大体包含以下几部分：
Oracle数据库在17：29：51存在一个105秒写redo日志的等待，该时间段与Tuxedo发生问题的时间段一致。数据库在写redo时，必须等前一个写redo的操作完成后才进行下一个写redo操作，如果这个写redo操作未完成，则后续所有涉及增删改的数据库操作都会等待这个写redo操作完成。
日志如下：
与此同时17：29：51时AIX操作系统层面存在Hdisk131报错，主机盘为hdisk-power35，这个设备指向了存储VMAX 10K#160 device：12B。
返回目录
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第22页
与此同时17：29：51时AIX操作系统层面存在Hdisk131报错，主机盘为hdisk-power35，这个设备指向了存储VMAX 10K#160 device：12B。
锡银科技
Company dynamics
对于hdiskpower35进行分析，存在Redo与其他应用混用盘的现象。
锡 / 银 / 科 / 技 第4页
锡 / 银 / 科 / 技 第23页
同时分析了其他disk operation error, 例如hdisk 446, hdisk 35, hdisk 101等。
Hdisk446这个设备指向了存储VMAX10K#158 device：66A
锡 / 银 / 科 / 技 第24页
Hdisk35这个设备指向了存储VMAX10K#158 device：167
Hdisk35这个设备指向了存储VMAX10K#160， device：113
经过分析，所有disk operation error的发生没有共性，分别发生在两台不同的VMAX10K存储上，唯一的共性是这些设备都是连接同一块HBA卡 FCS2。经过对主机的分析，其中FCS2的invalid CRC count为459，这个值与FCS0的值差距较大，所以怀疑是fcs2链路有问题.
光纤交换机在问题发生的时间段内无相关报错。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第25页
光纤交换机在问题发生的时间段内无相关报错。
锡银科技
Company dynamics
存储VMAX10K （CN498700158）在问题发生时北京时间17：29左右（北京时间=控制台系统时间+7小时6分），即控制台系统时间10：23分，存储上没有相关的报错信息。
存储VMAX10K（CN498700160）在问题发生时北京时间17：29左右（北京时间=控制台系统时间+7小时47分），即控制台系统时间9：42分，存储上有一天相关报错信息AB3E.00。该条报错的解释是存储外部链路存在问题， 并且指向了设备12B，与主机日志反映的hdisk131 disk operation error的报错一致。
通过上述排查定位问题是由于DB服务器FCS2链路抖动引起数据库写redo超时，从而导致Tuxedo端DB service触发70秒超时机制。链路传输超时为什么需要这么长时间的等待呢，这就需要了解下光纤通道的原理。
SAN（Storage Area Network，存储局域网络）是一种将存储设备、连接设备和接口集成在一个高速网络中的技术。SAN本身就是一个存储网络，承担了数据存储任务，SAN网络与LAN业务网络相隔离，存储数据流不会占用业务网络带宽。在SAN网络中，所有的数据传输在高速、高带宽的网络中进行，SAN存储实现的是直接对物理硬件的块级存储访问，提高了存储的性能和升级能力。
锡 / 银 / 科 / 技 第26页
通过上述排查定位问题是由于DB服务器FCS2链路抖动引起数据库写redo超时，从而导致Tuxedo端DB service触发70秒超时机制。链路传输超时为什么需要这么长时间的等待呢，这就需要了解下光纤通道的原理。
SAN（Storage Area Network，存储局域网络）是一种将存储设备、连接设备和接口集成在一个高速网络中的技术。SAN本身就是一个存储网络，承担了数据存储任务，SAN网络与LAN业务网络相隔离，存储数据流不会占用业务网络带宽。在SAN网络中，所有的数据传输在高速、高带宽的网络中进行，SAN存储实现的是直接对物理硬件的块级存储访问，提高了存储的性能和升级能力。
03 / 光纤通道原理
1.光纤通道技术
早期的SAN采用的是光纤通道（FC，Fiber Channel）技术，所以，以前的SAN多指采用光纤通道的存储局域网络，到了iSCSI协议出现以后，为了区分，业界就把SAN分为FC-SAN和IP-SAN。
FC开发于1988年，最早是用来提高硬盘协议的传输带宽，侧重于数据的快速、高效、可靠传输。到上世纪90年代末，FC SAN开始得到大规模的广泛应用。
锡 / 银 / 科 / 技 第27页
FC光纤通道拥有自己的协议层，它们是：
FC-0：连接物理介质的界面、电缆等；定义编码和解码的标准。
FC-1：传输协议层或数据链接层，编码或解码信号。
FC-2：网络层，光纤通道的核心, 定义了帧、流控制、和服务质量等。
FC-3：定义了常用服务，如数据加密和压缩。
FC-4：协议映射层，定义了光纤通道和上层应用之间的接口，上层应用比如：串行SCSI 协 议，HBA卡的驱动提供了FC-4 的接口函数。FC-4 支持多协议，如：FCP-SCSI，FC-IP，FC-VI。
光纤通道的主要部分实际上是FC-2。其中从FC-0到FC-2被称为FC-PH，也就是"物理层"。光纤通道主要通过FC-2来进行传输，因此，光纤通道也常被成为"二层协议"或者"类以太网协议"。
光纤通道的数据单元叫做帧。即使光纤通道本身就有几个层，大部分光纤通道是指第2层协议。一个光纤通道帧最大是2148字节，而且光纤通道帧的头部比起广域网的IP和TCP来说有些奇怪。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第28页
光纤通道的数据单元叫做帧。即使光纤通道本身就有几个层，大部分光纤通道是指第2层协议。一个光纤通道帧最大是2148字节，而且光纤通道帧的头部比起广域网的IP和TCP来说有些奇怪。光线通道只使用一个帧格式来在多个层上完成各种任务。帧的功能决定其格式。
光纤通道帧起始于帧开始（SOF）标志，随后是帧头部，这个一会进行描述。数据，或光纤通道内容，紧随其后，然后是帧结束（EOF）。这样封装的目的是让光纤通道可以在需要时被其他类似于TCP的协议所承载。
返回目录
锡银科技
Company dynamics
2.FC拓扑结构
FC拓扑主要有三种：
点对点（Point To Point）：允许2个设备互连，一般用于DAS存储。
光纤通道仲裁环路（Arbitrated Loop，FC-AL）：采用FC-AL仲裁环机制，使用Token（令牌）的方式进行仲裁。光纤环路端口，或交换机上的FL端口，和HBA上的 NL端口（节点环）连接，支持环路运行。采用FC-AL架构，当一个设备加入FC-AL的时候，或出现任何错误或需要重新设置的时候，环路就必须重新初始 化。在这个过程中，所有的通信都必须暂时中止。由于其寻址机制，FC-AL理论上被限制在了127个节点。
交换式光纤通道（Switched Fabric，FC-SW）：在交换式SAN上运行的方式。FC-SW可以按照任意方式进行连接，规避了仲裁环的诸多弊端，但需要购买支持交换架构的交换模块或FC交换机。--目前我行采用的拓扑。
锡 / 银 / 科 / 技 第29页
NL端口（节点环）连接，支持环路运行。采用FC-AL架构，当一个设备加入FC-AL的时候，或出现任何错误或需要重新设置的时候，环路就必须重新初始 化。在这个过程中，所有的通信都必须暂时中止。由于其寻址机制，FC-AL理论上被限制在了127个节点。
交换式光纤通道（Switched Fabric，FC-SW）：在交换式SAN上运行的方式。FC-SW可以按照任意方式进行连接，规避了仲裁环的诸多弊端，但需要购买支持交换架构的交换模块或FC交换机。--目前我行采用的拓扑。
3.光纤通道的寻址方式
光纤通道（FC:Fibre Channel）是通过 World Wide Name ( WWN)来标识一个唯一的设备。WWN是一个 64 位的地址。WWN 对于光纤通道设备就像Ethernet 的MAC 地址一样都是全球唯一的，它们是由电器和电子工程协会(IEEE)标准委员会指定给制造商，在制造时被直接内置到设备中去的。
通常用 Node WWN 来标示每台不同的FC交换机，它是唯一的;对于FC交换机的端口，则使用PortWWPN 来标示交换机的端口。所以一个交换机只有一个 Node WWN 和多个 Port WWPN。 根据IEEE标准定义，WWN的定义方式有三种：IEEE Standard (NAA=1)、IEEE Extended (NAA=2)、IEEE Registered Name (NAA=5)。
锡 / 银 / 科 / 技 第30页
通常用 Node WWN 来标示每台不同的FC交换机，它是唯一的;对于FC交换机的端口，则使用PortWWPN 来标示交换机的端口。所以一个交换机只有一个 Node WWN 和多个 Port WWPN。 根据IEEE标准定义，WWN的定义方式有三种：IEEE Standard (NAA=1)、IEEE Extended (NAA=2)、IEEE Registered Name (NAA=5)。
返回目录
4.FC流量控制
信用是指接收端口分配给发送端口的缓冲区的数量，在FC网络中采用流量控制机制是建立在信用系统上的基础上。在上面介绍的FC各层协议中，FC-2层来实现FC网络的通信流量控制，用来协调N端口之间、N端口与交换网络，以及交换网络内部端口之前的帧流量，防止接收方的缓冲区信用不足。在流量控制中使用的信用机制有2种：端到端信用（EE_Credit）以及缓冲到缓冲的信用（BB_Credit）。两种信用机制对应的信用计数方法为：端到端信用计数（EE_Credit_CNT）以及缓冲到缓冲的信用计数（BB_Credit_CNT）。通讯发起方通过递增或者递减两种方式来管理信用计数，从而获取接收方的缓冲区状态，实现FC的流量控制。
锡 / 银 / 科 / 技 第31页
锡银科技
Company dynamics
者递减两种方式来管理信用计数，从而获取接收方的缓冲区状态，实现FC的流量控制。
5.FC超时机制
Fibre Channel使用的是静态的超时重发机制，即达到固定时长才会去重发，不会根据网络的情况动态地加以改变。而TCP／IP协议中，TCP使用自适应重传算法以适应互连网络时延的变化，TCP监视每一条连接的性能，并计算出报文的往返时间RTT(Round Trip Time)，当连接的性能变化时，TCP随即修改RTT(也就是说它能自动适应时延的变化)，RTT(Round Trip Time)被发送方用来决定是否重传报文。因此相对于TCP／IP，FC的发送方可能过早或过迟地出现超时，这对改善网络的综合性能不利。。
锡 / 银 / 科 / 技 第32页
04 / 问题总结
核心DB服务器在17：28：06秒数据库写redo日志操作（即对hdisk131进行写操作）时，fcs2链路不稳定，Fibre Channel触发静态的超时重发机制，最大重传时间为重传次数（5次）*读写超时时间（40s），即200秒，系统配置如下图。
fcs2链路不稳定于105秒后即17:29:51恢复，期间所有动账业务全部超时，部分Tuxedo DB service到达70秒超时后重启。
返回目录
锡 / 银 / 科 / 技 第33页
返回目录
Linux是我们目前生产应用主要运行的操作系统，我们过去关注系统的状态、通断，可是随着业务量的逐渐增大，仅仅检查状态、通断等已经不能让我们的应用系统稳定的运行了，我们需要去关注性能，但是操作系统的性能又包含哪些部分，我们怎么在业务反应"慢"的时候在很短的时间内检查出"慢"之所在，是我们一直想要解决的问题。当然我今天只是抛砖引玉，希望找出一套标准化的操作在最短的时间内找到问题所在。
一般查找"慢"的原因，我们可以查看系统负载、tcp丢包情况、网卡吞吐量、网络连接数、磁盘读写延迟、cpu内存占用率这些方面。而这些方面在linux中是有现成的命令可以查看的，例如uptime、dmesg|tail、vmstat 、pidstat、sar -n DEV、top等。本期我们会重点介绍top命令，因为top命令能够查看到的信息最全并且都是实时的数据，其他的在后期进行介绍。
首先我们来看下top命令的输出，如下图：
Linux性能问题排查之TOP命令详解
文章：王旭
返回目录
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第34页
令，因为top命令能够查看到的信息最全并且都是实时的数据，其他的在后期进行介绍。
首先我们来看下top命令的输出，如下图：
锡银科技
Company dynamics
>系统运行时间和平均负载：
top命令的顶部显示与uptime命令相似的输出，这些字段显示：当前时间，系统已运行的时间，当前登录用户的数量，相应最近5、10和15分钟内的平均负载。
可以使用'l'命令切换uptime的显示。
21:45:11 - 当前系统时间
0 days, 4:54 - 系统已经运行了4小时54分钟（在这期间没有重启过）
3users - 当前有3个用户登录系统
load average:0.24, 0.15, 0.19 - load average后面的三个数分别是5分钟、10分钟、15分钟的负载情况。load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
返回目录
锡 / 银 / 科 / 技 第35页
21:45:11 - 当前系统时间
0 days, 4:54 - 系统已经运行了4小时54分钟（在这期间没有重启过）
3users - 当前有3个用户登录系统
load average:0.24, 0.15, 0.19 - load average后面的三个数分别是5分钟、10分钟、15分钟的负载情况。load average数据是每隔5秒钟检查一次活跃的进程数，然后按特定算法计算出的数值。如果这个数除以逻辑CPU的数量，结果高于5的时候就表明系统在超负荷运转了。
>任务：
Tasks - 任务（进程），系统现在共有144个进程，其中处于运行中的有1个，143个在休眠（sleep），stoped状态的有0个，zombie状态（僵尸）的有0个。第二行显示的是任务或者进程的总结。进程可以处于不同的状态。这里显示了全部进程的数量。除此之外，还有正在运行、睡眠、停止、僵尸进程的数量（僵尸是一种进程的状态）。这些进程概括信息可以用't'切换显示.
大家不要认为144个进程很多，其实linux在完成基本安装以后，裸系统的进程数是很多的，例如suse11.4是140个所有，centos7是232个左右，redhat是156个左右，这个大家可以自行安装进行比较查看。
锡 / 银 / 科 / 技 第36页
这里显示不同模式下所占cpu时间百分比，这些不同的cpu时间表示：
- " us, user： 运行(未调整优先级的) 用户进程的CPU时间
- " sy，system: 运行内核进程的CPU时间
- " ni，niced：运行已调整优先级的用户进程的CPU时间
- " wa，IO wait: 用于等待IO完成的CPU时间
- " hi：处理硬件中断的CPU时间
si: 处理软件中断的CPU时间
st：这个虚拟机被hypervisor偷去的CPU时间
可以使用't'命令切换显示。
1.3% us - 用户空间占用CPU的百分比。
1.0% sy - 内核空间占用CPU的百分比。
0.0% ni - 改变过优先级的进程占用CPU的百分比
97.3% id - 空闲CPU百分比
0.0% wa - IO等待占用CPU的百分比
0.3% hi - 硬中断（Hardware IRQ）占用CPU的百分比
0.0% si - 软中断（Software Interrupts）占用CPU的百分比
当然这里的cpu百分比是按照系统内总的cpu总的cpu来计算的，但是我们在平时的工作中往往cpu的平均占用百分比是不高的，但是我们会发现我们单一的进程占用的cpu会显示100%，这就是我们的应用程序没有启用多线程，譬如我们系统分配了16C，但是我们只用了其中的1C，所以往往是这1个C的利用率会很高，而其他C就一直是空闲，此时业务也会表现出"慢"的症状。在这种情况下我们查看总的cpu占用率就没有意义了，这时我们需要在top的情况下按大键盘的"1"，查看具体单个cpu核的占用率，见下图：
>CPU状态：
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第37页
当然这里的cpu百分比是按照系统内总的cpu总的cpu来计算的，但是我们在平时的工作中往往cpu的平均占用百分比是不高的，但是我们会发现我们单一的进程占用的cpu会显示100%，这就是我们的应用程序没有启用多线程，譬如我们系统分配了16C，但是我们只用了其中的1C，所以往往是这1个C的利用率会很高，而其他C就一直是空闲，此时业务也会表现出"慢"的症状。在这种情况下我们查看总的cpu占用率就没有意义了，这时我们需要在top的情况下按大键盘的"1"，查看具体单个cpu核的占用率，见下图：
锡银科技
Company dynamics
>内存使用：
这里就会出现总的cpu核数和每个核的利用率。或者我们可以使用mpstat -P ALL进行多核cpu的查看。
接下来两行显示内存使用率，有点像'free'命令。第一行是物理内存使用，第二行是虚拟内存使用(交换空间)。
物理内存显示如下:全部可用内存、已使用内存、空闲内存、缓冲内存。相似地：交换部分显示的是：全部、已使用、空闲和缓冲交换空间。
内存显示可以用'm'命令切换。
509248k total - 物理内存总量（509M）
495964k used - 使用中的内存总量（495M）
13284k free - 空闲内存总量（13M）
25364k buffers - 缓存的内存量 （25M）
swap交换分区
492536k total - 交换区总量（492M）
11856k used - 使用的交换区总量（11M）
480680k free - 空闲交换区总量（480M）
202224k cached - 缓冲的交换区总量（202M）
这里要说明的是不能用windows的内存概念理解这些数据，如果按windows的方式此台服务器"危矣"：8G的内存总量只剩下530M的可用内存。Linux的内存管理有其特殊性，复杂点需要一本书来说明，这里只是简单说点和我们传统概念（windows）的不同。
第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。
锡 / 银 / 科 / 技 第38页
物理内存显示如下:全部可用内存、已使用内存、空闲内存、缓冲内存。相似地：交换部分显示的是：全部、已使用、空闲和缓冲交换空间。
内存显示可以用'm'命令切换。
509248k total - 物理内存总量（509M）
495964k used - 使用中的内存总量（495M）
13284k free - 空闲内存总量（13M）
25364k buffers - 缓存的内存量 （25M）
swap交换分区
492536k total - 交换区总量（492M）
11856k used - 使用的交换区总量（11M）
480680k free - 空闲交换区总量（480M）
202224k cached - 缓冲的交换区总量（202M）
这里要说明的是不能用windows的内存概念理解这些数据，如果按windows的方式此台服务器"危矣"：8G的内存总量只剩下530M的可用内存。Linux的内存管理有其特殊性，复杂点需要一本书来说明，这里只是简单说点和我们传统概念（windows）的不同。
第四行中使用中的内存总量（used）指的是现在系统内核控制的内存数，空闲内存总量（free）是内核还未纳入其管控范围的数量。纳入内核管理的内存不见得都在使用中，还包括过去使用过的现在可以被重复利用的内存，内核并不把这些可被重新使用的内存交还到free中去，因此在linux上free内存会越来越少，但不用为此担心。
锡 / 银 / 科 / 技 第39页
锡银科技
Company dynamics
如果出于习惯去计算可用内存数，这里有个近似的计算公式：第四行的free + 第四行的buffers + 第五行的cached，按这个公式此台服务器的可用内存：
13284+25364+202224 = 240M。
对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。
>各进程（任务）的状态监控：
PID：进程ID，进程的唯一标识符
USER：进程所有者的实际用户名。
PR：进程的调度优先级。这个字段的一些值是'rt'。这意味这些进程运行在实时态。
NI：进程的nice值（优先级）。越小的值意味着越高的优先级。负值表示高优先级，正值表示低优先级
VIRT：进程使用的虚拟内存。进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES：驻留内存大小。驻留内存是任务使用的非交换物理内存大小。进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR：SHR是进程使用的共享内存。共享内存大小，单位kb
S：这个是进程的状态。它有以下不同的值:
D - 不可中断的睡眠态。
R - 运行态
S - 睡眠态
T - 被跟踪或已停止
Z - 僵尸态
%CPU：自从上一次更新时到现在任务所使用的CPU时间百分比。
%MEM：进程使用的可用物理内存百分比。
TIME+：任务启动后到现在所使用的全部CPU时间，精确到百分之一秒。
COMMAND：运行进程所使用的命令。进程名称（命令名/命令行）
还有许多在默认情况下不会显示的输出，它们可以显示进程的页错误、有效组和组ID和其他更多的信息。
锡 / 银 / 科 / 技 第40页
锡银科技
Company dynamics
PR：进程的调度优先级。这个字段的一些值是'rt'。这意味这些进程运行在实时态。
NI：进程的nice值（优先级）。越小的值意味着越高的优先级。负值表示高优先级，正值表示低优先级
VIRT：进程使用的虚拟内存。进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES：驻留内存大小。驻留内存是任务使用的非交换物理内存大小。进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR：SHR是进程使用的共享内存。共享内存大小，单位kb
S：这个是进程的状态。它有以下不同的值:
D - 不可中断的睡眠态。
R - 运行态
S - 睡眠态
T - 被跟踪或已停止
Z - 僵尸态
%CPU：自从上一次更新时到现在任务所使用的CPU时间百分比。
%MEM：进程使用的可用物理内存百分比。
TIME+：任务启动后到现在所使用的全部CPU时间，精确到百分之一秒。
COMMAND：运行进程所使用的命令。进程名称（命令名/命令行）
还有许多在默认情况下不会显示的输出，它们可以显示进程的页错误、有效组和组ID和其他更多的信息。
锡 / 银 / 科 / 技 第41页
>交互命令：
1- 开启或关闭显示所有cpu使用详细情况：
l - 关闭或开启第一部分第一行 top 信息的表示 t - 关闭或开启第一部分第二行 Tasks 和第三行 Cpus 信息的表示 m - 关闭或开启第一部分第四行 Mem 和 第五行 Swap 信息的表示 N - 以 PID 的大小的顺序排列表示进程列表（第三部分后述） P - 以 CPU 占用率大小的顺序排列进程列表 （第三部分后述） M - 以内存占用率大小的顺序排列进程列表 （第三部分后述） h - 显示帮助 n - 设置在进程列表所显示进程的数量 f- 显示更多选项 q - 退出 top s - 改变画面更新频率（输入数字）
这里我们注重讲一下f这个交互命令，如下图是在top中按下"f"的输出：
锡 / 银 / 科 / 技 第42页
里带星号的是目前显示的内容，不带星号的是可选显示的项目。这里可以选择显示父进程，进程所属用户的uid，显示终端等内容，可根据需要自行显示，这个隐藏内容在每次输入top都需要自行选择的，不会长驻在显示界面
至此，top命令就介绍完了，我们排查性能问题时，第一个想到的命令就应该是top，希望通过我的介绍能对大家排查问题时有所帮助，也请期待后期的"Linux性能问题排查之iostat命令详解"。
返回目录
锡 / 银 / 科 / 技 第43页
返回目录
随着技术的发展，日益增长的客户量以及交易量，对于软件程序的性能要求越来越高，在程序开发测试中，不论是前端还是后端，不论是单节点还是分布式，都会涉及到性能优化。性能测试是在性能指标不满足预估业务指标的情况下对其进行调优，例如TPS过低，达不到业务预估的值，或者交易响应时间过长影响用户体验等。另一方面是针对已有的系统，之前并未进行性能测试，但是生产上出现性能瓶颈的，需要进行压测并调优。最终提高程序质量，为上线后系统能够在满足业务需求的情况下可以长期稳定持续的运行提供参考。
18年发生的核心系统异常，就是因为GXP和核心通讯堵塞导致外围系统调用核心所有接口相应缓慢。针对核心系统，科技部各方面重视本次生产异常，技术测试岗配合开发和运维的同事共同对事故进行分析，发现在系统参数配置等方面都有待优化。本文就针对核心系统的MBT006中间业务记账交易性能测试进行性能问题的诊断分析和优化。在性能测试执行的过程中，当并发用户数达到70时出现交易失败的情况，见图1-1：
图1-1 核心70用户并发报错
性能调优怎么调-核心系统优化
文章：质量中心-张波
返回目录
锡 / 银 / 科 / 技 第44页
图1-1 核心70用户并发报错
图1-2 核心70并发报错信息
锡 / 银 / 科 / 技 第45页
返回目录
锡银科技
Company dynamics
错误信息大部分为：lrt_tpcall - internal system error，tpcall调用处理失败！
在核心50并发用户数时，TPS达到最大，平均TPS为15.345，不满足核心性能指标45.8的要求。因此对核心系统进行以下三个优化处理：
优化并发用户数达到70报错tpcall调用处理失败。该报错信息是由于最大连接数限制，导致在并发用户数超过60后无法正常建立连接，交易失败。找到/tuxedo/qztux/bin/ ubbltts配置文件，查看配置信息。发现MAXWSCLIENTS=60，修改为200后，重新加载配置tmloadcf -y ubbltts，重启服务后验证最大并发用户数支持200。
图1-3 核心200并发报错
01 / 并发用户数太小不够用？
锡 / 银 / 科 / 技 第46页
图1-4 核心200并发报错信息
当并发用户数超过200时，交易出现lrt_tpcall TPESYSTEM - internal system error，tpcall调用处理失败！的错误信息。由于压力机在200并发压测时，已经达到发压机的性能瓶颈，因此最大并发用户数优化至200。
返回目录
锡 / 银 / 科 / 技 第47页
使用重复数据导致锁等待时间过长问题，见图1-5。
图1-5 数据库等待事件
02 / 数据库行锁怎么这么多？
由于之前压测脚本中未对brchno字段进行参数化，导致使用相同的机构，产生大量的行锁，对交易报文中的brchno，userid，acctno，toacct等字段进行参数化之后解决。因此建议在压测时提供尽量多的可用数据，以避免产生此类问题影响测试结果。
优化TPS不满足性能指标要求。在测试的过程中，抓取数据库Oracle快照，发现并无过慢的SQL，因此尝试增加进程数来提升性能处理能力。查看/tuxedo/qztux/bin/ ubbltts配置信息。
ltts SRVGRP=GROUP1 SRVID=5 MIN=1 MAX=2 GRACE=120 CLOPT="-A -r"
db SRVGRP=GROUP1 SRVID=50 MIN=6 MAX=10 RESTART=Y MAXGEN=2GRACE=120CLOPT="-A -r"
espay SRVGRP=GROUP1 SRVID=100 MIN=3 MAX=6 GRACE=120
WSL SRVGRP=WSGRP SRVID=1000 RESTART=Y MAXGEN=2 GRACE=120 CLOPT="-A -r -t -- -n //166.8.63.210:7000 -m 3 -M 5 -x 10 -c128"
优化前TPS与ART见图1-6：
03 / 处理能力太低无法达到预计的业务指标？
锡 / 银 / 科 / 技 第48页
返回目录
锡银科技
Company dynamics
图1-6优化前TPS与ART
ubbltts配置信息。
ltts SRVGRP=GROUP1 SRVID=5 MIN=1 MAX=2 GRACE=120 CLOPT="-A -r"
db SRVGRP=GROUP1 SRVID=50 MIN=6 MAX=10 RESTART=Y MAXGEN=2GRACE=120CLOPT="-A -r"
espay SRVGRP=GROUP1 SRVID=100 MIN=3 MAX=6 GRACE=120
WSL SRVGRP=WSGRP SRVID=1000 RESTART=Y MAXGEN=2 GRACE=120 CLOPT="-A -r -t -- -n //166.8.63.210:7000 -m 3 -M 5 -x 10 -c128"
优化前TPS与ART见图1-6：
锡 / 银 / 科 / 技 第49页
修改参数为：ltts SRVGRP=GROUP1 SRVID=5 MIN=1 MAX=2 RESTART=Y MAXGEN=5 GRACE=120 CLOPT="-A -r"
db SRVGRP=GROUP1 SRVID=50 MIN=20 MAX=50 RESTART=Y MAXGEN=5 GRACE=120 CLOPT="-A -r"
espay SRVGRP=GROUP1 SRVID=100 MIN=10 MAX=10 RESTART=Y MAXGEN=5 GRACE=120 CLOPT="-A -r"
WSL SRVGRP=WSGRP SRVID=1000 RESTART=Y MAXGEN=5 GRACE=120 CLOPT="-A -r -t -- -n //166.8.63.210:7000 -m 10 -M10 -x 20 -c128"
验证优化后的TPS与ART：
图1-7优化后TPS与ART
在核心50并发用户数时，TPS从15.345提升至49.174,ART从3.341提升至2.042。系统性能得到进一步优化。
性能优化涉及的知识面比较广泛，硬件配置，系统参数，中间件参数配置，程序设计，数据库调优等各个方面。根据对目前测试过的近30套系统来看，系统优化优先级顺序为：参数配置优化（系统参数、中间件参数、线程池大小、连接数等）'程序优化（代码、算法、SQL、数据结构优化等）'硬件配置升级（升级服务器配置、添加节点等），从修改比较容易、成本较低的先开始优化，本文仅针对核心tuxedo进行参数优化。
锡 / 银 / 科 / 技 第50页
性能优化涉及的知识面比较广泛，硬件配置，系统参数，中间件参数配置，程序设计，数据库调优等各个方面。根据对目前测试过的近30套系统来看，系统优化优先级顺序为：参数配置优化（系统参数、中间件参数、线程池大小、连接数等）'程序优化（代码、算法、SQL、数据结构优化等）'硬件配置升级（升级服务器配置、添加节点等），从修改比较容易、成本较低的先开始优化，本文仅针对核心tuxedo进行参数优化。
如果是全链路交易压测，可以通过耗时长的一笔交易的全局流水号等唯一标识号通过日志查询各个系统的处理时间，从耗时最大的系统开始调优工作。
性能调优是一个持久的工作，在系统涉及到新增交易、业务变更、优化改造时更需要关注性能问题，已上线的系统也要持续的去发现并解决性能瓶颈，而不是等出了问题再去解决。
04 / 总结
附录：
关于ubbltts配置文件的一些参数含义：
文件路径：
/tuxedo/qztux/bin/ ubbltts
参数介绍：
1) IPCKEY
2) 说明：系统IPC资源唯一标识，一串数字，确保在一台机器上唯一，其范围为32769~262142。
3) DOMAINID
4) 说明：是该tuxedo应用的唯一标识。
5) MASTER
6) 说明：指定tuxedo应用系统的MASTER服务器，在该服务器上对整个tuxedo系统进行管理配置，多机模式下可以在MASTER服务器上管理整个tuxedo应用。
7) MAXACCESSERS
8) 说明：设定在本系统的一个节点上，可以同时最多有多少个进程访问该tuxedo系统的公告板，包括本地客户端进程、server进程、service进程、但不包括管理进程，如BBL、DBBL等。
9) MAXSERVERS
10) 说明：设定在本系统中，总共可以有多少个server存在，包括进行管理的server，如BBL、DBBL等。
11) MAXSERVICES
12) 说明：设定在本系统中，最多可以有多少个service存在，包括进行管理的server，如BBL、DBBL等，一般与MAXSERVERS一致。
13) MAXWSCLIENTS
14) 说明：配置最大客户端连接数，其值不能大于MAXACCESSERS，并且MAXACCESSERS- MAXWSCLIENTS值决定SERVER进程可以启动的最大值。例如MAXACCESSERS=100，MAXWSCLIENTS=90，那么我们进程最大可以启动10个。
15) WSL进程 -m -M -x 参数
16) 说明：-m -M分别指定WSH进程最少、最大启动个数，-x表示一个WSH进程最大可以接受多少个交易请求。MAXWSCLIENTS=M*x。
锡 / 银 / 科 / 技 第51页
锡银科技
Company dynamics
3) DOMAINID
4) 说明：是该tuxedo应用的唯一标识。
5) MASTER
6) 说明：指定tuxedo应用系统的MASTER服务器，在该服务器上对整个tuxedo系统进行管理配置，多机模式下可以在MASTER服务器上管理整个tuxedo应用。
7) MAXACCESSERS
8) 说明：设定在本系统的一个节点上，可以同时最多有多少个进程访问该tuxedo系统的公告板，包括本地客户端进程、server进程、service进程、但不包括管理进程，如BBL、DBBL等。
9) MAXSERVERS
10) 说明：设定在本系统中，总共可以有多少个server存在，包括进行管理的server，如BBL、DBBL等。
11) MAXSERVICES
12) 说明：设定在本系统中，最多可以有多少个service存在，包括进行管理的server，如BBL、DBBL等，一般与MAXSERVERS一致。
13) MAXWSCLIENTS
14) 说明：配置最大客户端连接数，其值不能大于MAXACCESSERS，并且MAXACCESSERS- MAXWSCLIENTS值决定SERVER进程可以启动的最大值。例如MAXACCESSERS=100，MAXWSCLIENTS=90，那么我们进程最大可以启动10个。
15) WSL进程 -m -M -x 参数
16) 说明：-m -M分别指定WSH进程最少、最大启动个数，-x表示一个WSH进程最大可以接受多少个交易请求。MAXWSCLIENTS=M*x。
锡 / 银 / 科 / 技 第52页
返回目录
引言：新形势下的银行电子化信息系统主要面向互联网，受众群体为广大互联网用户。手机、自助机具以及互联网技术的快速迭代，我们安全防护的重心也随之转移。从这些年银行信息化建设进程中发生的安全事件可以看出，攻击者开始转变攻击思路，不再以拿下相应的银行计算机权限或者数据为主要目标，而是通过业务逻辑和应用漏洞快速获取经济利益。本文将针对银行金融技术和金融业务方向对典型的风险进行分析及案例分享，最后提出相关的安全防护建议。
探索新形势下的银行业务逻辑攻防价值
文章：安全中心-潘林波
01 / 概述
1.1 行业概述
随着电子商务的飞速发展，银行也面临着改革的机遇及挑战。线下网点、电话服务、ATM转取等传统渠道改由网上银行、手机银行、微信银行、直销银行、各种自助设备终端等创新技术设施引导未来银行业务发展方向；在发展的同时，银行金融系统网络安全风险也成为了监管机构、广大人民群众以及银行自身的关注焦点。
锡 / 银 / 科 / 技 第53页
金融行业安全改造升级过程先后经历了基础安全、应用安全、业务逻辑安全。随着基础安全防御体系标准化，应用安全技术也趋于成熟，低成本、弱感知、高杀伤的业务逻辑漏洞逐渐成为黑灰产的摇钱工具，加强业务逻辑安全层面的安全防御能力，提升安全人员的业务逻辑安全理解能力，能够有效遏制黑灰产的有效发展，是现阶段保障自身名誉财产和维护用户权益的迫切任务，对金融行业具有十分重大的意义。
1.2 行业分析
根据第三方某厂商2018-2019最新金融行业安全大数据漏洞统计可以发现，因为基础类安全漏洞基本标准化，主要由单位内部和标准化集成公司运维，基础安全类漏洞基本没有；应用安全类漏洞包含XSS、敏感信息泄漏、SQL注入、CSRF、文件上传下载，占比约为48%；业务逻辑漏洞包含逻辑缺陷、权限越权，占比约为39%。银行自身安全运维漏洞包含运维不当、弱口令，占比约为12%。
锡 / 银 / 科 / 技 第54页
锡银科技
Company dynamics
不同行业、相同行业又或者是相同功能的业务系统都是不同的业务逻辑场景，这些场景由不同的开发人员、运维人员根据单位及用户所面临的需求进行开发运行，针对金融行业的业务逻辑安全大致可以分为账户安全、支付安全、业务流程安全。下述示例将介绍在金融行业业务逻辑安全的几种典型的案例。
SQL注入、CSRF、文件上传下载，占比约为48%；业务逻辑漏洞包含逻辑缺陷、权限越权，占比约为39%。银行自身安全运维漏洞包含运维不当、弱口令，占比约为12%。
02 / 金融业务逻辑安全
锡 / 银 / 科 / 技 第55页
2.1 账户安全-越权事件
漏洞危害：如果该类漏洞被攻击者利用，将导致指定借记卡账户交易提醒开启或者关闭，给用户带来不必要的麻烦，严重影响用户体验。
漏洞详情：参数open为1代表开启交易提醒，为0代表关闭，修改card参数为他人卡号可越权修改他人此项设置，如下图成功开启卡号6XXXXXXXXX580923的交易提醒（原来是关闭的）
漏洞危害：如果该类漏洞被攻击者利用，将导致指定借记卡账户交易提醒开启或者关闭，给用户带来不必要的麻烦，严重影响用户体验。
漏洞详情：参数open为1代表开启交易提醒，为0代表关闭，修改card参数为他人卡号可越权修改他人此项设置，如下图成功开启卡号6XXXXXXXXX580923的交易提醒（原来是关闭的）
案例1: 越权修改指定借记卡交易提醒开关
锡 / 银 / 科 / 技 第56页
漏洞危害：如果该类漏洞被攻击者利用，攻击者可更改指定用户账号密码，严重影响用户账号安全。
漏洞详情：修改密码时未验证手机号验证码，通过修改userAlias，以及获得的手机号pci_con1tele参数，可直接发包修改用户密码。
案例2: 任意用户密码重置
锡 / 银 / 科 / 技 第57页
锡银科技
Company dynamics
越权安全防护建议：
设计开发
1）对涉及权限的操作建立角色、用户的对应安全访问控制设计体系；
2）对不同角色和不同用户只能对相应权限的功能数据模块进行操作；
3）对于利用用户身份标识、订单标识用户角色特征操作应当从Session、数据库判断鉴别相应的权限后进行资源调用；
4）采用复杂的加密算法进行加密传输、存储，或使用消息鉴别码对http报文体进行完整性校验，防止攻击者使用工具中间人篡改攻击；
5）结合系统本身对前端以及外部提取数据库的敏感内容进行脱敏处理；
安全测试
1）内部测试，在功能测试、集成测试过程中可由内部安全人员通过不同角色、用户之间的增删改查等操作进行权限交叉测试；
2）安全服务，安全服务机构对权限控制层面进行安全检测。
上线运维
1） 工具设备，安全部门人员和风控部门人员通过结合风控系统等安全设备设施辅助安全策略进行半自动化乃至全自动化监控；
漏洞危害：如果该类漏洞被攻击者利用，攻击者可利用获取的大量个人信用卡申请信息进行电信诈骗黑产活动。
漏洞详情：APP信用卡申请查询接口通过修改信用卡编号值批量遍历信用卡申请信息。
案例3: 信用卡查询越权可批量遍历用户信息
锡 / 银 / 科 / 技 第58页
锡银科技
Company dynamics
3）对于利用用户身份标识、订单标识用户角色特征操作从Session、数据库判断鉴别相应的权限后进行资源调用；
4）采用复杂的加密算法进行加密传输、存储，或使用消息鉴别码对http报文体进行完整性校验，防止攻击者使用工具中间人篡改攻击；
5）结合系统本身对前端以及外部提取数据库的敏感内容进行脱敏处理；
安全测试
1）内部测试，在功能测试、集成测试过程中可由内部安全人员通过不同角色、用户之间的增删改查等操作进行权限交叉测试；
2）安全服务，安全服务机构对权限控制层面进行安全检测。
上线运维
1） 工具设备，安全部门人员和风控部门人员通过结合风控系统等安全设备设施辅助安全策略进行半自动化乃至全自动化监控；
锡 / 银 / 科 / 技 第59页
2.2 支付安全-支付事件
漏洞危害：如果该类漏洞被攻击者利用，会导致数据库锁限制功能设置被绕过，从而导致该竞猜100%中奖，造成经济损失。
漏洞详情： 由于数据库没有使用锁的机制，所以在并发条件下查询出的可竞猜次数可能相同，从而可以导致最终能够参与竞猜的次数大于实际拥有的次数。
漏洞危害：如果该类漏洞被攻击者利用，会导致数据库锁限制功能设置被绕过，从而导致该竞猜100%中奖，造成经济损失。
漏洞详情： 由于数据库没有使用锁的机制，所以在并发条件下查询出的可竞猜次数可能相同，从而可以导致最终能够参与竞猜的次数大于实际拥有的次数。
案例4: 交易漏洞导致绕过控制手段，可消费任意用户资金
锡 / 银 / 科 / 技 第60页
支付事件安全防护建议：
设计开发1）传输及加密，敏感参数不要明文放在URL中，如果一定需要则对敏感参数进行加密；
2）客户端校验，服务端效验客户端提交的参数，订单金额和充值接口返回的数据进行校验，支付时应从服务器读取数据，而不是直接读客户端的值；
3）数据签名，对用户金额和订单签名，支付过程中加一个服务器生成的key，用于校验参数有没有被篡改；
4）数据对接安全，如业务涉及数据库操作，应添加事务锁防止，在程序代码层应对相关操作添加线程锁、进程锁，防止同一资源、请求的高频请求都处理成功；
6）金融行业标准，根据金融行业支付安全标准体系设计。
安全测试
1） 内部测试，通过对涉及支付层面的功能尝试支付相关的参数修改以及建立多个测试账号对支付的用户相关参数进行修改操作；
2） 安全服务，安全服务机构对支付安全层面进行安全检测。
上线运维
1） 工具设备，安全部门人员和系统风控部门人员通过结合风控系统等安全设备设施辅助安全策略进行半自动化乃至全自动化监控；
2） 人工审核，支付审核部门/清算部门人员通过审核操作及清算资金发现异常的业务行为及时报送科技开发和安全部门。
锡 / 银 / 科 / 技 第61页
漏洞危害：如果该类漏洞被攻击者利用，攻击者可通过该漏洞消耗大量短信造成经济损失，当短信消耗有限额还可能导致业务功能失效，影响业务系统的正常运营。
漏洞详情：在注册页面，填写信息后点击获取验证码，抓包进行重放攻击，测试了15+条短信。
至全自动化监控；
2） 人工审核，支付审核部门/清算部门人员通过审核操作及清算资金发现异常的业务行为及时报送科技开发和安全部门。
2.2 支付安全-支付事件
漏洞危害：如果该类漏洞被攻击者利用，会导致数据库锁限制功能设置被绕过，从而导致该竞猜100%中奖，造成经济损失。
漏洞详情： 由于数据库没有使用锁的机制，所以在并发条件下查询出的可竞猜次数可能相同，从而可以导致最终能够参与竞猜的次数大于实际拥有的次数。
锡银科技
Company dynamics
案例5: 短信劫持轰炸
锡 / 银 / 科 / 技 第62页
漏洞危害：如果该类漏洞被攻击者利用，攻击者可通过该漏洞消耗大量短信造成经济损失，当短信消耗有限额还可能导致业务功能失效，影响业务系统的正常运营。
漏洞详情：注册成功时会发送短信通知，此处可进行重放攻击浪费服务器资源，数据包如下：
锡银科技
Company dynamics
案例6: APP注册短信劫持轰炸
锡 / 银 / 科 / 技 第63页
短信劫持安全防护建议：
设计开发
1） 安全设计，在服务端从账户、IP等个人特征明显字段限制其验证码发送周期、次数并设置时效；通过手机号和验证码在服务器进行唯一性绑定验证，每次验证后验证码失效；
2） 安全功能，结合图形验证码及其它人机鉴别手段防止短信接口被软件工具恶意利用。
安全测试
1） 安全功能测试，对单个及多个账户登陆前后调用接口周期、次数、时效进行检测，判断验证码失效策略以及黑名单策略；对图形验证码尝试识别绕过；
2） 安全服务，安全服务机构对短信劫持层面进行安全检测。
上线运维
1） 工具设备，结合风控系统对个人短信发送特征进行分析；通过收集的手机号黑名单库提前监控发现恶意手机号的攻击行为；
在面对业务逻辑漏洞形式严峻的同时，金融行业在XSS漏洞、敏感信息泄漏、SQL注入漏洞、文件上传下载漏洞这些应用漏洞也最为突出，下述示例将介绍在金融行业应用安全的几种典型的案例：
03 / 金融应用安全
锡 / 银 / 科 / 技 第64页
XSS漏洞、敏感信息泄漏、SQL注入漏洞、文件上传下载漏洞这些应用漏洞也最为突出，下述示例将介绍在金融行业应用安全的几种典型的案例：
3.1 XSS漏洞
漏洞危害： 如果该类漏洞被攻击者利用，攻击者可利用此漏洞获取后台管理员cookie从而登录后台敏感操作、获取敏感信息、提升权限等恶意操作。
漏洞详情：某功能页面未对编辑保存在数据库中的敏感字符串进行有效过滤输出到前端页面中导致可插入html，执行js代码。
案例7: 系统存储型XSS导致后台沦陷
锡 / 银 / 科 / 技 第65页
锡银科技
Company dynamics
漏洞危害： 如果该类漏洞被攻击者利用，攻击者可利用此漏洞获取后台管理员cookie从而登录后台敏感操作、获取敏感信息、提升权限等恶意操作。
漏洞详情：某功能页面未对编辑保存在数据库中的敏感字符串进行有效过滤输出到前端页面中导致可插入html，执行js代码。
案例8: 反射型XSS可能导致用户信息被劫持
锡 / 银 / 科 / 技 第66页
漏洞危害： 如果该类漏洞被攻击者利用，攻击者可利用此漏洞获取后台管理员cookie从而登录后台敏感操作、获取敏感信息、提升权限等恶意操作。
漏洞详情：某功能页面未对编辑保存在数据库中的敏感字符串进行有效过滤输出到前端页面中导致可插入html、js代码。
XSS漏洞安全防护建议：
设计开发1）对请求数据包中的特殊字符进行恰当的编码；
2）富文本过滤使用各程序语言通用安全API库；
3）使用开发程序的安全转义库转义特殊字符；
4）严格检查参数的数据类型、数值与数据长度；
5）除在业务需要客户端脚本程序操作的cookie外，将cookie设置为HttpOnly属性。
安全测试1） 内部测试，对于涉及html页面中可控的输入输出参数尝试html标签、js代码注入；
2） 安全服务，安全服务机构对XSS层面进行安全检测。
上线运维
1） 工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
锡 / 银 / 科 / 技 第67页
3.2 敏感信息泄漏
4）严格检查参数的数据类型、数值与数据长度；
5）除在业务需要客户端脚本程序操作的cookie外，将cookie设置为HttpOnly属性。
安全测试
1） 内部测试，对于涉及html页面中可控的输入输出参数尝试html标签、js代码注入；
2） 安全服务，安全服务机构对XSS层面进行安全检测。
上线运维
1） 工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
案例9: github信息泄漏可导致拖库
漏洞危害：如果该类漏洞被攻击者利用，攻击者可利用获取到的敏感信息盗取数据信息，甚至获取数据库、应用系统、服务器权限。
漏洞详情：内部人员通过github上传已上线的互联网系统源码信息，因信息未通过脱密等方法导致数据配置信息泄漏从而被攻击者获取数据库权限。
锡 / 银 / 科 / 技 第68页
漏洞详情：内部人员通过github上传已上线的互联网系统源码信息，因信息未通过脱密等方法导致数据配置信息泄漏从而被攻击者获取数据库权限。
敏感信息泄漏安全防护建议：
设计开发
1） 安全意识提升，检查互联网存储共享协作平台，防止敏感信息通过客户端自动上传、人工上传内容未脱密、人工控制分享对象的扩散范围未限制。
安全测试
1） 安全服务，基线检查安全服务对网盘客户端进行基础安全配置、协助检查其它存在敏感信息泄漏方法途径；专项安全意识培训，提升员工自身安全防护意识及安全技能。
上线运维
1） 安全工具与设备，通过脚本和系统对外部网盘、github等互联网存储共享平台进行监控，检查信息敏感与否、脱密与否；通过网络行为对办公网流量监控及网盘流量阻断；
2）安全管理制度，建立安全检查制度，禁止办公电脑安装网盘类软件，检查存储分享软件及账号安全配置和安全内容；对于已安装此类软件的客户端和运用互联网存储分享平台的用户要求提供安全自检文档；
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第69页
3.3 SQL注入漏洞
漏洞危害：如果该类漏洞被攻击者利用，攻击者可利用此漏洞获取数据库中相应权限的数据库，甚至可利用此漏洞调用执行系统命令从而获取操作系统权限。
漏洞详情：系统id参数过滤不严，存在基于错误的SQL注入导致后台管理员等信息被获取，攻击者利用后台管理员账号密码登录后台。
案例10: SQL注入登录后台
安全防护建议：
设计开发
1）使用正确完善的"白名单"或"黑名单"来进行规范化的输入验证；
2）进行数据库操作时，使用开发程序的安全转义库转义特殊字符；
3）SQL语句预编译和变量绑定；
4）严格检查参数的数据类型、数值与数据长度。
安全测试
1） 内部测试，对于涉及html页面中可控的输入输出参数尝试html标签、js代码注入；
2） 安全服务，安全服务机构对XSS层面进行安全检测。
上线运维
1） 工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
锡 / 银 / 科 / 技 第70页
入验证；
2）进行数据库操作时，使用开发程序的安全转义库转义特殊字符；
3）SQL语句预编译和变量绑定；
4）严格检查参数的数据类型、数值与数据长度。
安全测试
1） 内部测试，对于涉及html页面中可控的输入输出参数尝试html标签、js代码注入；
2） 安全服务，安全服务机构对XSS层面进行安全检测。
上线运维
1） 工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
3.4 文件上传下载漏洞
案例11: 任意文件下载
漏洞危害：
如果该类漏洞被攻击者利用，攻击者可下载服务器相应权限的任意路径文件。
漏洞详情：
下载接口可通过修改cookie绕过防护，导致任意文件下载漏洞。
锡 / 银 / 科 / 技 第71页
锡银科技
Company dynamics
案例12: 任意图片文件替换
漏洞危害：如果该类漏洞被攻击者利用，攻击者可修改金融平台中的图片，如果图片文件是反动言论、营销的内容文件平台将遭受名誉损失和经济损失。
漏洞详情：功能下载接口可通过修改filename值，导致任意图片文件替换漏洞。
锡 / 银 / 科 / 技 第72页
安全防护建议：
设计开发
1） 对用户传输的文件名参数进行硬编码或统一编码；
2） 对文件类型进行白名单控制；
3） 对包含恶意字符或者空字符的参数进行拒绝。
安全测试
1） 内部测试，对于涉及html页面中可控的输入输出参数尝试html标签、js代码注入；
2） 安全服务，安全服务机构对XSS层面进行安全检测。
上线运维
1） 工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
锡 / 银 / 科 / 技 第73页
04 / 安全思考
安全测试
1）内部测试，对于存在文件目录资源的操作（增删改查）的功能参数尝试带入恶意攻击测试，检验是否限制用户权限操作范围；
2）安全服务，渗透测试安全服务对文件操作层面进行安全检测。
上线运维
1）工具设备，web应用防火墙拦截异常请求、漏洞扫描工具检测安全；
综上所述，针对新形势的银行业务逻辑安全攻防，银行可从下列层面来提升我们在实际工作中的价值。
- 相关人员需了解安全漏洞产生原因与危害，实时跟踪业内安全动向；
- 建立安全编码规范、提升安全测试水平、完善安全漏洞跟踪处理机制；
- 熟练掌握安全设备的原理和功能，加强外部安全公司的沟通、协作。
- 完善落实不同层级、不同岗位的安全管理制度和流程；
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第74页
返回目录
负载均衡技术作为提高业务系统服务能力与服务连续性的一种技术手段，正在应用系统交付的过程中扮演着越来越重要的作用。关于负载均衡相关技术的使用已逐渐成为新业务系统上线或原有业务系统改造时的必选项。
要通过负载均衡技术实现业务系统的高可用，负载均衡设备需要能够实时感知后端业务系统的可用性，这一环节被称作健康检查。本文将就负载均衡实现健康检查的几种方式作简要分析。
浅谈负载均衡实现健康检查的几种方式
文章：运维中心--鲍一鸿
01 / 技术背景介绍
应用程序在支撑业务系统提供服务时主要实现了两类功能，分别是：
- 接受客户端请求的功能
- 实现业务系统所需的逻辑处理功能
通常在编写应用程序或使用应用程序相关组件的过程中，开发人员会指定接受客户端请求所使用的操作系统本地地址、应用协议以及对应的端口。当应用程序启动后，应用程序会在指定的地址和协议的端口上监听客户端发来的请求，在接收到请求后，根据请求内容进行后续处理。
针对应用程序提供的两类功能，负载均衡设备也提供了两类健康检查的方式，分别是：
- 针对应用程序接受客户端请求的服务端口的检测
- 针对应用程序服务功能的检测
02 / 健康检查的分类
锡 / 银 / 科 / 技 第75页
应用程序会在指定的地址和协议的端口上监听客户端发来的请求，在接收到请求后，根据请求内容进行后续处理。
针对应用程序提供的两类功能，负载均衡设备也提供了两类健康检查的方式，分别是：
- 针对应用程序接受客户端请求的服务端口的检测
- 针对应用程序服务功能的检测
03 / 健康检查的实现方式
虽然应用程序提供的功能纷繁复杂，但根据网络TCP/IP四层模型（见表1），可以按照传输层协议的不同将应用程序区分为TCP类型的应用和UDP类型的应用。本篇文章将主要介绍负载均衡设备针对TCP类应用程序健康检查的实现方式。
表1.网络TCP/IP四层模型
锡 / 银 / 科 / 技 第76页
1. 针对应用程序服务端口的健康检查
针对TCP类型的应用程序。负载均衡可以模拟TCP建立连接的过程检查应用程序服务端口的可用性。TCP协议通过客户端与服务器之间的三次握手建立TCP连接（如图1所示）。
图1.TCP三次握手建立连接
锡银科技
Company dynamics
负载均衡通过模拟客户端发送SYN报文给服务器，服务器在监听的端口接收到SYN报文后，返回SYN ACK报文给作为客户端的负载均衡设备，负载均衡设备收到SYN ACK报文后即可判断应用程序的服务端口工作正常。
若超过规定时间未收到服务器返回的 SYN ACK报文，负载均衡设备会进行重试，若在规定的重试次数内未能接收到服务器返回的SYN ACK报文，则判断应用程序服务端口无法正常工作，负载均衡设备不会再将业务流量分配到这台服务器上。
在负载均衡针对应用程序服务端口的健康检查中，根据负载均衡设备模拟客户端断开连接方式的不同又可将这一类的健康检查做如下分类：
- TCP 健康检查
- TCP_HALF_OPEN健康检查
下面，本文将结合实际案例讲解这两者之间的区别。
锡 / 银 / 科 / 技 第77页
能接收到服务器返回的SYN ACK报文，则判断应用程序服务端口无法正常工作，负载均衡设备不会再将业务流量分配到这台服务器上。
在负载均衡针对应用程序服务端口的健康检查中，根据负载均衡设备模拟客户端断开连接方式的不同又可将这一类的健康检查做如下分类：
- TCP 健康检查
- TCP_HALF_OPEN健康检查
下面，本文将结合实际案例讲解这两者之间的区别。
图1.TCP三次握手建立连接
锡 / 银 / 科 / 技 第78页
实际案例拓扑如图2所示，负载均衡设备发送健康检查的地址为166.8.30.110，两台服务器地址分别为166.8.30.208和166.8.30.210。在两台服务器上均部署了两个应用，服务端口分别为TCP 80 和 TCP 7799。
首先来看针对TCP协议7799服务端口的检查方式。
1) TCP健康检查
在TCP这一健康检查方式中，负载均衡设备在模拟客户端与服务器成功建立TCP连接后，采用发送FIN包的方式与客户端断开连接（如图3所示）。
图3.TCP四次挥手断开连接
锡 / 银 / 科 / 技 第79页
针对前文提到的案例，通过在负载均衡设备上抓包，查看在这一过程中数据包的交互情况。在数据包中通过过滤语句进行过滤，查看负载均衡设备针对166.8.30.208这台服务器的TCP 7799端口的健康检查的实现方式。（如图4所示）
图4.负载均衡针对服务器节点1的TCP健康检查
可以看到负载均衡设备通过模拟客户端，与服务器进行TCP三次握手，建立连接关系。之后通过发送FIN包与服务器端断开TCP连接，服务器也发送FIN包与客户端断开连接。这一现象与前面的描述一致。
2) TCP_HALF_OPEN健康检查
在TCP_HALF_OPEN这一健康检查方式中，负载均衡设备在模拟客户端向服务器发送SYN包，尝试建立连接后，若服务器端口工作状态正常，服务器会向负载均衡设备回应SYN ACK报文。与TCP这一健康检查方式不同的是，在负载均衡设备接收到SYN ACK报文后，会通过发送RST报文将连接直接重置。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第80页
通过抓包可以看到，在收到了服务器端返回的SYN ACK报文后，负载均衡设备直接将连接重置。这一现象与前文对TCP_HALF_OPEN这一健康检查方式的描述一致。
3) 两种方式的对比
通过前面的介绍，可以总结出TCP 与 TCP_HALF_OPEN这两种健康检查方式的区别主要有以下几点：
- TCP健康检查方式是通过负载均衡设备发起完整的TCP三次握手的方式建立连接，之后通过TCP 四次挥手的方式断开连接。
- TCP_HALF_OPEN健康检查方式是通过负载均衡设备发送SYN包后，通过能否收到服务器返回的SYN ACK包判断应用服务端口的工作状态。之后通过发送RST包文直接将连接重置。
这两种针对应用程序服务端口的健康检查方式，各有优劣，主要体现在以下三个方面：
- 健康检查的效果：由于TCP健康检查是通过完整的TCP三次握手与四次挥手完成TCP连接的建立和断开，而TCP_HALF_OPEN健康检查在断开连接时则是直接通过负载均衡设备发送RST报文将连接重置。TCP健康检查更符合实际业务中，客户端与服务器的交互情况。
占用系统资源情况：TCP健康检查是通过完整的TCP三次握手与四次挥手完成TCP连接的建立和断开。这种情况下，在连接断开后，针对健康检查的TCP连接在服务器上会表现为TIME_WAIT状态，会占用部分系统资源。而TCP_HALF_OPEN健康检查则是直接通过负载均衡设备发送RST报文将连接重置，服务器在收到RST报文后，针对健康检查的TCP连接会直接清除，不会额外占用系统资源。所以，在占有系统资源情况方面，TCP_HALF_OPEN这一健康检查方式要优于TCP健康检查方式。
占用网络资源情况：在交互数据包的数量上TCP_HALF_OPEN健康检查要少于TCP健康检查，TCP_HALF_OPEN健康检查来回共3个数据包，TCP健康检查来回共7个数据包。所以，在占用网络资源情况方面，TCP_HALF_OPEN这一健康检查方式也要优于TCP健康检查方式。
比较这两种健康检查方式的优劣势，在我行负载均衡设备的实际使用中，针对应用程序服务端口的健康检查均采用的TCP_HALF_OPEN这一健康检查方式，默认情况下负载均衡设备每隔5秒发送一次TCP SYN包，若连续三次没收到服务器返回的SYN ACK包，则判断TCP 端口工作状态不正常
图5.负载均衡针对服务器节点1的TCP_HALF_OPEN健康检查
仍然针对前文提到的案例，通过在负载均衡设备上抓包，查看在这一过程中，数据包的交互情况。在数据包中通过过滤语句进行过滤，查看负载均衡设备针对166.8.30.208这台服务器TCP 7799端口的健康检查的实现方式。（如图5所示）
锡 / 银 / 科 / 技 第81页
- TCP_HALF_OPEN健康检查方式是通过负载均衡设备发送SYN包后，通过能否收到服务器返回的SYN ACK包判断应用服务端口的工作状态。之后通过发送RST包文直接将连接重置。
这两种针对应用程序服务端口的健康检查方式，各有优劣，主要体现在以下三个方面：
- 健康检查的效果：由于TCP健康检查是通过完整的TCP三次握手与四次挥手完成TCP连接的建立和断开，而TCP_HALF_OPEN健康检查在断开连接时则是直接通过负载均衡设备发送RST报文将连接重置。TCP健康检查更符合实际业务中，客户端与服务器的交互情况。
- 占用系统资源情况：TCP健康检查是通过完整的TCP三次握手与四次挥手完成TCP连接的建立和断开。这种情况下，在连接断开后，针对健康检查的TCP连接在服务器上会表现为TIME_WAIT状态，会占用部分系统资源。而TCP_HALF_OPEN健康检查则是直接通过负载均衡设备发送RST报文将连接重置，服务器在收到RST报文后，针对健康检查的TCP连接会直接清除，不会额外占用系统资源。所以，在占有系统资源情况方面，TCP_HALF_OPEN这一健康检查方式要优于TCP健康检查方式。
- 占用网络资源情况：在交互数据包的数量上TCP_HALF_OPEN健康检查要少于TCP健康检查，TCP_HALF_OPEN健康检查来回共3个数据包，TCP健康检查来回共7个数据包。所以，在占用网络资源情况方面，TCP_HALF_OPEN这一健康检查方式也要优于TCP健康检查方式。
比较这两种健康检查方式的优劣势，在我行负载均衡设备的实际使用中，针对应用程序服务端口的健康检查均采用的TCP_HALF_OPEN这一健康检查方式，默认情况下负载均衡设备每隔5秒发送一次TCP SYN包，若连续三次没收到服务器返回的SYN ACK包，则判断TCP 端口工作状态不正常
锡 / 银 / 科 / 技 第82页
2) TCP_HALF_OPEN健康检查
由于在部分业务场景下应用程序服务端口工作状态正常并不代表着应用程序能够提供完整的对外服务，以web应用为例，在部分网页文件丢失或损坏的情况下，无法对外提供网页信息，此时客户端会收到 HTTP 404状态码，表示网页不存在，而此时服务端的80端口其实是正常工作的。在类似这样的场景中，采用针对应用程序服务端口的健康检查无法真实的反应后端应用程序的工作状态，应当使用针对应用程序服务功能的健康检查。
要实现针对应用程序服务功能的检测，负载均衡可以模拟客户端发送应用报文到服务端，根据服务端的响应，判断应用程序服务功能是否正常。下面分别针对以下两类应用程序服务功能健康检查的实现方式做简要介绍，分别是：
- HTTP应用，通过HTTP协议实现与客户端的交互，提供web服务或HTTP 报文的交互；
- TCP应用，通过应用程序调用socket，使用TCP协议，实现报文的交互
- 占用网络资源情况：在交互数据包的数量上TCP_HALF_OPEN健康检查要少于TCP健康检查，TCP_HALF_OPEN健康检查来回共3个数据包，TCP健康检查来回共7个数据包。所以，在占用网络资源情况方面，TCP_HALF_OPEN这一健康检查方式也要优于TCP健康检查方式。
比较这两种健康检查方式的优劣势，在我行负载均衡设备的实际使用中，针对应用程序服务端口的健康检查均采用的TCP_HALF_OPEN这一健康检查方式，默认情况下负载均衡设备每隔5秒发送一次TCP SYN包，若连续三次没收到服务器返回的SYN ACK包，则判断TCP 端口工作状态不正常
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第83页
要实现针对应用程序服务功能的检测，负载均衡可以模拟客户端发送应用报文到服务端，根据服务端的响应，判断应用程序服务功能是否正常。下面分别针对以下两类应用程序服务功能健康检查的实现方式做简要介绍，分别是：
- HTTP应用，通过HTTP协议实现与客户端的交互，提供web服务或HTTP 报文的交互；
- TCP应用，通过应用程序调用socket，使用TCP协议，实现报文的交互
锡银科技
Company dynamics
1) HTTP应用程序的健康检查
针对HTTP应用程序，负载均衡设备支持模拟客户端发送HTTP GET/POST请求报文到服务端，根据服务端响应的内容判断HTTP应用程序服务功能是否正常。仍然以上面提到的实际案例来讲解这类健康检查的实现方式，拓扑如下图：
锡 / 银 / 科 / 技 第84页
在此类健康检查中，需要配置健康检查的频率（默认为5秒）、健康检查超时时间（默认为健康检查3次即判断健康检查失败，时间为16秒）、HTTP请求的方法（HTTP Method），HTTP请求的URL，以及判断HTTP应用是否工作正常的状态码或字符串。
在本次介绍的案例中，应用程序专门为负载均衡健康检查设计了检测的路径，并规定了正常状态下返回的字符串。当负载均衡请求该HTTP应用的"amlu/verification.jsp"目录时，若收到的响应中包含"Server Enable"字符串，则HTTP应用程序工作正常。同样可以通过在负载均衡设备上抓包，验证这一情况。（见图7、图8）
图6.负载均衡实际案例拓扑
锡 / 银 / 科 / 技 第85页
串。当负载均衡请求该HTTP应用的"amlu/verification.jsp"目录时，若收到的响应中包含"Server Enable"字符串，则HTTP应用程序工作正常。同样可以通过在负载均衡设备上抓包，验证这一情况。（见图7、图8）
图7.负载均衡健康检查请求
图8.服务端针对健康检查请求的响应
可以通过这样的健康检查方式判断HTTP应用具备接受和响应客户端请求的能力，以此判断HTTP应用程序工作正常。
额外需要注意的是，负载均衡设备不会缓存全部的HTTP响应内容，我行的负载均衡设备会在接收到HTTP响应内容的前5120个字节中模糊匹配是否存在用于判断HTTP应用程序工作状态的字符串，以此作为依据判断HTTP应用程序的工作状态。
锡 / 银 / 科 / 技 第86页
2) TCP（非HTTP类）应用程序的健康检查
针对TCP应用程序，负载均衡设备可以模拟客户端发送TCP探测报文到服务端，根据服务端响应的内容判断TCP应用程序的工作状态。发送的探测报文支持定长报文、XML格式报文等。下面以我行公共信息集中处理系统为例讲解这一健康检查的实现方式。
首先，根据开发人员提供的探测报文在负载均衡设备上进行相关配置，报文内容如下：
当服务器响应内容包含000000特征码时，可判断该TCP应用程序工作正常。在负载均衡设备上抓包验证这一情况。（见图9）
应内容的前5120个字节中模糊匹配是否存在用于判断HTTP应用程序工作状态的字符串，以此作为依据判断HTTP应用程序的工作状态。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第87页
图9.TCP应用程序健康检查
从上图中可以看到，负载均衡设备在发送TCP模拟探测报文(红色部分)后，收到服务端的响应（蓝色部分）。当负载均衡设备匹配到特征码000000这一字符串时，判断TCP应用程序工作状态正常。
与HTTP应用程序的健康检查一样，负载均衡设备会在接收到TCP应答报文中的前5120个字节中进行模糊匹配，查找是否存在用于判断TCP应用程序工作状态的特征字符串。
3. 健康检查实现方式的比较与选择
通过前面的介绍，我们了解到负载均衡设备可以通过对应用程序服务端口进行健康检查或对应用程序服务功能进行健康检查这两种方式判断应用程序的工作状态。这两种健康检查方式主要有以下区别：
- 健康检查效果：采用针对应用程序服务功能的健康检查是一种更贴近实际业务交互情况的健康检查方式，健康检查结果能够更真实的反映应用程序实际工作状态。并且由于应用程序服务端口工作正常是应用程序能够对外提供服务的基础，所以采用针对应用程序服务功能的健康检查实际上已经达到了针对应用程序服务端口健康检查的效果。所以，应在实际使用中尽可能的选择针对应用程序服务功能的健康检查。
锡 / 银 / 科 / 技 第88页
- 健康检查效果：采用针对应用程序服务功能的健康检查是一种更贴近实际业务交互情况的健康检查方式，健康检查结果能够更真实的反映应用程序实际工作状态。并且由于应用程序服务端口工作正常是应用程序能够对外提供服务的基础，所以采用针对应用程序服务功能的健康检查实际上已经达到了针对应用程序服务端口健康检查的效果。所以，应在实际使用中尽可能的选择针对应用程序服务功能的健康检查。
- 占用资源情况：采用针对应用程序服务功能的健康检查相较于针对应用程序服务端口的健康检查将更加消耗各类资源，包括系统资源和网络资源。并可能会产生大量的应用日志给应用运维人员带来额外的运维压力。以上问题，可以通过结合应用系统实际业务承载能力与开发人员协商健康检查频率，同时早期介入应用系统开发过程，在确定健康检查的实现方式、实现报文、是否需要记录日志等问题后，再开展负载均衡针对应用程序健康检查的实施工作。
04 / 总结
负载均衡技术作为一种提高业务系统服务能力与服务连续性的一种技术手段，在实现业务系统负载均衡的基础上，如何实现更精准的感知应用系统的健康状态是我们需要持续研究的课题。本篇文章就负载均衡实现健康检查的几种方式做了简要介绍，并对这几种方式的优劣势进行了比较，希望能对各位读者有所帮助。
锡 / 银 / 科 / 技 第89页
返回目录
2018年下半年作业调度系统的项目建设的某一天，我突然决定要项目组一起讨论下作业节点的状态的分类以及它们相互之间的转换规则。于是我召集了相关人员开会开始讨论，会上大家开始口头表述讨论，情形如下：
复杂状态转换分析的小手段
文章：运维中心--沈志浩
15分钟后虽然大家踊跃表述自己的观点，但是除了没能理解别人说的具体设计，甚至自己想好的状态及转换规则都模糊了。
于是3个小时以后项目经理进过艰苦奋战整理了一份设计的文字稿，项目组再次聚集讨论，项目经理对着文字稿内容开始讲解：
『作业节点状态一共有以下几种：未开始、处理中、已暂停、运行中、已成功、已失败、待确认、已锁定、已重跑……』
（然后就是每一个状态后面都附上了长长的一段文字说明以及可能转换到的其他状态的规则说明。）
『未开始：作业计划已经生成的状态，暂时未开始。如果手动点击"开始"，则作业到运行中的状态；如果有定时计划……
图1 讨论情形
锡 / 银 / 科 / 技 第90页
于是3个小时以后项目经理进过艰苦奋战整理了一份设计的文字稿，项目组再次聚集讨论，项目经理对着文字稿内容开始讲解：
『作业节点状态一共有以下几种：未开始、处理中、已暂停、运行中、已成功、已失败、待确认、已锁定、已重跑……』
（然后就是每一个状态后面都附上了长长的一段文字说明以及可能转换到的其他状态的规则说明。）
『未开始：作业计划已经生成的状态，暂时未开始。如果手动点击"开始"，则作业到运行中的状态；如果有定时计划……
处理中：……
……』
之后15分钟项目经理滔滔不绝的把全部状态讲了一遍，众人也纷纷积极参与提问。可是当我环顾一下项目组的其他人时不禁有种错觉：感觉大家的头又变大了一圈。我忍不住怀疑其他人是否与我一样：大致明白了这些状态以及含义，对于之间的转换规则也觉得没大问题；但是对于作业调度系统是否需要这么多状态、还有没有遗漏状态、转换规则是否已经齐备是否可以简化等等根本没有直观的感受和整体的思考，每个人的思维都伴随着这一个个状态呈现碎片化的分布，既难以继续讨论，也很难做出该设计到底行不行的结论。
正当我感到非常为难不知道如何继续下去的时候，我倒是突然想起了之前故障分析讨论过程中不止一次用到的TCP状态转换图。
锡 / 银 / 科 / 技 第91页
图2 TCP状态转换图
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第92页
锡银科技
Company dynamics
这图有多牛逼我不知道，但是这图有多实用我可是有切身体会。于是我想"要是作业调度的状态转换画成这个图这样不就方便了？"
然后我开始在脑海中绞尽脑汁的检索我大学里曾学过的计算机知识，所幸终于在一顿"冥思苦想"的挣扎后得到了那个想要的名词："有限状态机"。下面就由我陪同大家一起回忆下这个其实很简单的东西吧。
有限状态机是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。
有限状态机是一个五元组： ，其中
是有限状态集合。在任一确定的时刻，有限状态机只能处于一个确定的状态 ；
是有限输入字符集合。在任一确定的时刻，有限状态机只能接收一个确定的输入 ；
是状态转移函数，在某一状态下，给定输入后有限状态机将转入状态迁移函数决定的一个新状态；
是初始状态，有限状态机由此状态开始接收输入；
是最终状态集合，有限状态机在达到终态后不再接收输入。
一般情况下可以用状态图来对一个状态机进行精确地描述。大家可以回头看看上面的TCP状态转换图。接下来就看看我自己根据有限状态机的定义画个单作业节点的状态图吧。
一开始我当然就是迫不及待的定义单作业的状态集合
后拉线画图：
锡 / 银 / 科 / 技 第93页
图3 单作业节点状态转换草稿图
然后我通过分析上图修正了自己第一稿的几个错误：
1 项目作业调度系统调度的作业是执行在目标对象上，作业调度系统仅仅是发起调用和接受返回，状态"pause"前面的输入暂停"pause"是无法实现或者不存在的，所以状态"pause"是可以去除的；
2 状态"waitconfirm"的后续输入继续"continue"是不对的，"continue"应该是状态"pause"后的输入，此处状态"waitconfirm"的后续输入应该是"unlock"，后续状态回到"ready"才是合理的；
3 经过上述状态"waitconfirm"的修改，状态"doing"就完全处于状态"ready"和状态"running"之间了，而且后续输入预处理"pretreatment"也很奇怪，不是个单独的输入，完全可以包含在输入人工触发"manual"和定时触发"timing"中，所以状态"doing"可以去掉。
后拉线画图：
锡 / 银 / 科 / 技 第94页
2 状态"waitconfirm"的后续输入继续"continue"是不对的，"continue"应该是状态"pause"后的输入，此处状态"waitconfirm"的后续输入应该是"unlock"，后续状态回到"ready"才是合理的；
3 经过上述状态"waitconfirm"的修改，状态"doing"就完全处于状态"ready"和状态"running"之间了，而且后续输入预处理"pretreatment"也很奇怪，不是个单独的输入，完全可以包含在输入人工触发"manual"和定时触发"timing"中，所以状态"doing"可以去掉。
返回目录
4 状态"ready"到状态"running"之间可以有两个输入手工触发"manual"和定时触发"timing"，其实本事都是触发，只不过是系统操作的方法不同，一种是页面上点击按钮，一种是后台程序定时器，输入操作完全可以统一为"trigger"。
5 状态"failed"时作业可能会进行系统外的干预处理，处理完成后我们很可能需要通过手工操作输入"ignore"从而把状态转换到"succeed"，
修正以后状态后修改如下：
锡 / 银 / 科 / 技 第95页
图3 单作业节点状态转换草稿图
这回单作业节点的状态图看上去简洁明了了，也终于能够拿出去和项目组讨论了。此时单作业节点的限状态机模型如下：
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第96页
至此我自己看了一遍感觉没啥问题，于是召唤了项目组同仁们再再讨论了一次，这回大家终于可以"正常"的交流了（泪流满面）。
后面项目组以TCP状态转换图为榜样，继续针对一个作业状态（包含多个作业节点）和作业调度系统状态（包含多个作业）进行了类似的设计和分析论证，过程中的交流也不再有文中开头的那般尴尬。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第97页
今年春节期间当我看见朋友圈中的"上拜图灵只佑服务可用，下跪关公但求永不宕机"的程序员专属对联时颇有感触。我不知道下跪关公是否有效，但是多去拜拜图灵这样的逻辑学大师对于计算机工作绝对是极有用的。同时我对于已然遗忘大学生涯中学到的计算机知识感到深切遗憾和懊恼，此刻已决心要重新翻阅当初的课本重新拿回本属于的自己的财富。
后面项目组以TCP状态转换图为榜样，继续针对一个作业状态（包含多个作业节点）和作业调度系统状态（包含多个作业）进行了类似的设计和分析论证，过程中的交流也不再有文中开头的那般尴尬。
锡 / 银 / 科 / 技 第98页
返回目录
今天我们就DataStage的高可用性来简单聊一聊，在展开这个话题之前，先对部分内容做一个简单阐述，方便后面的理解。在开始聊这个DataStage之前，必须先讲一下ETL，什么是ETL呢？ETL是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，ETL是数据仓库的重要一个环节，起着承前启后的作用。那么今天聊的DataStage就是ETL产品中的一个，从目前金融行业使用来看，主要有3种相对比较成熟的产品，分别为Datastage、Informatica、Kettle，还有一些目前新兴大数据技术上使用的产品sqoop等。当然，今天本文主要不是来讨论几个产品之间的差异，更多的还是来聊聊有关DataStage的应用高可用架构，下面我们就回到这个话题本身。
01 / 背景
今天我们就DataStage的高可用性来简单聊一聊，在展开这个话题之前，先对部分内容做一个简单阐述，方便后面的理解。在开始聊这个DataStage之前，必须先讲一下ETL，什么是ETL呢？ETL是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，ETL是数据仓库的重要一个环节，起着承前启后的作用。那么今天聊的DataStage就是ETL产品中的一个，从目前金融行业使用来看，主要有3种相对比较成熟的产品，分别为Datastage、Informatica、Kettle，还有一些目前新兴大数据技术上使用的产品sqoop等。当然，今天本文主要不是来讨论几个产品之间的差异，更多的还是来聊聊有关DataStage的应用高可用架构，下面我们就回到这个话题本身。
锡银科技
Company dynamics
DataStage应用高可用性浅谈
文章：开发中心顾琪冰
锡 / 银 / 科 / 技 第99页
Load 的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程，ETL是数据仓库的重要一个环节，起着承前启后的作用。那么今天聊的DataStage就是ETL产品中的一个，从目前金融行业使用来看，主要有3种相对比较成熟的产品，分别为Datastage、Informatica、Kettle，还有一些目前新兴大数据技术上使用的产品sqoop等。当然，今天本文主要不是来讨论几个产品之间的差异，更多的还是来聊聊有关DataStage的应用高可用架构，下面我们就回到这个话题本身。
图1.DataStage
现有架构
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第100页
为此项目组联合运维系统组以及IBM相关工程师就Datastage的高可用集群改造进行商讨，以满足数据仓库的稳定性。为了能够满足整个集群的高可用性，对于改造方案提出了几点要求：
从上述的图中可以看出，DataStage的安装模式虽为双机，但其实却为单套环境，DataStage1为主环境，DataStage2为计算节点资源，主要分担主节点的计算量，提升效率，但对高可用没有任何帮助。DataStage2如果发生宕机不影响整体环境的使用和运行，但如果DataStage1出现问题，则整套DS将无法使用。因此行内的新ETL环境存在着较为严重的单点故障问题，对后续生产的稳定性造成了较大影响，而在实际生产的使用过程中，也确实碰到了DataStage1主节点问题导致整个DS集群无法正常使用的情况，影响了整个批量业务的处理，因此DataStage的高可用方案改造也就迫在眉睫。
02 / 解决方案
1、高可用性是基本的要求，优先解决该缺陷
2、尽量减少对已有系统的改造工作，能够实现快速的部署和切换，也方便后续的横向扩展。
3、尽量减少系统间的复杂度，方便后续的维护。
基于以上几点要求，再结合了各方的建议，最终讨论提出了如下的解决方案,具体架构如图2。
锡 / 银 / 科 / 技 第101页
图2.调整优化方案
此方案采用的是DataStage多套独立环境的部署方式，相互之间的运行互不影响，而对于数据文件采用的共享NAS的方式，来保证多套环境中数据的一致性。此种方案有点类似于F5集群的模式，前端应用APP的多套独立部署，也方便后续的横向扩展。但此Datastage方案需要应用的配合改造使用，由于在现有的架构中，DataStage主节点的服务器上安装了Moia的调度平台客户端，在NAS上面部署了数据平台的相关执行脚本，整个数据平台的运行都通过了调度平台自动去执行。
锡 / 银 / 科 / 技 第102页
据平台的相关执行脚本，整个数据平台的运行都通过了调度平台自动去执行。如果使用新的方案，主要解决的问题是如何让应用来解决二套DS环境的任务分配，保证任务分配的独立性，防止任务重复计算。数据平台的执行脚本和落地数据文件可以通过NAS实现共享，Datastage的作业也可以2台同步部署来保证作业的一致性，关键点问题是主要如何实现批量作业自动化分配执行，又能做到故障发生时自动切换作业任务的要求。由于此前没有该类问题的方案处理经验，因此如何解决上述问题，一直困扰着项目组。
随着各方的深入讨论研究了解后，最终应用端的解决方案以Moia调度平台的执行域管理来实现。以往我行的调度平台的client执行端一般都是单机配置，未做过多机执行端的配置，因此在执行域的管理上一般都是以单个物理节点配置为主。由于本项目的特殊性，为满足多任务分配有序执行，我们在2台DS服务器上面都安装了Moia的执行端，再将这2台执行端组成一个执行域进行统一管理。具体的配置调整如下：
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第103页
图3.DS与MOIA架构图
图4.MOIA执行域管理
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第104页
此配置下面，将多个物理节点调度的执行端放在一个执行域统一管理，Moia调度就可以解决任务分配的自动调整。当整个计划任务执行起来后，Moia调度就按照内部的逻辑规则平均分配到几个节点上自动执行任务，调度平台会实时的自动检测各节点的状态，如果其中任何一个节点出现故障，调度将会自动将任务分配到剩余的节点，保证计划任务不会出现中断，整体作业不受影响，这样也保证整个DS集群的稳定性。以下，就是我们按照这个方案在测试环境上面做的部署测试，红色方框可以看出任务执行时，调度平台自动将任务分配到了不同节点去执行，保证了整个任务的完整性，也有效解决了DS高可用的问题。
图5.MOIA执行测试案例
03 / 总结
银行系统的稳定性和高可用性，一直是重中之重，以往我们在建设高可用环境的时候更多从运维的F5、NAS、HA、存储复制等方面去考虑，今天讨论的这个案例应该来讲，架构层面并不是很复杂，我们只是换了一个思维方式，通过另外一个途径去解决这个高可用性，同时也简化运维层面的复杂性。在此案例中，我们并没有去太多考虑DS集群高可用方案，而是通过应用层面的适当改造，来满足这个要求，同时也大大降低了其复杂度。随着互联网技术的不断发展，将有越来越多的新技术新平台将逐步使用，对于系统的高可用性，也需要我们不断去转变思维模式，从应用+运维等多方面多维度去思考，来提高整个系统的稳定高效运行，以上就是对于DataStage高可用性的一些浅谈。
锡 / 银 / 科 / 技 第105页
运维层面的复杂性。在此案例中，我们并没有去太多考虑DS集群高可用方案，而是通过应用层面的适当改造，来满足这个要求，同时也大大降低了其复杂度。随着互联网技术的不断发展，将有越来越多的新技术新平台将逐步使用，对于系统的高可用性，也需要我们不断去转变思维模式，从应用+运维等多方面多维度去思考，来提高整个系统的稳定高效运行，以上就是对于DataStage高可用性的一些浅谈。
锡 / 银 / 科 / 技 第106页
返回目录
年前遇到一个案例，在更新了网银服务器证书之后发现有一台银企直连服务器无法正常建立安全通道完成登录。当时并没有考虑到证书的问题，在网络和应用上折腾了很长时间。最后发现网银服务器证书的中级证书及根证书发生了变化，而银企直连服务器并没有安装新的中级证书和根证书导致证书认证失败无法建立安全通道。问题虽然解决了，但是发现对于证书的原理及使用还一知半解，因此特意查找了相关资料并做了整理。
证书链浅析
文章：开发中心--戈珺
在解释证书链之前首先要了解一下非对称加密的相关概念，由于篇幅的限制非对称加密另外再做讲解。在这里先介绍一下数字证书，有很多同学将数字证书和密钥概念混淆，其实数字证书包含了证书持有者的公钥以及持有者信息和证书有效期、签发者签名等一系列信息。数字证书是各种信息的一个集合，而密钥只是数字证书中的一个元素。数字证书有两个非常重要的属性，其中一个是刚刚提到的持有者，另外一个就是数字证书的签发者--CA。在这里我再澄清一下数字签名和数字证书的关系。相信很多同学都知道数字证书用来做数字签名，这么说不能算错，但其实是不严谨的。为了更清晰的理解两者的关系我举个例子加以说明。先假设有同学A、同学B和我三人，我将同学A的公钥、他的信息和我的签名做成数字证书a，颁发给同学A，此时我就是CA，是证书a的签发者，同学A是数字证书a的持有者。当同学A向同学B写信时，把信的内容用hash算法生成摘要，再用私钥对摘要内容用sha256算法生成一串密文，这个对摘要的加密就是数字签名（见图一）。
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第106页
给同学A，此时我就是CA，是证书a的签发者，同学A是数字证书a的持有者。当同学A向同学B写信时，把信的内容用hash算法生成摘要，再用私钥对摘要内容用sha256算法生成一串密文，这个对摘要的加密就是数字签名（见图一）。
图一：签名流程
锡银科技
Company dynamics
同学A将信的内容连同数字签名和证书a一并发给同学B，同学B收到后用CA的公钥来验证数字证书a里的签发者签名，确认该证书确实是属于同学A的是可信的，然后从证书中获取同学A的公钥，并使用该公钥对同学A的数字签名进行验证。因此数字证书的直接作用是保护信息发送者的公钥，间接作用是对信息发送者进行验签（见图二）。
锡 / 银 / 科 / 技 第108页
证书中获取同学A的公钥，并使用该公钥对同学A的数字签名进行验证。因此数字证书的直接作用是保护信息发送者的公钥，间接作用是对信息发送者进行验签（见图二）。
图二：验签流程
锡 / 银 / 科 / 技 第109页
通过上面的例子我们基本了解了密钥、证书以及签名的概念和两两之间的关系，也了解到同学A使用CA颁发的证书保护了自己的公钥不被篡改，但是又怎么保护CA的公钥不被篡改呢？最直接和简单的方法就是把CA的公钥做成证书b（中级证书）交给同学B，而制作证书b的公钥则做成根证书。简单的说认证过程是这样：同学B收到信件后首先查看信件中的证书签发者，通过签发者向上一级找到中级证书，再进一步找到根证书。然后再用根证书公钥去验证中级证书的签名，再用中级证书的公钥验证同学A证书的签名。以上验证都通过后即可确认同学B收到的信件确实是由同学A发出的，而这三张证书就形成了证书链。通过下面的图大家可以更直观的理解整个过程（见图三）。
图三：证书链验证过程
锡 / 银 / 科 / 技 第110页
了解以上原理后，在实际使用电脑过程中我们要注意两点：首先定期查看个人电脑的证书管理器，重点关注"受信任的根证书颁发机构"这一栏，将可疑的根证书删除。轻易不要手工导入根证书。其次，设置好个人电脑开机密码，防止他人在自己的个人电脑上安装证书。细心的同学应该会发现我们现在只解决了同学B确认同学A的过程，如果信件被同学C截取，那同学C岂不是也知道了信件的内容？那应该做才能确保同学A写给同学B的信件不被其他人查看呢？其实这个问题通过对称加密与证书相结合的方法就很好解决，我们下一期再继续讲解。
返回目录
锡银科技
Company dynamics
锡 / 银 / 科 / 技 第111页
返回目录
无锡农村商业银行
地址：无锡市金融二街9号
网址：www.wrcb.com.cn
增值电信业务经营许可证：陕B2-20210327 | 
陕公网安备 61102302611033号