高并发系统设计 40 问
唐扬
美图公司技术专家
49013 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
高并发系统设计 40 问
15
15
1.0x
00:00/00:00
登录|注册

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

内部成本、沟通成本、运维成本
上线变更不灵活
构建时间增加
模块之间互相依赖
代码冲突和功能耦合
沟通成本随团队规模增加而增加
数据库连接数成为瓶颈
分享微服务化的道路经验
成本成为架构设计的决定性因素
考虑成本
起初和中期关注性能、可用性、可扩展性
构建速度提升
维护人员职责明确
功能内聚
提高代码重用性
提升系统可扩展性
控制数据库连接数
运维影响
研发成本和效率问题
技术层面问题
便捷的开发运维
一课一思
微服务化的决定因素
微服务化带来的优势
公用服务的抽取
业务池的拆分
缺陷
选用一体化架构的初衷
课程小结
如何使用微服务化解决这些痛点
一体化架构的痛点
系统架构:每秒1万次请求的系统要做服务化拆分吗?

该思维导图由 AI 生成,仅供参考

你好,我是唐扬。
通过前面几个篇章的内容,你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。
现在你的系统运行稳定好评不断,每天高峰期的流量已经达到了 10000/s 请求,DAU 也涨到了几十万。CEO 非常高兴,打算继续完善产品功能进行新一轮的运营推广,争取在下个双十一可以将 DAU 冲击过百万。这时你开始考虑怎么通过技术上的优化改造支撑更高的并发流量,比如支撑过百万的 DAU。
于是你重新审视了自己的系统架构,分析系统中有哪些可以优化的点。
目前来看,工程的部署方式还是采用一体化架构。也就是说所有的功能模块,比如电商系统中的订单模块、用户模块、支付模块、物流模块等等都被打包到一个大的 Web 工程中,然后部署在应用服务器上。
你隐约觉得这样的部署方式可能存在问题,于是 Google 了一下后发现当系统发展到一定阶段都要做微服务化的拆分,你也看到淘宝的“五彩石”项目对于淘宝整体架构的扩展性带来的巨大影响。这一切让你心驰神往。
但是有一个问题一直萦绕在你的心里:究竟是什么促使我们将一体化架构拆分成微服务化架构?是不是说系统的整体 QPS 到了 1 万或者到了 2 万,就一定要做微服务化拆分呢?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

电商系统在面临高并发流量时,一体化架构可能会带来一些痛点,如数据库连接数限制、研发效率下降、系统运维受影响等。因此,考虑将一体化架构拆分成微服务化架构是值得思考的。微服务化拆分可以解决数据库连接数限制、提高研发效率、减少模块间依赖、提升系统运维灵活性等问题。文章通过实际案例说明了微服务化拆分的必要性和优势,例如将与用户相关的逻辑部署成单独的服务,抽取公用服务形成独立服务,以及通过横向拆分解决数据库层面的扩展性问题。此外,文章还强调了微服务化带来的维护人员职责明确、构建速度提升等优势。总的来说,文章强调了在架构演进的初期和中期,性能、可用性、可扩展性是主要目标,但随着系统规模和团队成员增加,成本也成为架构设计中的决定性因素,从而引出了微服务化的必要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(34)

  • 最新
  • 精选
  • Alex Liu
    现在只要是个项目都恨不得用微服务,而且用的不彻底,反而集成了单体和微服务的缺点,简直就是人间炼狱啊

    作者回复: 是的,会非常痛苦

    2020-03-26
    2
    11
  • 沐紫剑
    如果一个系统微服务数比开发人数还要多,这样合理吗

    作者回复: 一般一个人可以维护2-3个微服务,所以算是合理的

    2020-06-07
    3
    9
  • Geek_33c134
    唐老师你好,关于高并发的系统人们都会问系统的qps是多少。但是如果一个系统经过服务化之后,我只会负责其中的一个小模块,所以我关注的只是这个模块的访问量多少。所以系统的qps我是无法关注的,也关注不出什么东西(因为其他的模块都不是我负责的)。想问下这时候人们所问的qps是指模块的qps还是只系统呢?如果是模块的话qps其实是比较小的,很难提到高并发;但是如果是系统的qps,而其他模块是其他部门负责的,与我又没有什么关系。这种情况下应该如何回答呢?

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

    2019-11-19
    4
    7
  • 张传美
    一个工程师负责几个服务是合理的? 我的思考:从服务活跃度,重要度,工程师水平三个角度来考虑 1. 活跃又重要的服务,一个高级开发工程师不超过3个? 2. 非活跃,非重要的服务在全部服务数中的占比应低于30%? 想问下: 1. 业界的最佳实践是? 2. 您认为一个工程师负责几个服务是合理的?

    作者回复: 个人觉得2个活跃的服务可能已经疲于奔命了

    2020-03-25
    2
    5
  • Thranduil
    公司刚开始就直接上中台可行吗?

    作者回复: 额 大概率是不可行的,中台其实是对现有业务的抽象,如果连业务都没有,何谈抽象呢

    2020-02-25
    2
    5
  • helloworld
    请问老师,若把一个单体服务拆分成多个微服务后,原来客户端只需要一次http调用服务器,微服务化后客户端需要多次http调用服务器端,这就对客户端来说就增加了总的调用时间了,是不是存在这个问题呢?

    作者回复: 是的 是有多一跳的问题

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

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

    2019-11-11
    2
    4
  • 空知
    走上微服务的原因是 1、确实是代码量大 交互在一起复杂 2、部署、测试麻烦

    作者回复: 是的

    2020-01-15
    2
    2
  • longslee
    打卡。还是有收获的,以前理解微服务化,只知道业务细分和单独部署扩建容易,没想到数据库连接数这个地方也有讲究。 曾经的大项目是一体化的,开发过程比较崩溃的是八竿子打不着的类被远方的一个兄弟改了,我提交代码的时候被卡下来了。。。原因就是紧耦合,而我没有全量更新代码。

    作者回复: 👍👍

    2019-11-12
    2
  • 阿卡牛
    之前主导过一个项目,那时正是微服务概念开始流行的时候,脑袋一热,很多东西还没搞懂,就心痒痒地弄起来了。 结果当然悲剧了,还好及时止损。 不过遇到一个大问题还是可以说说的:就是数据问题,至今没搞明白,多个微服务之间是否可以存在相同的数据。还是必须通过接口的方式获取

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

    2019-11-12
    2
    2
收起评论
显示
设置
留言
34
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部