握手机制反复上线失败问题记录分析

本文主要是介绍握手机制反复上线失败问题记录分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目录

问题说明：

场景说明：

每次上线失败原因分析：

第一次上线失败原因分析：

第二次上线失败原因分析：

第三次上线失败原因分析：

第四次上线失败原因分析：

问题经验总结：

---

问题说明：

握手机制简单来说就是接口调用过程，现就握手机制反复上线失败问题作出如下总结、分析。

场景说明：

握手机制接口调用涉及3个厂商，5个服务。调用过程如下图：

每次上线失败原因分析：

第一次上线失败原因分析：

        失败结果体现：MOP和XSB在pdf工单加载和保存操作速度慢，影响了工单业务办理。

        处理方式：版本回退

        分析代码逻辑： DMZ  Map存储必要参数，形成XML格式请求报文到BHPS服务，BHPS提供一个接口供DMZ调用，接口包含调用能开接口和请求响应报文入库两个主要逻辑。xml格式请求报文传输方式以字节流传输。

        分析结果：认为是调用能开接口响应较慢，影响了页面工单pdf加载和保存效率。

        解决方法：为不影响业务办理主线程，在调用能开接口和日志入库过程中采用异步方式。

第二次上线失败原因分析：

        失败结果体现：虽然解决了pdf工单加载慢和保存操作速度慢问题，但经数据比对，发现在核对数据准确性，存在较大出入。

        处理方式：版本回退

        分析：在比对数据是，发现数据错乱，不准确，调用能开接口响应结果报错情况，并且又了解到新需求，必须保障数据准确性达到100%，于是推翻调用能开接口和日志入库采用异步方式。

       分析结果：认为是调用能开接口响应较慢，影响了页面工单pdf加载和保存效率。

       解决方法：能开接口优化，请求报文新增地市编码（home_city）和月份（month），以供CRM进行表分区，建索引

第三次上线失败原因分析：

           失败结果体现：根据第二次优化，重新上线，上线后pdf工单加载和保存操作速度慢，影响了工单业务办理

           处理方式：版本回退

           分析：上线过程中，在调用能开接口代码处加了调用时长日志输出，经调用时长日志输出，发现接口调用耗时在200毫秒内，正常范围。重新分析，是不是可能在请求报文和响应报文入库环节耗时过多？于是在在入库环节增加耗时日志，发现请求报文和响应报文入库耗时在4/5秒左右，定位到问题结果在于表结构创建的不合理

          表结构如下：

--日志表结构
create table T_BH_DXMLDOCEMAILYYYYMM
(case_no        VARCHAR2(15),xmldoc         BLOB,op_time        VARCHAR2(20),handrespondxml BLOB,handxml        BLOB,source_type    VARCHAR2(100)
)

   不合理原因：1  表结构存在过多BLOB类型字段，在日志入库、更新操作时，效率低下，耗时较久。

                         2. 表结构 针对主键也没有创建索引，导致查询数据较慢

   解决方法：重新设计表结构

-- Create table
create table T_BH_HANDLOG201810
(case_no             VARCHAR2(15),city_code           VARCHAR2(10),source_type         VARCHAR2(100),print_id            VARCHAR2(20),status              VARCHAR2(10),describe            VARCHAR2(1000),create_time         DATE,update_time         DATE,load_interface_time INTEGER,save_interface_time INTEGER,load_resp_type      VARCHAR2(10),load_resp_desc      VARCHAR2(1000),save_resp_type      VARCHAR2(10),save_resp_desc      VARCHAR2(1000),comments            VARCHAR2(1000),month               VARCHAR2(20)
)

第四次上线失败原因分析：

         失败体现：重新设计日志表结构和对表创建索引之后，日志入库有了明显提高，并且工单pdf加载和保存效率有明显提高，工单业务办理正常。但是经比对分析日志表数据发现，日志数据准确性存在较大出入、并且能开接口响应报文也存在很多失败情况。

         处理方式：版本回退

         分析：经过日志分析，发现DMZ向BHPS服务传递参数数据存在错乱，导致请求报文里一些参数不准确。

         解决方法：由于DMZ向BHPS传递参数存在错乱，由于我们只传一个关键参数caseNo作为查询条件，其他参数到数据库中获取，BHPS封装请求报文，然后在调用能开接口和日志入库。

        传递参数数据错乱原因：经过分析，是因为多线程问题导致。 模拟实际问题如下代码DEMO，每个子线程代表一个工单业务办理过程。项目采用的框架是structs1,而structs1创建的Action是单实例，一个Action实例处理所有请求。structs1存在线程安全问题。

package com.agile.tool.test;/*** Created by gaoming on 2019/11/7.*/import java.util.HashMap;
import java.util.Map;/*** @version 1.0* @auther gaoming* @create 2019/11/7* @Description TODO*/
public class jdbcTest {private static Map<String,String> map = null;public static void main(String[] args) {Thread thread0 = new Thread(new Runnable() {@Overridepublic void run() {init("0");}});Thread thread1 = new Thread(new Runnable() {@Overridepublic void run() {init("1");}});Thread thread2 = new Thread(new Runnable() {@Overridepublic void run() {init("2");}});//模拟多个业务办理操作thread0.start();//模拟业务办理操作间隔时间//try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}thread1.start();//模拟业务办理操作间隔时间//try {Thread.sleep(3000);} catch (InterruptedException e) {e.printStackTrace();}thread2.start();}//模拟pdf工单初始化加载过程public static  void init(String i){//赋值map = new HashMap<String, String>();map.put("caseNo","aa"+i);//模拟实际业务操作其他代码处理耗时try {Thread.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}//模拟调用握手接口，传递参数信息System.out.println(map.toString());}}

 运行demo预想结果：   

 {caseNo=aa0}
 {caseNo=aa1}
 {caseNo=aa2}                                                        

运行DEMO实际结果（而且存在多种可能性）：

 

 

 

问题经验总结：

1.   首先因为地理位置和网络环境原因，在安徽开发，而项目是福建项目，测试环境在福建，而且调用能开接口测试链接只能在测试环境网络通，本地开发网络不通，开发人员无法本地开发测试，导致功能开发测试不充分。
2.   创建日志表结构太随意，表结构设计不合理。
3.   没有大量并发测试，压力测试。
4.  当然也有我个人因素，在代码规范性和逻辑严谨性存在不足，以后需要注意代码更加规范合理。

     握手机制经过反复上线回退，上线失败5/6次，多次局方投诉，受到公司领导层关注，导致影响较大，特此记录，铭记教训！！！

 

 

 

 

 

 

这篇关于握手机制反复上线失败问题记录分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---