文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

面试官:你给我画一下秒杀系统的架构图!

2024-12-02 23:35

关注

泪目,不堪回首!

博主毕业4年了,最近秋招开始了,每次回想起自己的秋招,都感觉到当时自己特别的可惜(菜是原罪),自己当时简历上面的项目,只有一个 农资电商平台,当时的秒杀系统还没有那么普及(简历人均秒杀系统)。

第一次微众面试

当年自己的八股文背的其实还可以,但是自己的项目就只是一个单机系统,分布式?微服务?什么玩意?,还记得当时微众面试,是二面,在一个酒店房间,面试官笑嘻嘻的看着我,说让我先画一下我项目里面的农资电商平台, 我脑子嗡嗡叫,啥?咋画, 就一个安卓系统,一个前端页面,和一个后台系统?

大概长这样子

我擦,这也太简单了吧, 我是不是该画复杂一点? 或者说,我这个能叫架构吗?就这样,犹豫之间,毛线都没有画出来... 我记得当时好像画了个这样子的玩意。。毫无意外的,嗝屁了~

这玩意有点四不像,不说了,丢脸~

第二次微众面试

第二次微众面试,毕业有快一年了,抱着试一下的心态,找了个师姐内推, 那时候我在干啥呢,在搞爬虫。公司离微众比较近,就在金蝶那边,下班了溜过去,跟面试官吧啦了一会八股文,好家伙,没一会就掏出了一张纸:

来画一下你们现在这个爬虫系统的架构图!

当时系统的部署架构长这样吧, 比上面的看起来还简单一点。

但是,我就是画不出手啊!!!心里想着太简单了啊!!这玩意能叫架构吗?

摊牌了, 我不会画!

现在想起来,真的太憋屈了,年轻啊!那如果现在来回头看的话,能怎么画呢?

单体系统的部署架构图

爬虫系统的分层架构图

爬虫系统的业务架构

架构图

从上面的各个方向描述架构来看,其实即使是单体系统 也能够画出不一般的架构图!(为啥当时我就不会呢!)

最近在看架构相关的内容(华仔的课),在4+1 视图里面,从多方面描述了我们的系统,可以参考下面的描述,

你的秒杀系统,架构是怎么样的?

单体系统

不管你们简历吹的多牛逼,我猜你们的服务,大部分都是长这个样子的,猜对的话点个关注, 只有浏览器是分布式的。

那我该如何去描述我的单体系统呢?

架构设计的三大原则:

每一条原则都符合我们大学做的秒杀系统啊!!

简单原则:一个系统就可以满足我们秒杀服务的所有动作,没有太多的中间件依赖

合适原则:在我们的实践项目中,单体系统是最适合不过的了。(主要是没钱啊!拆分服务,引入中间件,部署集群,都得钱啊!)

演进原则:这个比较好理解,没有什么系统架构是一出生就定下来的,是随着时间,业务需求,不断演变出来的。

总结:

我们架构的优势: 成本低,系统复杂度低,维护成本低,快速定位问题

劣势:稳定性差,并发量低,扩展性弱等

在梳理架构时,每个方案都有他的优势和缺点,所以需要了解你目前方案的优缺点。才能更好的向面试官展示你的系统!

服务拆分

好家伙,参加了个科创比赛,资金到位了,能买更多机器了,那不得将服务优化一下,拆分个微服务系统出来!

在这个服务拆分的架构中,我们做了哪些动作?

1、前后端分离

在单体系统中,我们的静态资源(Html,JS,CSS 和 IMG)可能都是通过我们服务端进行返回,存在的问题是:

前端代码维护成本比较高(全栈开发成本也高)

前端代码发布,需要整个系统进行发布

服务器带宽,请求资源占用等

那么通过前后端分离所带来的好处就很明显了:

代码独立维护(低耦合),发布成本低(高效率)

前后端通过接口交互动态数据

CDN资源访问加速,减少后端服务压力(高性能)

2、反向代理

反向代理的作用比较明显, 由于我们服务拆分成多个,那么我们和前端进行交互时,需要提供一个通用的入口。而这个入口,就是我们的反向代理服务器(Nginx)。例如:服务域名:https://www.jiuling.com ,根据restful规范,我们可以通过 https://www.jiuling.com/user/1.0/login 将请求转发到 用户服务的登录接口中。

3.进程间通信

随着服务的拆分,在部分功能的实现上,就会涉及到服务间相互调用的情况,例如:

在常见的实现方案上,我们会采用 注册中心 和 RPC框架,来实现这一能力。而我们比较常用的实现方案就是 zookeeper & dubbo。

为什么要使用 RPC 框架?

