面试官，你好。我叫XXX，毕业于东北大学信息管理与信息系统专业，现在就职于哈啰出行。目前是哈啰打车乘客端的技术PM，技术PM就是把控技整体术方案和项目进度的角色，同时也要参与coding。刚入职哈啰的时候在电动车部门，参与B端服务迭代开发和稳定性维护，主导了数据库隔离、服务拆分和接口优化的工作。去年下半年公司成立了S级项目哈啰打车，就被调到普惠用车了，进行了历时两个多月的封闭式开发，见证了打车业务从0-1的过程。主导乘客端日常迭代，带领团队做了打车业务层架构重构和特价车专项。上一家公司是沐融科技，是校招进入的一家支付公司，在职期间负责收单、支付和内部对账的开发，连续两年获得优秀员工称号。
项目介绍 讲一下哈啰打车的核心链路，发单->如果预付先支付->接单->到达乘客上车起点->接到乘客->到达目的地->后付支付->没付催收。 发单会做核心服务 进行开城，路程，发单和取消次数，黑名单，优惠决策和风控，价格核对，预后付决策校验，子业务特有的校验，如果没问题就发到行程服务，行程服务落库并同步通知交易平台生成交易单，存储价格快照。然后发送mq到abnormal服务，进行发单风控和敏感地址校验。如果校验通过，rpc回调到行程服务，通知匹配系统，并发送行程变更消息，其他服务可以做处理。匹配系统进行派单或者落选单大厅。派单会通过tcp通知到移动端车主界面，车主可以点击接单，点击接单在行程服务在动作加锁以后，会对乘客单 单独加锁，生成车主单，异步更改交易状态，通知交易失败会使用延迟队列做重试。后面流程动作加锁后，对乘客，车主单双层加锁。最后到达目的地，会在payment有个补偿，如果行程状态和交易状态不同步，则补偿前面步骤更新交易状态。然后会mq调用风控，延迟消息，十分钟回查风控。如果风控通过，则通知清结算。
特价车专项提出了子业务类型的概念，之前的打车就是快车，特价车是价格对乘客友好，司机只能选单，不能派单。和移动端的交互有些不一样。
打车业务层重构是我带领了三个同级同事一起做的，四个人做了两个月。做了五件事情吧，一是架构做了大的调整，原来业务层是分为司机、乘客两个服务，现在整理了接口，变成了核心和非核心两个服务，核心里放跟行程单相关的主链路，不影响行程单的和App的交互都放在了非核心服务；二是，跟团队同学一起协商决定了一套新的代码规范，并且落地，把服务里的模块分的更细了，之前只有iface,service，现在增加了facade，event，domian，core层，因为发现之前代码随着时间的推移，有些同学没有照着之前约定的包来用，比如facade的调用其他服务的防腐层，会有同学写业务逻辑在里面，一写写了一两千行，直接做成模块后，内部模块会有依赖关系，写之前就会思考放的位置是否合理。三是收到监听的后处理进行了重构，之前是司机、乘客服务同时接收行程变更消息，来做操作。现在是一个consumer接收消息，起了个线程池，把收到的消息copy出来两份，分别给到乘客和司机的消息分发器，再根据messageType来分发到handler处理。四是之前后处理里的消息触达很乱，消息触达就是App推送，支付宝、微信小程序提醒，短信之类的，这个收口是我们一起过的方案，其中的同事做的。五是设计了一套平滑灰度切流方案，关于接口是写了个注解从老服务切流到新服务，切流策略配置在apollo。会有白名单，然后可以切到0.1%的流量粒度，根据用户号来切。mq的话归了三种情况，一种是本身的延迟消息，不需要切，一种是外部系统长远设计来看会更换topic的，直接在外部系统用apollo规则切。第三种就是topic保持不变，新老consumer同时消费。这样的话会出现重复消费或者都丢弃的情况，所以取了个巧，在发单时埋了个行程单维度的灰度标记，临时共用这个redis集群，贯穿这个订单生命周期的mq消息要么走新服务，要么走老服务。切流分批切流。切好了之后，网关三个一批，换成新服务的网关。然后观察老服务这些接口还有没有流量。如果半个月没流量，就下掉，不然找到源头，再继续切。 这个方案后边顺风车迁非核心服务也用到了。
数据库拆分是19年做的，总共有100多张表，当时按域梳理向合伙人，门店，各种工单，投放点等偏B端的40张表放到了新库。是使用Spring提供的AbstractRoutingDataSource，重写了方法determineCurrentLookupKey，塞入我通过apollo控制的数据源。难点在于说领域的划分吧，比如车辆表就很有争议，从用户维度他是商品，从商家维度他是资产。后来是先放在了C端库。
， 项目难点
职业规划
最近在看什么书
你有什么问题要问我
