# charging-service

**Repository Path**: binbinroom/charging-service

## Basic Information

- **Project Name**: charging-service
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-09-23
- **Last Updated**: 2026-01-29

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# charging-service

#### 服务与服务、数据之间用DTO(数据传输)
#### 服务与前端之间用param(更新和创建的时候传参会使用)
#### VO(页面展示的时候用)
#### PO(数据库)

一.RestFul 定义接口的一个规范 ， 基于http方法 Get POST PUT DELETE HEAD
订单
获取订单详情  Get /order/
删除订单     Del /order/

### Get  查询
### Post 更新 新增 删除
* 获取订单详情 Get  /order/{id}      或者   /order?orderId=?
* 删除订单  Post   /order/del/{id}/  或者    /del/order/{id}
* 创建订单  Post   /order/add/{id}   或者    /add/order/{id}
* 更新订单  Post   /order/update/{id}  或者   /update/order/{id}

1. @PostMapping("create")   更新
2. @PutMapping("")   新
3. GetMapping("")    读
4. DeleteMapping("") 删


二.梳理充电桩的业务
1. 搜索附近的充电站
    1.1 距离最近 我当前**位置**(地图获取当前用户的位置信息)   uniapp 位置信息对接 三方地图，距离的计算
    1.2 充电站详情：帮助用户做决策是否愿意来这个充电站充电（用户考虑的因素：价格、电费、充电桩的类型[快充、慢充]、充电时长、距离[按照距离排序]、充电桩的状态[空闲、使用中、故障]、
        充电站的状态[营业中、未营业（在地图上显示状态未营业）]、充电桩的评分[按照评分排序]、充电桩的评价[按照评价排序]、充电桩的图片[按照图片排序]、充电桩的营业时间[按照营业时间排序]、充电桩的、营销促销活动、
        设备信息、周边的配套信息、用户评价）
2. 导航过去
    2.1 对接导航软件
3. 充电
    3.1 先插枪 再扫码
4. 设备上扫码 开始充电
    4.1 二维码 扫过后会发生什么事情？
        4.1.1 用户验证，验证用户是否注册过，如果注册过，登录；如果没有注册过，先注册，后登陆
        4.1.2 充电
    4.2 如何设计这个二维码？
    4.3 码的图片本身包含了什么信息？
        4.3.1 请求地址：http://order/create?pileId=1&gunId=1
        4.3.2 设备信息：json{"pileId":1,"gunId":1}
        4.3.3 获取设备的json信息，通过**扫码获得的设备信息和用户信息（本地存储）登录的时候调用登录接口，登录接口返回用户id，把用户id存储到本地存储**去调用 创建订单接口
   5. 下单
       5.1 查询场站信息和设备信息
       5.2 获取用户车辆信息
       5.3 生成订单号
       5.3 给设备发送开始充电指令
       5.4 修改充电桩的状态为 使用中
       5.4 立即创建订单记录** （结论）
               开始充电的时候，创建订单记录，点击开始充电按钮，创建一条订单记录
               如何定义开始充电？
                设备自检后，会告诉订单服务，一条订单记录，开始真正的充电
                订单服务：告诉 设备开始充电给设备发送开始充电指令，设备接收到开始充电指令后，给订单服务返回响应，开始充电成功，数据库插入记录
                {
                    "订单号": "123"
                    "指令":"开始充电"
                }
                {
                    "订单号"："11111"
                    "指令":"开始充电成功/失败"
                }
       5.5 付款？
           5.5.1 先付款 再充电（推荐）
                   先充钱(充值卡)，再充电
                   充钱可以扩展营销活动
                   例子：先充了200元，充电的过程中，余额不足，该怎么处理？
                       提醒用户，停止充电，因为用户大概率知道本次充电需要多少钱
           5.5.2 信用分(对接第三方渠道，支付宝或者微信)平台积分，先充电 再付款(先享后付)
                   先使用，后付款，如果用了，不支付(没钱)，该如何处理？
                   1.免密支付 和支付平台 签署 协议
                   2.下次再充电，必须支付上次未支付的订单
                       影响信用分，上传失信记录，拉入黑名单
                       优点：简单  缺点：赔钱
        

# Feign的执行流程
订单服务 注册中心 用户服务
## 订单服务，通过 feign 和 注册中心 调用 用户服务
1. 订单服务的 启动类 chargingOrderApplication 增加 @EnableFeignClients 注解
2. 订单服务的 UserClient 接口中增加 @FeignClient 注解 并且指定服务名称 userService
3. 此时 Spring-boot 启动的时候，会自动扫描类路径 cn.tedu 下所有 加了 @FeignClient 的接口
4. 扫描到了UserClient这个接口，根据@FeignClient("userService")获取到userService这个服务名称
5. 通过userService服务名称 去 注册中心(nacos)获取userService对应的服务列表
            ip     端口号
          localhost  8080
          localhost  8081
          localhost  8082
6. 业务调用：OrderServiceImpl 注入 UserClient @Autowired private UserClient userClient; OrderServiceImpl使用getUserInfoByUserId的方法，通过调用userClient.getUserCarInfo(userId);
7. 具体调用:
* 获取UserClient接口中的getUserCarInfo的注解
  * @GetMapping("/user/info/{userId}")得到接口地址 /user/info/{userId}
  * @PathVariable("userId") 得到入参 userId
8. 地址拼接  http://userService/user/info/{userId}
9. 通过负载均衡 loadbalancer 从userService对应的 服务列表里 选取一个服务地址 localhost 8081 地址的拼接就变成 http://localhost:8081/user/info/{userId}
10. 序列化入参 对象转为Json
11. 通过HttpClient 访问http的客户端 http://localhost:8081/user/info/123
12. 返回结果Json反序列化为对象 返回

> 思考 获取服务列表的时机？
>>  A.启动的时候？ 优点：提前准备好，在业务调用之前就准备好，调用的时候，直接用，理论上调用的时候速度快  缺点：启动慢 10个client 意味着10个服务名，项目启动时，需要查询10次服务名对应的服务列表，占用内存，获取的服务列表会占用内存空间
>>>  B.业务调用的时候？ 优点：占用内存相对较少，用的时候再获取  缺点：业务调用的时候再通过服务名称获取服务列表需要消耗时间，会导致业务调用的总体耗时增加
>>>> 结论：默认采用的是B方案，可以通过参数配置的方式修改为A