21 | 系统架构:每秒1万次请求的系统要做服务化拆分吗?
唐扬
该思维导图由 AI 生成,仅供参考
你好,我是唐扬。
通过前面几个篇章的内容,你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。
现在你的系统运行稳定好评不断,每天高峰期的流量已经达到了 10000/s 请求,DAU 也涨到了几十万。CEO 非常高兴,打算继续完善产品功能进行新一轮的运营推广,争取在下个双十一可以将 DAU 冲击过百万。这时你开始考虑怎么通过技术上的优化改造支撑更高的并发流量,比如支撑过百万的 DAU。
于是你重新审视了自己的系统架构,分析系统中有哪些可以优化的点。
目前来看,工程的部署方式还是采用一体化架构。也就是说所有的功能模块,比如电商系统中的订单模块、用户模块、支付模块、物流模块等等都被打包到一个大的 Web 工程中,然后部署在应用服务器上。
你隐约觉得这样的部署方式可能存在问题,于是 Google 了一下后发现当系统发展到一定阶段都要做微服务化的拆分,你也看到淘宝的“五彩石”项目对于淘宝整体架构的扩展性带来的巨大影响。这一切让你心驰神往。
但是有一个问题一直萦绕在你的心里:究竟是什么促使我们将一体化架构拆分成微服务化架构?是不是说系统的整体 QPS 到了 1 万或者到了 2 万,就一定要做微服务化拆分呢?
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
电商系统在面临高并发流量时,一体化架构可能会带来一些痛点,如数据库连接数限制、研发效率下降、系统运维受影响等。因此,考虑将一体化架构拆分成微服务化架构是值得思考的。微服务化拆分可以解决数据库连接数限制、提高研发效率、减少模块间依赖、提升系统运维灵活性等问题。文章通过实际案例说明了微服务化拆分的必要性和优势,例如将与用户相关的逻辑部署成单独的服务,抽取公用服务形成独立服务,以及通过横向拆分解决数据库层面的扩展性问题。此外,文章还强调了微服务化带来的维护人员职责明确、构建速度提升等优势。总的来说,文章强调了在架构演进的初期和中期,性能、可用性、可扩展性是主要目标,但随着系统规模和团队成员增加,成本也成为架构设计中的决定性因素,从而引出了微服务化的必要性。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《高并发系统设计 40 问》,新⼈⾸单¥59
《高并发系统设计 40 问》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(34)
- 最新
- 精选
- Alex Liu现在只要是个项目都恨不得用微服务,而且用的不彻底,反而集成了单体和微服务的缺点,简直就是人间炼狱啊
作者回复: 是的,会非常痛苦
2020-03-26211 - 沐紫剑如果一个系统微服务数比开发人数还要多,这样合理吗
作者回复: 一般一个人可以维护2-3个微服务,所以算是合理的
2020-06-0739 - Geek_33c134唐老师你好,关于高并发的系统人们都会问系统的qps是多少。但是如果一个系统经过服务化之后,我只会负责其中的一个小模块,所以我关注的只是这个模块的访问量多少。所以系统的qps我是无法关注的,也关注不出什么东西(因为其他的模块都不是我负责的)。想问下这时候人们所问的qps是指模块的qps还是只系统呢?如果是模块的话qps其实是比较小的,很难提到高并发;但是如果是系统的qps,而其他模块是其他部门负责的,与我又没有什么关系。这种情况下应该如何回答呢?
作者回复: 可以只是你负责的qps,你需要对你负责的项目模块的数据有足够的了解
2019-11-1947 - 张传美一个工程师负责几个服务是合理的? 我的思考:从服务活跃度,重要度,工程师水平三个角度来考虑 1. 活跃又重要的服务,一个高级开发工程师不超过3个? 2. 非活跃,非重要的服务在全部服务数中的占比应低于30%? 想问下: 1. 业界的最佳实践是? 2. 您认为一个工程师负责几个服务是合理的?
作者回复: 个人觉得2个活跃的服务可能已经疲于奔命了
2020-03-2525 - Thranduil公司刚开始就直接上中台可行吗?
作者回复: 额 大概率是不可行的,中台其实是对现有业务的抽象,如果连业务都没有,何谈抽象呢
2020-02-2525 - helloworld请问老师,若把一个单体服务拆分成多个微服务后,原来客户端只需要一次http调用服务器,微服务化后客户端需要多次http调用服务器端,这就对客户端来说就增加了总的调用时间了,是不是存在这个问题呢?
作者回复: 是的 是有多一跳的问题
2020-06-094 - 撒旦的堕落以前每次发版整个部门的人都要到凌晨 项目太大 导致开发时项目启动耗时太多 自己的代码会牵扯到别人的代码 提交时 代码冲突问题 因为所有人代码都在一块 一个人有功能要上线 其他人都得留下 一个很小的功能上线 测试都到对其他功能做回归测试 真的太难了
作者回复: 相同的经历呀,苦涩~
2019-11-1124 - 空知走上微服务的原因是 1、确实是代码量大 交互在一起复杂 2、部署、测试麻烦
作者回复: 是的
2020-01-1522 - longslee打卡。还是有收获的,以前理解微服务化,只知道业务细分和单独部署扩建容易,没想到数据库连接数这个地方也有讲究。 曾经的大项目是一体化的,开发过程比较崩溃的是八竿子打不着的类被远方的一个兄弟改了,我提交代码的时候被卡下来了。。。原因就是紧耦合,而我没有全量更新代码。
作者回复: 👍👍
2019-11-122 - 阿卡牛之前主导过一个项目,那时正是微服务概念开始流行的时候,脑袋一热,很多东西还没搞懂,就心痒痒地弄起来了。 结果当然悲剧了,还好及时止损。 不过遇到一个大问题还是可以说说的:就是数据问题,至今没搞明白,多个微服务之间是否可以存在相同的数据。还是必须通过接口的方式获取
作者回复: 没有准备好就为服务化是大坑
2019-11-1222
收起评论