当我们提到使用 RPC框架 的时候,是否有去思考过,为什么要使用 RPC框架? 每个服务提供 RESTful 接口,不是也能够完成服务间通信吗?

这里就需要进行对比 RPC 和 RESTful 的区别了:

说完优点后,再来分析一下,RPC的缺点:

分布式微服务

在上一个版本的服务拆分中, 我们根据不同的业务边界,功能职责,划分出了多个子系统,而针对不同的系统,他所承受的负载压力是不一样的,例如:订单服务的每个请求处理耗时较长(其他服务压力不大),为了挺升我们的下单量,我们可以只扩容订单服务即可,这就是我们在服务拆分所带来的收益,性能使用率提升!

从上面的图我们可以看到,有些服务出现了不同的重影,每一个方块,可以理解为一台机器,在这个架构中, 为了保证我们的下单成功率,以及下单量,我们主要将服务器集中在了订单服务。

除此之前,再来看看我们的中间件集群部署:

小结

到这里为止,一般我们自己开发的系统,也就基本完成了整个秒杀系统的演进了。可能大伙一直有个疑问,为什么少了我们最熟悉的MQ呢?

在整个调用链路中,我都是以同步调用的方式去讲述这一个秒杀系统的架构,因为这个已经满足我们当前的流量诉求了,在架构设计的原则里面,提到的,合适原则,和演进原则。在当前满足流量需求的情况下,我们需要先思考引入消息中间件,带来的问题是什么?解决的问题又是什么?在权衡利弊后,才是我们决策是否要使用这个方案的时候。

高性能

在上述架构演进的过程中,我们通过服务拆分,垂直扩容,分布式部署等方式,提升了我们架构的性能和稳定性,对于我们自研阶段的架构演进已经是足够满足我们的流量诉求了,但如果我们想继续优化我们的系统,提升服务性能,可以从以下几个方面进行优化:

1、资源预热

在上面的服务拆分阶段, 我们就提到了资源动静分离, 这里的静态资源包括:html,js,css,img 等。我们活动阶段,可以通过后台管理系统,将商品服务中的活动的静态资源预热到CDN,加速资源的访问。

资源预热: 通过预先将资源加载到CDN
回源:CDN找不到资源后,会触发源站(商品服务)调用,进行查询对应资源,如果源站存在该资源,则会返回到CDN中进行缓存。
OSS: 实际存储静态资源的服务(可参考阿里云OSS)

上面有反复提到,引入一个技术的时候,需要同时考虑它所带来的利和弊,那么 CDN的风险是什么呢?

2、缓存预热

与上面的静态资源加速相对比,动态数据则需要通过缓存进行性能上的优化,老生常谈,为什么redis 那么快?

单线程(redis的性能瓶颈并不在这,所以这个不算优势)

引入 redis 带来的风险主要有:

3、异步调用

通过异步的方式,将减库存成功的用户,通过消息的方式,发送给订单服务,进行后续的下单操作。可以在短时间内,将所有的商品销售出去。整体的流程如下图所示:

MQ异步调用为什么能过提升我们服务的吞吐量呢?

主要原因在于,通过异步调用的方式,我们将消息投递过去了,就完成了这一次的请求处理,那么性能的瓶颈,由订单服务,转移到了秒杀服务这里。通过减少调用依赖,从而提升了整体服务的吞吐量。

MQ 带来的常见问题:

高可用

能看到这里真不容易,感谢大家的支持。关于可用性这里,之前有写过一篇 # 《高可用实战》-B站蹦了,关我A站什么事?感兴趣可以看一下。

高可用主要可以从:

同城双活

部署在同一个城市不同区的机房,用专用网络连接。两个机房距离一般就是几十千米,网络传输速度几乎和同一个机房相同,降低了系统复杂度、成本。

这个模式无法解决极端的灾难情况,例如某个城市的地震、水灾,此方式是用来解决一些常规故障的,例如机房的火灾、停电、空调故障。

异地多活

在上述模式中,没办法解决城市级别的服务容灾,比如水灾,地震等情。而通过异地多活的部署方案,则可以解决这种问题。

但是每个方案都是存在利和弊的,那么异地多活的弊端主要体现在网络传输和数据一致性的问题上!

跨城异地主要问题就是网络传输延迟,例如北京到广州,正常情况下的RTT(Round-Trip Time 往返时延)是50毫秒,
当遇到网络波动等情况,会升到500毫秒甚至1秒,而且会有丢包问题。

物理距离必然导致数据不一致,这就得从“数据”特性来解决,
如果是强一致性要求的数据(如存款余额),就无法做异地多活。

图片地址:draw.io原图


来源:Java补习课内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