架构设计思路-滴答打车

 

一、架构设计

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次,如果再有问题,直接抛出异常,人工介入

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

 

posted @ 2022-04-17 20:33  aspirant  阅读(90)  评论(0编辑  收藏  举报