高并发系统设计40问
唐扬
美图公司技术专家
立即订阅
9202 人已学习
课程目录
已更新 38 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要学习高并发系统设计?
免费
基础篇 (6讲)
01 | 高并发系统:它的通用设计方法是什么?
02 | 架构分层:我们为什么一定要这么做?
免费
03 | 系统设计目标(一):如何提升系统性能?
04 | 系统设计目标(二):系统怎样做到高可用?
05 | 系统设计目标(三):如何让系统易于扩展?
06 | 面试现场第一期:当问到组件实现原理时,面试官是在刁难你吗?
演进篇 · 数据库篇 (5讲)
07 | 池化技术:如何减少频繁创建数据库连接的性能损耗?
08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?
09 | 数据库优化方案(二):写入数据量增加时,如何实现分库分表?
10 | 发号器:如何保证分库分表后ID的全局唯一性?
11 | NoSQL:在高并发场景下,数据库和NoSQL如何做到互补?
演进篇 · 缓存篇 (6讲)
12 | 缓存:数据库成为瓶颈后,动态数据的查询要如何加速?
13 | 缓存的使用姿势(一):如何选择缓存的读写策略?
14 | 缓存的使用姿势(二):缓存如何做到高可用?
15 | 缓存的使用姿势(三):缓存穿透了怎么办?
16 | CDN:静态资源如何加速?
加餐 | 数据的迁移应该如何做?
演进篇 · 消息队列篇 (6讲)
17 | 消息队列:秒杀时如何处理每秒上万次的下单请求?
18 | 消息投递:如何保证消息仅仅被消费一次?
19 | 消息队列:如何降低消息队列系统中消息的延迟?
20 | 面试现场第二期:当问到项目经历时,面试官究竟想要了解什么?
用户故事 | 从“心”出发,我还有无数个可能
期中测试 | 10道高并发系统设计题目自测
演进篇 · 分布式服务篇 (9讲)
21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
22 | 微服务架构:微服务化后,系统架构要如何改造?
23 | RPC框架:10万QPS下如何实现毫秒级的服务调用?
24 | 注册中心:分布式系统如何寻址?
25 | 分布式Trace:横跨几十个分布式组件的慢请求要如何排查?
26 | 负载均衡:怎样提升系统的横向扩展能力?
27 | API网关:系统的门面要如何做呢?
28 | 多机房部署:跨地域的分布式系统如何做?
29 | Service Mesh:如何屏蔽服务化系统的服务治理细节?
演进篇 · 维护篇 (5讲)
30 | 给系统加上眼睛:服务端监控要怎么做?
31 | 应用性能管理:用户的使用体验应该如何监控?
32 | 压力测试:怎样设计全链路压力测试平台?
33 | 配置管理:成千上万的配置项要如何管理?
34 | 降级熔断:如何屏蔽非核心系统故障的影响?
高并发系统设计40问
登录|注册

21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?

