前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >那一天,我回想起被微众碾压的架构问题!

那一天,我回想起被微众碾压的架构问题!

作者头像
九灵
发布于 2021-08-10 02:34:50
发布于 2021-08-10 02:34:50
62400
代码可运行
举报
文章被收录于专栏:JaycekonJaycekon
运行总次数:0
代码可运行

泪目,不堪回首!

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

第一次微众面试

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

大概长这样子

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
这玩意有点四不像,不说了,丢脸~

第二次微众面试

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

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

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

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

摊牌了, 我不会画!

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

单体系统的部署架构图

爬虫系统的分层架构图

爬虫系统的业务架构

架构图

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

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

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

单体系统

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

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

架构设计的三大原则:

  • 简单原则
  • 合适原则
  • 演进原则

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

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

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

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

总结:

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

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

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

服务拆分

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

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

  • 静态资源隔离(CDN加速
  • 代理服务器Nginx
  • 服务拆分,应用独立部署
  • 服务rpc通信 (rpc框架 & 注册中心
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 接口,不是也能够完成服务间通信吗?

这里就需要进行对比 RPCRESTful 的区别了:

  • 数据报文小&传输效率快RPC简化了传输协议中一些必要的头部信息,从而加快了传输效率。
  • 开发成本低:例如 Dubbo框架,封装好了服务间调用的逻辑(如:反射建连超时控制等),只需要开发相应的接口数据模型即可。
  • 服务治理: 在分布式场景下,我们的服务提供者不止一台,那么就涉及到 服务健康负载均衡服务流控等情况需要处理,而这部分能力在rpc & 注册中心 的架构下,都已经满足了。

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

  • 耦合性强: 相较于 RESTful而言,RPC 框架在跨语言的场景下实现比较困难。并且版本依赖比较强。服务脱离了当前内网环境后,无法正常提供服务,迁移成本高。
  • 内网调用RPC更适合内网传输,在公网环境下,显得没那么安全。

分布式微服务

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

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

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

  • mysql 主从架构: 读写分离,减轻主库压力,确保数据能正常写入,保障订单数据落库.
  • zookeeper 主从架构: 保障注册中心可用,避免导致全链路雪崩。
  • redis 哨兵集群: 避免redis宕机导致大流量直接打到数据库中。

小结

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

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

高性能

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

  • 资源预热
  • 缓存预热
  • 异步调用
1、资源预热

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

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

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

  • 成本 : 比较直接,就是得多花钱!
  • 带宽 : 在大流量的访问下, CDN 是否能支撑那么多的带宽,每个服务器能支撑的流量是有限的,需要考虑CDN是否能支撑业务的访问量。
  • CDN命中率: 在CDN命中率低的情况下,比如活动图片,每一个小时都会发生改变,那么每次图片的替换,都会触发回源操作,这时候的资源访问效率反而有所下降。
2、缓存预热

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

  • 单线程(redis的性能瓶颈并不在这,所以这个不算优势)
  • 多路I/O复用模型
  • 数据结构简单
  • 基于内存操作

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

  • reids 宕机: 单机部署的情况下,会导致大量的服务调用超时,最终引起服务雪崩。可通过Sentinel集群优化。
  • 缓存击穿:大流量下,缓存MISS缓存过期等情况,会导致请求穿透到数据库,如果数据库扛不住压力,会造成服务雪崩。可以通过 布隆过滤器进行优化。
  • 数据一致性缓存数据与DB数据一致性问题,需要通过更新策略进行保障。
3、异步调用

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

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

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

MQ 带来的常见问题:

  • 数据一致性
  • 重复消费:由于生产者重复投递消息,或者消费缓慢导致重复推送消息。需要通过加锁,消费幂等来保证消费正常。
  • 消息堆积: 生产能力远大于消费能力情况下,会导致消息堆积。
  • MQ可用性:MQ宕机的情况下,需要支持同步调用切换。

这里不做详细介绍,后面会专门写一篇MQ相关的文章

高可用

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

高可用主要可以从:

同城双活

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

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

异地多活

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

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

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
跨城异地主要问题就是网络传输延迟,例如北京到广州,正常情况下的RTT(Round-Trip Time 往返时延)是50毫秒,
当遇到网络波动等情况,会升到500毫秒甚至1秒,而且会有丢包问题。

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

点关注,不迷路

图片地址:draw.io原图

好了各位,以上就是这篇文章的全部内容了,我后面会每周都更新几篇高质量的大厂面试和常用技术栈相关的文章。感谢大伙能看到这里,如果这个文章写得还不错, 求三连!!! 感谢各位的支持和认可,我们下篇文章见!

我是 九灵 ,有需要交流的童鞋可以 加我wx,Jayce-K,关注公众号:Java 补习课,掌握第一手资料! 如果本篇博客有任何错误,请批评指教,不胜感激 !

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2021-08-05 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
面试官:你给我画一下秒杀系统的架构图!
博主毕业4年了,最近秋招开始了,每次回想起自己的秋招,都感觉到当时自己特别的可惜(菜是原罪),自己当时简历上面的项目,只有一个 农资电商平台,当时的秒杀系统还没有那么普及(简历人均秒杀系统)。
麦洛
2021/08/23
1.1K0
面试官:你给我画一下秒杀系统的架构图!
突围电商大促场景,得物在高可用上的探索与实践 | 卓越技术团队访谈录
采访嘉宾 | 金思宇、陈贞宝、胡强忠 编辑 | 辛晓亮   大型电商系统并非一开始就具有完整设计的高可用特性,而是随着用户的不断增加与业务的快速增长逐步演进与完善的。当前高可用架构体系是互联网企业系统架构的基础要求,随着公司的业务发展,尤其是对于电商平台,每次发生稳定性故障带来的影响越来越大,提供稳定的服务,保证系统的高可用已经变成了整个技术团队需要面对的挑战。 基于此,我们深度采访了得物技术团队核心成员,探索他们在高可用架构上的实践、演进,深入了解大促备战是如何进行的,异地多活体系是如何建设的,全链路
深度学习与Python
2023/03/29
2.1K0
突围电商大促场景,得物在高可用上的探索与实践 | 卓越技术团队访谈录
今天跟大家聊一聊软件架构(图文并茂)
系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。
小熊学Java
2023/07/16
10.7K1
今天跟大家聊一聊软件架构(图文并茂)
历时三年,苏宁如何建设多数据中心多活的实践项目?
随着苏宁线下线上业务以及全产业、全业态规模式快速增长,特别是每年苏宁 818 大促、双 11 等大促节点,销售订单基本都呈现倍数级增长态势,需要进行大量资源扩容,单个数据中心的容量有限,已经无法支撑苏宁业务的快速发展。同时,单数据中心在高可用上存在不足,一旦数据中心发生故障,会导致业务受损,用户访问中断,带来严重的影响。针对以上问题,苏宁规划建设多数据中心解决方案迫在眉睫。
深度学习与Python
2020/11/06
1.7K0
历时三年,苏宁如何建设多数据中心多活的实践项目?
浅谈业务级灾备的架构模式
互联网常见的高可用手段。比如服务冗余部署、异步化设计、负载均衡、服务限流降级熔断、架构拆分、服务治理、分布式存储等等,今天主要是一起聊下,多机房部署的灾备架构模式,来确保服务的高可用。
得物技术
2023/07/06
1.2K0
浅谈业务级灾备的架构模式
追前沿,领略SET化架构衍化与设计
备注:当你再一个cluster钟使用了federation插件,所有在集群中的 nodes都需要安装federation插件
用户1212940
2022/04/13
8630
追前沿,领略SET化架构衍化与设计
境外业务性能优化实践
前言 性能问题简介 应用性能是产品用户体验的基石,性能优化的终极目标是优化用户体验。当我们谈及性能,最直观能想到的一个词是“快”,Strangeloop在对众多的网站做性能分析之后得出了一个著名的3s定律“页面加载速度超过3s,57%的访客会离开”,可见页面加载速度对于互联网产品的重要性。 速度在Google、百度等搜索引擎的PR评分中也占有一定的比例,会影响到网站的SEO排名。“天下武功,唯快不破”,套在性能上面也非常适用。 性能指标 性能优化是个系统性工程,涉及到后端、前端、移动端、系统网络及各种基础设
美团技术团队
2018/03/13
7.9K0
境外业务性能优化实践
思考:如何保证服务稳定性?
最近一直在忙618大促的全链路压测&稳定性保障相关工作,结果618还未开始,生产环境就出了几次生产故障,且大多都是和系统稳定性、性能相关的bad case。生产全链路压测终于告一段落,抽出时间将个人收集的稳定性相关资料整理review了一遍,顺带从不同的维度,谈谈稳定性相关的“务虚”认知和思考。。。
老_张
2020/06/29
4.8K0
同城双活与异地多活架构分析
采用高可用系统架构支持重要系统,为关键业务提供7x24的不间断服务,已经成为众多企业保障业务稳定、持续运转的主要选择。服务多活是高可用架构重要实施手段,本文介绍了一些业界常用的多活手段例如同城双活、两地三中心、异地多活架构设计方案并详述了各种方案的优缺点。
2020labs小助手
2020/09/14
12.2K0
在线协作系统总体架构
之前写过几篇在线协作相关的文章,如何实现多人协作的在线文档,在线Excel存储方案,如何实现在线Excel多人协作,在线协作如何保证消息有序、不丢、不重,今天继续和大家一起探讨在线协作系统的总体架构。我们这里说的在线协作系统包括:「在线文档」、「在线Excel」、「在线脑图」、「在线流程图」、「在线PPT」、「在线PS」等文档类的系统。我们主要分前端和服务端两部分来讨论。
一行舟
2022/08/25
1.1K0
在线协作系统总体架构
如何设计一个高并发的高可用系统?
如何设计一个支持高并发的高可用服务?在前期设计时应该从哪些方面入手?明确的一点:没有哪一个系统是从一开始设计时就是高可用的,支持高并发的。都是在产品的发展壮大中,随着业务量的增加,逐渐对系统架构进行一步步升级。
小东啊
2019/11/14
2.2K0
看完这篇异地多活的改造,我决定和架构师battle一下
异地多活的概念以及为什么要做异地多活这里就不进行概述了。概念性的很多,像什么同城双活、两地三中心、三地五中心等等概念。如果有对这些容灾架构模式感兴趣的可以阅读下这篇文章进行了解:《浅谈业务级灾备的架构模式》。
得物技术
2023/07/11
5720
看完这篇异地多活的改造,我决定和架构师battle一下
从“挖光缆”到“剪网线”|蚂蚁金服异地多活的微服务体系
本文介绍了蚂蚁金服异地多活单元化架构的原理,以及微服务体系在此架构下的关键技术实现。
数据和云
2018/12/19
1.3K0
从“挖光缆”到“剪网线”|蚂蚁金服异地多活的微服务体系
这个场景题很常见,一定要会!
鱼皮最新原创项目教程,欢迎学习 大家好,我是鱼皮。 今天给大家分享一道场景设计题目:如何设计一个高并发系统。并给大家整理了高并发系统设计的 15 个锦囊,相信大家看完会有帮助的。 如何理解高并发系统 所谓设计高并发系统,就是设计一个系统,保证它整体可用的同时,能够处理很高的并发用户请求,能够承受很大的流量冲击。 我们要设计高并发的系统,那就需要处理好一些常见的系统瓶颈问题,如内存不足、磁盘空间不足,连接数不够,网络宽带不够等等,以应对突发的流量洪峰。 1. 分而治之,横向扩展 如果你只部署一个应用,只
程序员鱼皮
2023/03/29
5400
这个场景题很常见,一定要会!
单体架构服务转型至分布式的踩坑经历
背景 我们在聊架构风格之前先明确一个问题,什么是架构?我们为什么要选择架构?用来解决哪些问题? 什么是架构 书本定义:“软件的架构是一种抽象的结构,他由软件的各个组成部分和这些部分之间的依赖关系构成”。 我的理解是,架构就是根据业务选择合适的技术、中间件,并且按照合适的设计模式对这些模块,进行组装来满足业务特性的需求。 选择架构风格的目的 我们选择架构风格的初衷在于 “三更原则”(自己的理解) :更好地降本提效、更快地发版上线、更好地维护系统稳定性。 任何一个架构风格,都可以实现功能性需求,但是一个好的架构
程序猿DD
2023/04/04
2720
单体架构服务转型至分布式的踩坑经历
高并发系统设计的15个锦囊
记得很久之前,去面试过字节跳动。被三面的面试官问了一道场景设计题目:如何设计一个高并发系统。当时我回答得比较粗糙,最近回想起来,所以整理了设计高并发系统的15个锦囊,相信大家看完会有帮助的。
捡田螺的小男孩
2023/02/24
8420
高并发系统设计的15个锦囊
大型网站电商网站架构案例和技术架构的示例
大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型。除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标)。
数商云
2019/05/27
3K0
亿级流量网站架构核心技术【笔记】(二)
九、应用级缓存 A.缓存简介 1.先从缓存中读取数据,如果没有,再从慢速设备上读取实际数据并同步到缓存 2.经常读取的数据、频繁访问的数据、热点数据、I/O瓶颈数据、计算昂贵的数据、符合5分钟法则和局部性原理的数据都可以缓存 B.缓存命中率 1.缓存命中率=从缓存中读取次数/【总读取次数(从缓存中读取次数+从慢速设备上读取次数)】 C.缓存回收策略 1.基于空间,指缓存设置了存储空间 2.基于容量,指缓存设置了最大大小 3.基于时间
硬核项目经理
2019/08/06
1.3K0
亿级流量网站架构核心技术【笔记】(二)
聊聊高可用的 11 个关键技巧
面对一个庞然大物,如果没有一个合理的分工分层。任何一个小小失误都会被无限放大,酿成巨大灾难。
微观技术
2022/05/27
3840
聊聊高可用的 11 个关键技巧
从运维角度看中大型网站架构的演变之路
网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解。
互联网老辛
2018/10/18
1.2K0
推荐阅读
相关推荐
面试官:你给我画一下秒杀系统的架构图!
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文