新能源车辆双积分管理系统，该系统是为了政府人员便于管理各大车企在新能源车辆上的积分交易而研发，通过该系统可以实现政府人员对各大企业新能源车辆积分的交易进行查看，汇总，打印报表及对历年积分的变化情况进行记录查看。 该系统基于zookeeper+dubbo+spring+mybaits及mysql数据库进行开发，前端主要使用的是jquery及js语言，通过git进行协同开发，本人主要负责企业交易大厅中发布交易，该模块采用观察者模式，定向交易及管理端对交易双方的积分交易进行审批，查看，汇总，在此过程中，通过dubbo来对不同库的数据表进行管理，四种交易详情：新能源交易大厅： 出售大厅：出售积分车企 发布交易 定价整体 定价拆分 竞价整体 竞价拆分 1．发布定价整体交易 交易过了公示期后，应价车企将在出售大厅可以应价该交易（应价车企的具备的条件是必须有新能源类型的积分，否则将不能应价），应价车企应价该交易后，将会向双方车企都发送邮件，并且该交易会产生订单，交易状态变为已下架，出售者在我发布的交易模块可以看到自己发布的交易，并可以看到应价的车企；应价之后，应价者可在我参与的交易里看到自己应价的交易，并在此进行确认操作，当应价方确认后，需出售方在我发布的交易也进行确认，当双方进行确认后，应价者在我参与的交易里，进行该笔交易的上传附件操作，上传附件后，该交易将经过管理端审核人员进行三级审批，在管理端双积分管理-新能源积分管理-分配审核模块中，对该订单进行分配审核人员，当形式审核通过后，积分进行交换，若该交易没有通过，选的是退回进行补充材料，则该交易需应价者重新进行上传附件，接着还是走该流程，直到三级审批通过，在此若该交易在规定的时间内没有进行审核，则积分将不会交换，冻结积分返还冻结出售的积分，该笔交易状态已下架，订单状态已关闭。 2. 发布定价拆分交易 交易过了公示期后，应价车企将在出售大厅可以进行应价，此时，多个车企可以进行应价，直到将出售的积分数量买完，则该交易将不在出售大厅显示，此时， 会有多个订单产生，交易状态已下架，接着就是上面所说的流程，订单创建-确认-双方确认-上传附件，在管理端双积分管理-新能源积分管理-分配审核模块中，对该订单进行分配审核人员，跟上述流程所述无异。 3. 发布竞价整体交易 交易过了公示期后，应价车企将在出售大厅可以进行应价，此时，该交易的积分数量出售，会选择出价最高的车企才能买到，当应价车企应价后，产生投标记录，多个车企投标后，该交易将不会下架，直到结束时间到时，会自动筛选出胜出的投标，此时投标会生成对应的订单，投标时买的积分数量不一定是最终数量，产生的订单记录上的积分数量才是企业最终获取到的数量，此时应价的车企进行确认-双方确认-上传附件，同上流程。 4. 发布竞价拆分交易 交易过了公示期后，应价车企将在出售大厅可以进行应价，此时，该交易的积分数量出售，会选择出价最高的车企才能买到，此时多个车企应价，生成多个投标，当结束时间到时，则将生成多个订单，当订单生成后，同上流程。

