一次剐蹭引起的程序员业务分析

背景：

租某公司平台汽车，右转中，直线行车快速驶入，引起车辆左前方的车壳挤压变形。后续走交警，保险，理赔，金额垫付。

就此进行业务分析。

首先业务涉及的第五方面：

A 我方车辆  可以理解成业务发起人，客户端请求。

B 对方车辆 可以理解为业务并行信息

C 交警部分

D 租车公司

E 保险公司 

业务流程：

part -1

我方A车右转弯与B车快速驶入十字路口候车区，因太快发生两车挤碰。A车缓慢观察行车，B车快速驶入，刹车迅速。

此时，我方A驾驶者，我十脸懵，抓后脑勺表情。停车后，下车查案情况。对方下车，Emmmm,国粹话，怎么开的车。然后报警，双方不移动车等待责任判断。

这个可以理解为业务触发，引起后续业务流程处理，我方与对方或的关系执行下一步报警流程。

这个在技术上就是Sping的拦截，触发情况。接口可以写成 -- 交通 事务类型（举TrafficAccidentA  ）。因为分布式微服务业务，需要调用报警系统。通过连接请求警务系统。

警务系统下122报警，首先是电话接通，进行事故登记，人工核实，然后进行消息推送，以及跟踪。并且记录数据：报警手机号，事故地方，事故类型，事故地点等。122报警中心数据记录，然后根据事故地点进行消息推送到对应的负责该区域交警的个人手机APP，并提示信息，标红。

这个地方就是业务处罚的第一阶段。这里面会涉及到一个队列，redis缓存，因为交警需要确认是否手上有其他的事故，过去大概时间，反馈信息，执行开车到线程的过程。此时我的剐蹭事故处于待处理阶段，标识为handleState =false。在报警系统中是分布式的一个接听，也即是多个话务员接听交通报警电话，然后进行数据记录，按照先进先出的顺序去走一个信息推送。然后在对区域交警确认一个队列顺序，或者是多个交警负责一个区的交通事故。这里可以设计成一个Spring的自动扩容的状态，快速处理事故，减少交通影响。

part -2

我十脸后脑勺抓头的后，冷静下来后，首先个人梳理下思路。肯定是涉及到跟租车公司的沟通，确认后续的如何处理。首先对话交车的人，因为是第一对接人，并且是可以最近接触的租车公司的负责人。

对方接到电话后，首先是进行了情况确认，安抚情绪，后续的手续和如何操作，告知了对应的公司后台的处理事故的部门，以及对应的保险事故专员电话。然后随时保持沟通。

后处理事故的部门、保险公司专业对话，确认情况，告知后续处理流程，以及目前所需操作。

1.拍照 2,等待交警定责 3.按照定责，走理赔流程（有保险走保险，没保险个人出钱。）

这段的业务其实就是我这边流程处理，在有报警的前提下，执行的调用租车公司个人端的数据对接，然后执行租车公司后端，其他的部分服务，从租车的方说就是不同的业务部分，微服务+分布式，责任划分以及多处理。租车公司根据我放的信息，包括租车购买的服务，租车公司购置汽车时候跟汽车公司签订的关于保险的范围业务。推送信息给保险的一个事故队列信息，内部应该有一个预警，消息推送的的处理，也就是接到租车公司的信息之后， 保险公司系统根据信息，消息队列化，然后给对应的事故专业。事故专员的个人APP上，得到消息，并且红色提醒。正常是接到后跟事故人进行沟通，确认信息，告知事故人目前这个情况跟他的业务经验的处理，以及后续需要准备的东西。协助事故者进行数据采集，以便后续的理赔业务流程。

这里其实就是涉及到我个人对租车公司请求，租车公司数据收集，然后对接保险公司，保险公司采集数据进行下一步处理，只要等待交警定责。

这一段包含的就是Person ->Company ，Company <-->Company,Company ->Person。