唐扬 2019-11-11
你好,我是唐扬。
通过前面几个篇章的内容,你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。
现在,你的系统运行稳定,好评不断,每天高峰期的流量,已经达到了 10000/s 请求,DAU 也涨到了几十万。CEO 非常高兴,打算继续完善产品功能,以便进行新一轮的运营推广,争取在下个双十一可以将 DAU 冲击过百万。这时,你开始考虑,怎么通过技术上的优化改造,来支撑更高的并发流量,比如支撑过百万的 DAU。
于是,你重新审视了自己的系统架构,分析系统中有哪些可以优化的点。
目前来看,工程的部署方式还是采用一体化架构,也就是说所有的功能模块,比方说电商系统中的订单模块、用户模块、支付模块、物流模块等等,都被打包到一个大的 Web 工程中,然后部署在应用服务器上。
你隐约觉得这样的部署方式可能存在问题,于是,你 Google 了一下,发现当系统发展到一定阶段,都要做微服务化的拆分,你也看到淘宝的“五彩石”项目,对于淘宝整体架构的扩展性,带来的巨大影响。这一切让你心驰神往。
但是有一个问题一直萦绕在你的心里:究竟是什么促使我们将一体化架构,拆分成微服务化架构?是不是说系统的整体 QPS 到了 1 万,或者到了 2 万,就一定要做微服务化拆分呢?
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《高并发系统设计40问》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(17)

  • 真飞鸟
    走上微服务化道路的主要原因还是微服务目前大热加上docker的兴起,出于可能降低成本的考虑。
    但以前就是SOA的架构,按照模块分解服务,但是并没有微服务,不知道这样的模块分解服务然后通过DNS去访问的方式叫做什么呢?
    而有个问题在于现在公司的确是将业务按照模块拆分了,但是这些模块还是访问的同一个库,这样微服务拆分是不是并没有性能上的提升,反而因为多了网络传输而更加慢了,只是逻辑分层清晰了?那这个时候还有必须微服务么?毕竟多开一个数据库实例就要有额外的支出。
    2019-11-11
    1
    7
  • chp
    现在公司,把业务按模块拆分,每个成员负责一个模块,但是这些模块依然连的同一个库。
    2019-11-11
    7
  • oneDream
    微服务最根本的应该是解决架构和可扩展的问题,像文章重说的1wqps 在微服务场景中也同样存在
    2019-11-29
  • Geek_33c134
    唐老师你好,关于高并发的系统人们都会问系统的qps是多少。但是如果一个系统经过服务化之后,我只会负责其中的一个小模块,所以我关注的只是这个模块的访问量多少。所以系统的qps我是无法关注的,也关注不出什么东西(因为其他的模块都不是我负责的)。想问下这时候人们所问的qps是指模块的qps还是只系统呢?如果是模块的话qps其实是比较小的,很难提到高并发;但是如果是系统的qps,而其他模块是其他部门负责的,与我又没有什么关系。这种情况下应该如何回答呢?

    作者回复: 可以只是你负责的qps,你需要对你负责的项目模块的数据有足够的了解

    2019-11-19
  • 饭饭
    用户服务伸缩的时候数据库还是会成为瓶颈
    2019-11-13
  • 啊啊啊哦哦
    用户池值得是用户连接池?

    作者回复: 不是 是部署用户的接口的业务

    2019-11-12
  • Devin
    系统QPS并不是微服务化的决定性因素或者说直接因素,主要还是看是否遇到问题了,比如资源问题、效率问题、成本问题等。
    2019-11-12
  • longslee
    打卡。还是有收获的,以前理解微服务化,只知道业务细分和单独部署扩建容易,没想到数据库连接数这个地方也有讲究。 曾经的大项目是一体化的,开发过程比较崩溃的是八竿子打不着的类被远方的一个兄弟改了,我提交代码的时候被卡下来了。。。原因就是紧耦合,而我没有全量更新代码。

    作者回复: 👍👍

    2019-11-12
  • 海罗沃德
    由於公司是跨國的業務系統,以前的monolith服務器部署在美國,就導致歐洲亞洲訪問速度很慢,但是分地理位置部署成本又太高,就考慮使用AWS的跨region模式,租用AWS的專線來做數據的不同region同步
    2019-11-12
  • 阿卡牛
    之前主导过一个项目,那时正是微服务概念开始流行的时候,脑袋一热,很多东西还没搞懂,就心痒痒地弄起来了。
    结果当然悲剧了,还好及时止损。
    不过遇到一个大问题还是可以说说的:就是数据问题,至今没搞明白,多个微服务之间是否可以存在相同的数据。还是必须通过接口的方式获取

    作者回复: 没有准备好就为服务化是大坑

    2019-11-12
  • 旅途
    老师,业务池的作用什么,其他的业务池只访问用户池可以吗

    作者回复: 业务池是为了隔离故障把业务拆分部署,业务池之间是平等的,最好不要相互调用

    2019-11-12
    1
  • 小小小丶盘子
    面试的时候,面试官问我,你们体量不大为什么要拆分呢?我从开发的角度回答的。项目维护或者单独优化,提取公共服务之类。老师,如果只是为了开发维护上做业务模块拆分,有必要吗?

    作者回复: 我觉得如果维护上痛点明显的话是有必要的

    2019-11-12
    1
  • 星空123
    目前项目还不是微服务的架构。但是早晚会变成微服务的
    2019-11-11
  • 吃饭饭
    一句话:量变引起质变;现在不少人张嘴微服务闭嘴微服务,但是得去衡量自己的业务真的有必要吗?微服务看着优雅其实成本很大,就单纯这个问题每秒上完 QPS ,这业务量很大了,不细粒度怎么可以

    作者回复: 是的~

    2019-11-11
  • 风再起时
    发个版 ,半小时

    作者回复: 有时候不止半小时:(

    2019-11-11
  • Omer
    老师你好 ,我想请教一下。
    数据库那块我有点疑惑,你把用户的模块拆分出来成了单独的用户库访问,为什么就减少了用户库的瓶颈呢,那我拆分之前的所有用户库的请求不减少的情况下都丢给用户模块,那请求数量和建立连接的数量和 不拆分的时候不是都差不多吗,而且还增加了不同服务之间的IO,希望老师看到能点解一下

    作者回复: 是拆分成单独的用户服务,这个服务只处理与用户相关的业务逻辑,所以部署的机器相比web层要少很多

    2019-11-11
    3
  • 撒旦的堕落
    以前每次发版整个部门的人都要到凌晨 项目太大 导致开发时项目启动耗时太多 自己的代码会牵扯到别人的代码 提交时 代码冲突问题 因为所有人代码都在一块 一个人有功能要上线 其他人都得留下 一个很小的功能上线 测试都到对其他功能做回归测试 真的太难了

    作者回复: 相同的经历呀,苦涩~

    2019-11-11
收起评论
17
返回
顶部