飞滴出行--以网约车为例，切入分布式项目

 

 以网约车为模板（逸品出行）

 〇、前言

1、今日内容：

需求最重要

 技术为业务赋能

2、明日内容

 

 一、项目须知---国家监管要求

 1、预防做完后悔---------国家监管信息

需要符合技术要求

 

 

 

 

 

 

 

 

 

 计价规则模板/依据

 

 

 

 

 

 政府已经给变量起好名字

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 订单三个状态：发起、成功、取消

 

 驾驶员定位信息---做派单

 

 3秒收集一次司机的位置

评价表信息

 

如CLHP车号牌，公安部（政府项目）与监管平台 

2、好处--做前有参考

 

二、如何写到简历中

1、三要素

需求、解决方案、难点

难点：并发量达到多少qps，需要并发

2、需求分析

车主端

乘客端

车机端：汽车大屏屏

大屏端：副驾驶后面

 

 3、功能列表

 

 4、业务架构图

 

 请求调用DNS/CDN/GAT/LB/网关

服务层：中台--业务中台（新），技术中台，数据中台

 

中台的由来：阿里拆分为25个事业部

 CTO首席技术官，CDO首席数据官

大型数据仓库，收集底层数据，不行---从上往下（从底层）

从下往上：来往app--作为入口（从上层）

 

 逍遥子：从中间层，做商品中心、支付中心、订单中心，起名为中台

如：淘特

中台最成功的：盒马生鲜

中台：对上层通用业务能力的沉淀，以便以后复用

双中台：数据中台、技术中台

现在阿里正在去中台：个性化的东西比较多，比如直播等

中台适合于：组合式创新--利用现有能力组合成一个产品

but：个性化需求多，不适用个性化创新，故去中台--让中台变薄

薄的一层只定义接口，具体实现交给不同的服务

中台：适合组合式创新，不适用于个性化创新，上层通用业务能力的沉淀

去中台：满足不了业务变化的需求，去中台（变小、变薄、变弱、变抽象，相当于一个接口，类似JDBC），抽象成接口、服务，具体的service看具体的业务逻辑

5、微服务的架构设计

接收请求，组合服务

 

 不是每个服务都有CDN，是否需要CDN，看用户量

三、具体介绍

1、服务组成

 

 2、业务层

 

 LBS同步位置

 

 

 

 

 

 免登录

access_token：不需要每次输入手机号密码--如微信，有效期为2小时，包含用户信息及过期时间，推荐使用JWT【好处：去server查询sessionId，无需输入用户名密码，即可】

集群需要对session信息做负载均衡，即共享session，使用JWT，就不需要集群存

refresh_token：加盐的token，进行sal/sha-256加密
https防偷窥/设置过期时间，可以使用refresh_token请求服务重新获取token

给系统发两个token，