从技术说，个人请求，到租车公司下小点，然后到租车公司的后台专门服务。为了应对业务，是一个队列处理，微服务。然后是保险公里，接到系统租车公司信息，进行消息叫停，也就是消费者模式，在进行内部的业务微服务化的调用，业务专业一个监听状态。得到信息后进行依次处理。对接我个人后，在进行信息反馈到保险公司的总体事故处理微服务，在同步信息到租车公司，租车公司在下发信息到租车点。

此时业务处理等待处理阶段，各个阶段等待交警到县城定责。如若按照多线程就是此时是挂起，等待被唤醒。线程资源切换其他的执行任务。实际中，是不论交警系统报警系统，理赔公司，还是租车公司都会切换人员处理其他的事务。

part -3 

当然了，我方主也处理挂机等待状态，并且持续进行分析，判断，还有琢磨的阶段。

拍照，取证，缓过神来之后，对事情进行回顾分析。

车辆缓慢右转，对方直行快速插入。按照交规是都可以执行的，但是右转让直行。

我的车先出的头，缓慢驶入中，对方快速插入，在十字路口前，相碰的整好车头钱于我车头。

这里涉及到的是交警的判定标准。会根据事故发生情况，发生后未动的拍照进行线路等进行判断。

作为车速，如果限速那就是对方有部分责任，否则就是我全责。属于观察不到位。

在租车公司来说就是否有投保，在保险公司来说就是交警定责，有保险就走保险，数据采集完事走认定的理赔范围。

交警到达之后，根据实际的拍照还有原因，沟通双方，说明定责原因，后拍相关驾驶证，行驶证，以及现场证件，后交警个人APP提交数据，反馈给交警后台。

交警后台根据数据进行后续业务的完结，数据收录。然后走一个短信通知涉及的A,B两方。

当然了。还有有一个后续的觉得不合理再次申请。

这部分就是取证，信息执行后续的交警部门的内部数据备份，以及后续的申诉阶段，申诉阶段后的评分阶段。以及最后还有一个资格登记的情况。这个听说是会根据个人的故事，后续买车保险会适度加大保险的起步。

租车公司，以及保险公司，会根据定责的确认书，进行后续的根据。

这一部分我觉得没啥好说的，就是数据回流。最后保险公司采集定责，根据和租车公司的保险，操作记录数据，然后通知，等待线下A，B两房修车，出具发票之后，直接数据收录。走财务审批。

财务审批之后，进行转账执行，通知对方。就OK。

part -4

从租车这里了解到的就是同步事故信息，确认保险呢公司的理赔范围，客户的购买服务是否在理赔范围内，然后告知用户后续需要的垫付金额，以及后续根据对所要的票据证明，然后对接保险公司。对方的打款之后，在进行的一个金额转账。

从技术上，就是确定定责书后，保险公司和租车公司请求交警的接口，获取事故的线上信息，然后保险公司通知事故人、租车公司，确认然后转账。

也就是接口调用信息，内部服务请求财务，财务审批，反馈专员，专员沟通事故者，租车公司，信息同步，之后该事故的理赔录入数据。最后也是短信通知好拼调研问卷。

租车公司根据反馈的信息，沟通事故双方，取得维修凭证，数据，进行报销。

最后我先垫付，然后留证明，然后租车公司对我转账付款，事情完结。

回顾一下：

整个事情就是车辆碰擦，然后涉及到5各方面，交警系统，保险公司系统，租车公司，我个人，对方车辆，五个方面，从用户的角度去分析业务触发，后台的逻辑处理。

从程序员的角度，联想的业务和技术实现问题。

其中最主要的微服务+分布式，队列，观察者模式，数据推送，事务的跟踪。其实后台肯定还有大数据分析，以及数据库主从备份。数据库百万更多两级的数据处理。保险行业应该是数据很大。

在延伸，就是业务经理，根据以往数据，调整保险的理赔比例还有几率，那些保险是比较优的。对此展开的一些列的活动设计啊，商业合同之类的运营策略。

最后

算个结论，觉得有意义。

最后的最后事故处理的比较顺畅，大家可以借鉴下。开车多注意个人安全，以及如果碰到事故，看下心里多少有点底气。