秒杀系统架构设计，教你画好架构图！
泪目，不堪回首！
博主毕业了，最近秋招开始了，每次回想起自己的秋招，都感觉到当时自己特别的可惜（）,自己当时简历上面的项目，只有一个 ,当时的秒杀系统还没有那么普及（简历人均）。
第一次微众面试
当年自己的八股文背的其实还可以，但是自己的项目就只是一个单机系统，？ ？ 什么玩意？,还记得当时，是，在一个酒店房间，面试官笑嘻嘻的看着我，说让我先画一下我项目里面的， 我脑子嗡嗡叫，啥？ 咋画， 就一个，一个，和一个？
大概长这样子
我擦，这也太了吧， 我是不是该画复杂一点？ 或者说，我这个能叫吗？就这样，犹豫之间，毛线都没有画出来... 我记得当时好像画了个这样子的玩意。。 毫无意外的，嗝屁了～
这玩意有点四不像，不说了，丢脸～
第二次微众面试
第二次，毕业有快一年了，抱着试一下的心态，找了个内推, 那时候我在干啥呢，在搞爬虫。公司离微众比较近，就在那边,下班了溜过去，跟面试官吧啦了一会，好家伙，没一会就掏出了一张纸：
来画一下你们现在这个爬虫系统的架构图！
当时系统的长这样吧， 比上面的看起来还简单一点。
但是，我就是画不出手啊！！！ 心里想着太简单了啊！！ 这玩意能叫吗？
摊牌了， 我不会画！
现在想起来，真的太了，年轻啊！ 那如果现在来回头看的话，能怎么画呢？
单体系统的部署架构图
爬虫系统的分层架构图
爬虫系统的业务架构
架构图
从上面的各个方向描述架构来看，其实即使是 也能够画出不一般的架构图！（为啥当时我就不会呢！）
最近在看架构相关的内容（），在4+1 视图里面，从多方面描述了我们的系统，可以参考下面的描述，
你的秒杀系统，架构是怎么样的？
单体系统
不管你们简历吹的多牛逼，我猜你们的服务，大部分都是长这个样子的，, 只有是分布式的。
那我该如何去描述我的单体系统呢？
架构设计的三大原则：
每一条原则都符合我们大学做的秒杀系统啊！！
： 一个系统就可以满足我们秒杀服务的所有动作，没有太多的中间件依赖
：在我们的实践项目中，单体系统是最适合不过的了。（主要是没钱啊！拆分服务，引入中间件，部署集群，都得钱啊！）
：这个比较好理解，没有什么系统架构是一出生就定下来的，是随着时间，业务需求，不断演变出来的。
总结：
我们架构的优势： ，，，
劣势： ，，等
在梳理架构时，每个方案都有他的优势和缺点，所以需要了解你目前方案的优缺点。才能更好的向面试官展示你的系统！
服务拆分
好家伙，参加了个科创比赛，到位了，能买了，那不得将服务优化一下，拆分个微服务系统出来！
在这个服务拆分的架构中，我们做了哪些动作？
静态资源隔离（）
代理服务器（）
服务拆分，应用独立部署
服务rpc通信 （）
1、前后端分离
在单体系统中，我们的静态资源（）可能都是通过我们服务端进行返回，存在的问题是：
前端成本比较高（全栈开发成本也高）
前端代码发布，需要整个系统进行发布
服务器，占用等
那么通过前后端分离所带来的好处就很明显了：
代码独立维护（）,发布成本低()
前后端通过接口交互
访问加速,减少后端服务压力（）
2、反向代理
的作用比较明显， 由于我们服务拆分成多个，那么我们和进行交互时，需要提供一个通用的。而这个入口，就是我们的()。 例如： 服务域名： ，根据restful规范，我们可以通过 将请求转发到 的登录接口中。
3.进程间通信
随着服务的拆分，在部分功能的实现上，就会涉及到的情况，例如：
在常见的实现方案上，我们会采用 和 ,来实现这一能力。而我们比较常用的实现方案就是 。
为什么要使用 RPC 框架？
当我们提到使用 的时候，是否有去思考过， 每个服务提供 接口，不是也能够完成服务间通信吗？
这里就需要进行对比 和 的区别了:
： 简化了传输协议中一些必要的头部信息，从而加快了传输效率。
：例如 框架，封装好了服务间调用的逻辑(如：，和等)，只需要开发相应的和即可。
: 在分布式场景下，我们的服务提供者不止一台，那么就涉及到 ，和等情况需要处理，而这部分能力在 的架构下，都已经满足了。
说完优点后，再来分析一下，:
： 相较于 而言， 框架在跨语言的场景下实现比较困难。并且比较强。服务脱离了当前后，无法正常提供服务,迁移成本高。
： 更适合内网传输，在公网环境下，显得没那么安全。
分布式微服务
在上一个版本的中, 我们根据不同的，,划分出了多个,而针对不同的系统，他所承受的是不一样的，例如： 的每个请求处理（其他服务压力不大），为了挺升我们的下单量，我们可以只扩容即可,这就是我们在服务拆分所带来的，性能使用率提升！
从上面的图我们可以看到，有些服务出现了不同的重影，每一个,可以理解为一台,在这个架构中， 为了保证我们的下单成功率，以及下单量，我们主要将服务器集中在了。
除此之前，再来看看我们的集群部署：
： 读写分离，减轻主库压力，确保数据能正常写入，保障订单数据落库.
： 保障注册中心可用，避免导致全链路雪崩。
： 避免宕机导致大流量直接打到数据库中。
小结
到这里为止，一般我们自己开发的系统，也就基本完成了整个的演进了。可能大伙一直有个疑问，为什么少了我们最熟悉的呢？
在整个调用链路中，我都是以的方式去讲述这一个秒杀系统的架构,因为这个已经满足我们当前的流量诉求了，在里面，提到的，，和。在当前满足流量需求的情况下，我们需要先思考引入消息中间件，带来的问题是什么？ 解决的问题又是什么？ 在权衡利弊后，才是我们决策是否要使用这个方案的时候。
高性能
在上述架构演进的过程中，我们通过，，等方式,提升了我们架构的和,对于我们自研阶段的已经是足够满足我们的流量诉求了，但如果我们想继续优化我们的系统，提升服务性能，可以从以下几个方面进行优化：
资源预热
缓存预热
异步调用
1、资源预热
在上面的阶段, 我们就提到了, 这里的静态资源包括： 等。我们活动阶段，可以通过后台管理系统，将商品服务中的活动的静态资源到CDN，的访问。
资源预热： 通过预先将资源加载到CDN
回源： CDN找不到资源后，会触发源站（商品服务）调用，进行查询对应资源，如果源站存在该资源，则会返回到CDN中进行缓存。
OSS： 实际存储静态资源的服务（可参考阿里云OSS）
上面有反复提到，引入一个技术的时候，需要同时考虑它所带来的，那么 是什么呢？
: 比较直接，就是得多花钱！
： 在大流量的访问下， CDN 是否能支撑那么多的带宽，每个服务器能支撑的流量是有限的，需要考虑CDN是否能支撑业务的访问量。
: 在CDN命中率低的情况下，比如,每一个小时都会发生改变，那么每次图片的替换，都会触发,这时候的资源访问效率反而有所下降。
2、缓存预热
与上面的相对比，则需要通过进行性能上的优化，老生常谈，为什么 那么快？
单线程（redis的性能瓶颈并不在这，所以这个不算优势）
引入 带来的风险主要有:
宕机： 单机部署的情况下，会导致大量的服务调用超时，最终引起服务雪崩。可通过优化。
：大流量下，和等情况，会导致请求穿透到数据库，如果数据库扛不住压力，会造成服务雪崩。可以通过 进行优化。
： 的数据一致性问题，需要通过更新策略进行保障。
3、异步调用
通过异步的方式，将减库存成功的用户，通过消息的方式，发送给订单服务，进行后续的下单操作。可以在短时间内，将所有的商品销售出去。整体的流程如下图所示：
异步调用为什么能过提升我们服务的呢？
主要原因在于，通过异步调用的方式，我们将消息投递过去了，就完成了这一次的请求处理，那么性能的瓶颈，由订单服务，转移到了秒杀服务这里。通过减少调用依赖，从而提升了整体服务的吞吐量。
带来的常见问题：
：由于生产者重复投递消息，或者消费缓慢导致重复推送消息。需要通过加锁，消费幂等来保证消费正常。
： 生产能力远大于消费能力情况下，会导致消息堆积。
：MQ宕机的情况下，需要支持同步调用切换。
这里不做详细介绍，后面会专门写一篇。
高可用
能看到这里真不容易，感谢大家的支持。关于可用性这里，之前有写过一篇 感兴趣可以看一下。
高可用主要可以从：
同城双活
部署在同一个城市不同区的机房，用专用网络连接。两个机房距离一般就是，网络传输速度几乎和同一个机房相同，。
这个模式无法解决极端的灾难情况，例如某个城市的，此方式是用来解决一些的，例如机房的。
异地多活
在上述模式中，没办法解决城市级别的服务容灾，比如，等情。而通过异地多活的部署方案，则可以解决这种问题。
但是每个方案都是存在利和弊的，那么异地多活的弊端主要体现在和的问题上!
跨城异地主要问题就是网络传输延迟，例如北京到广州，正常情况下的RTT（Round-Trip Time 往返时延）是50毫秒，
当遇到网络波动等情况，会升到500毫秒甚至1秒，而且会有丢包问题。
物理距离必然导致数据不一致，这就得从“数据”特性来解决，
如果是强一致性要求的数据（如存款余额），就无法做异地多活。
点关注，不迷路
好了各位，以上就是这篇文章的全部内容了，我后面会每周都更新几篇高质量的大厂面试和常用技术栈相关的文章。感谢大伙能看到这里，如果这个文章写得还不错， 求三连！！！ 感谢各位的支持和认可，我们下篇文章见！
我是 ,有需要交流的童鞋可以关注公众号：，掌握第一手资料！ 如果本篇博客有任何错误，请批评指教，不胜感激 ！