架构设计思路-滴答打车

 

一、架构设计

1、首先最外层有一层网关层 mz-gatway ，在网关层 使用霸下等，将异常流量剥离出来

异常流量:1、爬虫，根据IP，如果是代理的话，根据协议头 request header 也可以判断出来

 

2、用户应用层，承接入口流量

包含了登录层设计

使用用户名和密码 登录然后服务端返回sessionId

这里有个问题，那我能否模拟sessionId，其实是可以的，这个没办法控制模拟sessionId，可以使用频次控制，比如某个人最多登录几次，ip，一天最多几次等；

 

3、业务逻辑层

处理用户的业务逻辑信息，核心层

 

4、数据持久层

处理与用户底层的交互设计

DB的交互

这里可以分为两个模块，分为两种情况：

1、访问自己的数据库，不存在超时的问题

2、访问远程的数据库，会存在超时的问题，需要统一处理；是否需要抛出异常，还是自己吃掉异常，不向上层用户透出

 

5、微服务向其他应用提供服务的client 接口层

因为是向其他应用提供，因此需要考虑尽量把引用的包做小，别人引用的时候更轻量，用户不关心他不需要的应用，

实现放在业务逻辑层；

6、预热层

富客户端的数据，专门处理富客户端的数据，放在缓存；

二、缓存设计

1、双缓存设计

在入口层：guava --redis 缓存（guava 如果key一致，则使用分布式事务锁，只允许一个key穿透到redis层）

redis 与数据库DB之前 使用sentinel限流；保护接口；

更新缓存 与数据库放在一个try事务里面；尽量把try做小；

guava的更新，可以考虑发送mq消息的形式；这样会全量更新；

2、常用的稳定数据，比如用户信息，场馆信息等，考虑富客户端设计；

 

三、日志设计

核心链路，异步日志打印，

日志统一，考虑只用手机号，或者用户ID 就可以查询日志；

考虑C端应用，只打印异常日志；

如果异常使用日志上报的形式；专门设计日志监控系统；

四、对于库存超售的设计

首先 不同的应用使用 mq同步消息，做幂等，比如扣减库存把订单号传过来，

然后发消息，这样如果异常的话，可以循环16次，如果再有问题，直接抛出异常，人工介入

然后在系统内部参考：库存回滚架构设计原则