网约车 梳理

整体（图）

项目过程

1. 启动
   背景，为什么做？
   项目的长远考虑？
   项目的特色？

2. 计划
   deadline，项目做不完怎么办？
   加班，加人，功能排优先级（重要的先做且保证能用，后面再迭代）

3. 实施控制
   开发，测试

4. 收尾
   验收。产品验收

项目和产品

团队多少人？
什么管理方式？矩阵式（开发：1组、2组，产品：1组、2组），项目组，抽人组队

项目的流程？
需求分析、kickoff、开发计划和需求评审、需求确认、开发设计、设计评审、测试用例编写、评审、开发、测试、上线
解释：
过一遍需求、需求及其里程碑、开发设计评审、测试用例
开发时是对着产品和测试用例（思维导图）一起编码

沟通不畅怎么办？关键是温和

人员的安排

登陆限制规则

一档限制：
一小时内验证码错误达到3次，限制10分钟后登录
二档限制：
一小时内验证码错误达到5次，限制24小时后登陆
防止恶意发大量短信

实现的需求

乘客端：
发送验证码：三档验证，防止恶意发送短信
登陆/注册
查看开通区域：高德的围栏，轨迹：纠偏
预估价格
下单
支付（分布式事务：订单，支付，积分）
评价

司机端：
发送验证码
登陆/注册
出车
司机抢单（分布式锁）
订单状态变更
发起收款

运营端boss

微服务设计原则

目标：隔离变化点

具体原则：
高内聚，低耦合
每个服务独立
以业务为中心
弹性设计：容错、隔离、降级
自动化：持续集成、持续交付
粒度把控

扛住并发：akf

架构
前端展示层
pc、乘客端、司机端、微信、boss、开放平台
负载层
nginx（软件）、f5（硬件）
网关
鉴权、限流、黑白名单管理
业务层
乘客api、司机api、bossapi、地图api
能力层
用户服务、订单服务、应用更新管理、短信码验证、派单、支付
中间层（贯穿业务层、能力层）
缓存redis、file（oss）、mq
存储
mysql
贯穿始终
日志、权限
运行环境
linux、docker、k8s

用户
nginx集群
zuul/gateway
api-xxx
servicexxx

注册中心eureka
健康检查boot-admin
链路追踪zipkin,sleuth
配置中心config server

拆服务
模块 项目名 描述
乘客端 api-passenger 乘客端
司机端 api-driver 司机端
司机听单 api-listen-order 司机听单

能力
app升级 service-app-update
订单 service-order
派单 service-order-dispatch
乘客用户管理 service-passenger-user
短信 service-sms
计价 service-valuation
验证码 service-verfication-code
钱包 service-wallet
支付 service-payment

spring cloud 基础
注册中心 cloud-eurka
配置中心 cloud-config-server
网关 cloud-zuul
熔断监控 cloud-hystrix-dashboard
健康检查 cloud-admin
链路追踪 cloud-zipkin-ul

基础 common
通用，工具类，校验 common

第三方技术
短信服务
语音服务
文件服务oss
地图：高德
消息推送
支付
查航班
发票

boot cloud maven git mysql redis mq

能力层
qps:2000
有些：300

接口设计

安全
三级等保
幂等
cia：保密性、完整性、可用性

过滤 jsoup
xss

微服务项目结构