东东
发布于 2022-11-23 / 76 阅读 / 0 评论 / 0 点赞

宇通工作总结

入职

18年6月底,参加完毕业典礼,就打包收拾东西离开了福州,回想14年入学时第一个入住宿舍,到如今又是第一个离开宿舍,四年大学时光匆匆而过。
简单收拾行李前往郑州,在发小处借宿一晚,第二天一大早乘坐地铁到了西流湖站,正式开始迎接宇通生活。
地铁口已经有对应的大巴车在等候,确认了身份后上车找了位置继续等待。
陆陆续续满座后,大巴车启动,宇通生活的第一站是在郑州西郊荥阳的一所大学校园内进行为期两周的军训。
公司提供拎包入住的服务,宿舍内是八人间上下铺,一下子好像又回到了校园。

此处先不多写,具体见视频吧

车间实习

部门入职

运营平台-运营管理服务的迁移

将老服务功能迁移到新服务中,涉及一下几个工作

  1. 梳理待迁移的业务:了解有哪些功能需要迁移,安排好工作的优先级,规划好迁移的顺序及进度
  2. 业务流程梳理:每一项业务需要梳理业务逻辑、数据项来源、统计规则等相关细节
  3. 表迁移:用Geenplum表替代原有的Oracle表,需要做新表结构设计、分区设计
  4. 代码迁移:基于老项目的业务代码进行重构优化,以及sql的改写适配等工作

新能源监控平台-测试bug修改

新能源平台项目改造完成后,在自测阶段有相当大量的bug待修复,抽调去承接修改bug的工作

  1. 从bug入手熟悉代码,熟悉业务。

运营平台

双写

原因

历史遗留问题,新老系统并行,新架构使用mysql,老架构使用Oracle

  1. 由于上层业务分支复杂,部分业务没有资源启动迁移改造,只能使用老架构,而新增业务则是需要在新架构中开发。
  2. 业务之间对数据的使用又存在交叉,需要保证此类数据两个系统要一致
  3. 原来设计的同步程序在数据实时性上性能较差

工作内容:

  1. 改造老系统原有功能,在数据入库后启动一个线程实时处理数据,将数据直接写入新系统中
  2. 写入失败后记录要进行记录,失败表中要包含对应数据的主键、对应的数据类型、操作类型、具体的调用参数等信息。
  3. 失败记录表中的数据,要有一个监听程序及时处理,当出现失败数据后,及时按照记录的信息进行重试。
  4. 在运行一段时间后,发现双写程序维护频繁,功能直接嵌入在老系统中,且其他服务中也有双写需求,维护麻烦。于是需要将双写功能单独形成一个微服务,这样其他服务有双写需求的时候直接引入api,所有的双写请求统一处理。

技术

  1. 远程调用采用的feign的方式,服务注册在nacos上向外提供。
  2. 服务本身采用SSM框架开发。
  3. 失败处理服务采用elastic-job框架做定时任务
  4. 监控程序则采用zabbix监控失败表数据在控制台告警并关联发送邮件给对应开发

终端升级

  1. 手动升级
  2. 批量同版本升级
  3. 批量不同版本升级
  4. 定时升级
  5. 强制升级

终端协议配置

背景

  1. 一辆车可能会装配好几个终端用来处理不同类型的数据,但是每个终端要处理的数据类型是通过给终端配置哪些协议决定的,并且协议的配置是随着终端所处车辆关联的业务变化
  2. 原有的终端协议配置功能适用性窄,在协议配置环境比较稳定的时候比较适用
  3. 后续协议配置的策略有新增也有变化,原来的功能代码就需要不断改造,扩展性比较差。

解决方案

  1. 先搞清楚协议配置是由哪些因素引起的变化,把对应的这些属性抽取出来形成一个策略类
  2. 新增一个策略类和协议之间的配置功能,支持策略的修改以及策略对应协议的修改
  3. 改造代码,首先是根据一些基本数据判断所属的策略,然后再统一进行协议配置。
  4. 后续维护的过程中只需要修改策略的判断代码即可。

远程参数配置

  1. 配置化改造
  2. 导入配置、导入待升级终端
  3. 根据导入文件的信息通过程序自动组装每辆终端对应的升级命令

车辆元数据同步

功能背景

  1. 车辆有很多配置信息、订单信息都是在生产系统、销售系统中
  2. 车联网部门将车辆基本数据接入后,需要进一步获取这些扩展数据
  3. 原有的功能设计师每天同步昨天新增数据、每周同步所有车辆的数据,通过车联网部门主动去请求其他系统获取数据
  4. 但是随着车辆数的不断增长到目前一共几十万的车辆,每周进行同步时会相当耗费资源,其他系统为了自身稳定,直接采用了限流,导致车联网这边同步功能经常不能正常完成
  5. 导致单车需要这些数据的时候还是要再次主动请求获取一下来保证数据完整性

解决方案

  1. 首先了解一下这些扩展数据都有哪几种,向对应的车间部门调研一下这些数据的变更情况
  2. 调研车辆生产下线的业务流程,了解车辆数据在进入车联网系统的前后,对应扩展数据的变化情况
  3. 沟通新的数据传输模式,由其他系统在合适的时间主动推送到车联网系统
  4. 车联网系统提供一个接口服务,将其他系统传递的数据放入到mq中,由对应的服务收到后进行分类处理
  5. 频率修改为每天增量推送,把已经接入车联网系统或可能接入车联网系统的数据都推送
  6. 效果极大缓解了双方的压力,而且在数据完整性上也有了保证。