该系统主要是通过Spring cloud+nacos+gateway+redis+mysql+自定义消息队列+K8S+aliyun ECS进行开发，基于二期工程后为了适应大量用户的访问、更好的监控设备是否故障或网络中断及更方便的部署服务，增加监控设备服务模块，并将命令下发模块拆分重构成一个独立的工程产品（DC）来开发，向上接入业务模块下发的业务记录，向下对消息进行存储转化下发给对应设备，并在DC中自定义消息队列来按顺序存储消息； 当业务模块调用DC暴露的接口前，业务模块需自定义生成一个traceId（为了追踪整个流程）及sourceId（记录消息来源）作为header请求头传递给DC接口，DC通过检验该记录是否符合消息规范从而进一步处理； 若检验通过则进行保存并将traceId，sourceId进行保存，并调用提交接口将该记录进行转换成设备所需消息规则进行下发，（转换成的消息上带上rid随机码值保存到消息表），设备会返回传递的rid、code、timestamp属性值，若设备返回的code码200则表明下发成功，更新消息表标识为成功标识；若设备返回code码非200成功码，则下发失败并更新消息表标识为失败标识，此时的失败是设备网络中断或设备故障导致，所以进行消息下发重试：在此重试时需要防止消息重复下发，故每次重试时需要先调用设备返回rid的接口与该失败消息的rid是否相同，若不同，则将该消息进行下发，并将消息表标识更新成功；若相同则不再下发该消息。（此过程是因为下发成功，但是设备返回消息时断线或故障，导致服务未收到成功通知） 若达到重试次数后，依然没有返回rid、code，则将用户后续下发的指令进行存储，并调用当监控服务接口查看设备当前状态是否在线，若在线，则将该消息表中存储的失败标识的消息取出来按时间升序排序后放入消息队列下发给设备。 当用户在业务层面对该记录进行修改时，则调用dc后，dc通过header头传递的traceId进行查询出相关记录并对该记录进行克隆后，将副本进行更新，之后调用删除接口下发删除本体消息，在调用提交接口下发副本最新消息；在修改过程中用户可能会修改多次记录而并没有进行下发，只是调用dc的保存接口将消息进行保存，此时通过traceid可以查询到该记录所有克隆状态的消息。 通过K8S将DC服务部署到三台服务器，便于之后的灰度发布、扩容服务等操作。

该项目基于springboot所开发，分成 ● investment-service ● investment-account-service ● product-service ● wm-ops-service(前端，定时任务等必须调用该服务与其他服务进行交互) ● fx-service ● t24-service 使用postsql数据库，redis，操作数据库使用jpa（jpql,原生查询语句） ，本人所开发的是客户购买基金进行投资获取收益的功能，具体描述如下： 客户登录app后，在wealth一栏，可以进行下单购买基金，下单购买基金时选取相应的产品，目前只提供6个产品，该产品来自于（安联基金提供,调用的第三方提供的fnz-service），选好之后，下一步，就要设置月供资金数额，及设置目标值，目标值是设置最终想要达成的资金收益，然后进行确认买入（购买买入时investment-service服务里做的处理是需要该基金的portfolio_code通过product-service获取到对应的产品编号，通过fnz-service服务获取对应的产品此时的价格，此时使用客户customerId传到investment-account-service服务,该服务会调用t24服务获取客户账号的余额，由于该客户的资金是美元，需要将其进行兑换为港币，调用fx-service进行货币兑换，fx-service服务其实是去通过渣打银行提供的scb接口进行货币兑换，若是在工作日则进行兑换并返回相应港币，若不是工作日，则返回下一个工作日给该基金单进行标识，通过定时任务去执行），此时该基金单状态为placed状态；买入后，客户还需要在另一端portal，即web端上传基金文件，上传后会有审核员进行审核，审核通过后，该客户购买的基金状态就为on_track状态，等到本月底最后一天晚上（香港时间）9点进行定时任务更新所有的基金单状态，基金单状态分别有以下状态： ● placed ● on_track ● off_track ● completed ● achieved ，当定时任务（定时任务是airflow执行）执行时，会通过wm-ops-service，去调用investment-service服务获取on_track,off_track,achieved状态的单做以下处理，若在目标时间内达成客户所设立目标值，则更新为achieved状态；若在目标时间内未达成目标值，则为completed状态；若通过fnz-servie服务获取到的success_rate小于50，则为off_track，大于50则为on_track； 上述是买入操作，还有卖出操作： 当客户买入成功后，可以编辑该单做卖出处理或改变月供，目标值等处理，这里描述下卖出操作： 当客户选择卖出操作时，可以选择全卖还是部分卖出，若全卖，则后台通过该单的portfolio_code给product-service服务获取到此时的对应的产品价格，与买入的操作相同，若部分卖出，则跟此也基本相似； 客户还会有取消操作： 当客户取消该单时，也会通过每天的定时任务来批量处理这些单，通过消息队列进行处理，处理完成后，该订单状态更新为off_track。 这里的消息队列使用的是solace平台，这些服务部署在k8s上，使用Rauther可视化进行查看每个服务的pod情况。 预期效果满足客户购买基金，卖出基金的操作处理