16 | 高性能和可伸缩架构：业务增长，能不能加台机器就搞定？

王庆友

你好，我是王庆友，今天我来和你聊一聊如何打造高性能和可伸缩的系统。
在课程的第 11 讲，我和你介绍了，技术架构除了要保证系统的高可用，还要保证系统的高性能和可伸缩，并且能以低成本的方式落地。在实践中呢，高性能、可伸缩和低成本紧密相关，处理的手段也比较类似，这里我就放在一起来给你讲解。
在实际的工作当中，我们一般会比较关注业务功能的实现，而很少关注系统的性能，所以我们经常会面临以下这些挑战：
系统的 TPS 很低，只要流量一大，系统就挂，加机器也没用；
机器的资源利用率很低，造成资源严重浪费。
我曾经就统计过公司云服务器的资源利用率，结果让我非常意外，有相当比例的服务器，它们的 CPU 和内存平均利用率长期不到 1%，但与此同时，这些系统整体的 TPS 只有个位数。这里，你可以发现，资源利用率低和系统性能低的现象同时并存，很显然，系统没有充分利用硬件资源，它的性能有很大的优化空间。
所以今天，我就先来给你介绍一下常用的性能数据，让你建立起对性能的基本概念；然后，我会和你具体讲解实现系统高性能和可伸缩的策略，让你能在实践中灵活运用。
常用的性能数据对于服务器来说，1ms 的时间其实不算短，它可以做很多事情，我在这里列了几个基础的性能数据，你可以把它们看做是系统性能的基线。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入探讨了如何构建高性能和可伸缩的系统，针对实际工作中常见的性能低和资源利用率低的挑战，提出了一系列解决方案。首先，作者列举了常用的性能数据，帮助读者建立对性能的基本概念。接着，详细讲解了实现系统高性能和可伸缩的策略和手段，包括加快单个请求处理、同时处理多个请求以及请求处理异步化等方法。此外，还介绍了系统的可伸缩能力实现方式，包括节点级别的可伸缩和有状态服务的状态数据重新分布。文章还提出了高性能和可伸缩架构原则，包括可水平拆分和无状态、短事务和柔性事务、数据可缓存、计算可并行、可异步处理、虚拟化和容器化等。总的来说，本文为读者提供了在实际工作中如何应对系统性能和可伸缩性挑战的实用指导。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《架构实战案例解析》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(16)

最新
精选

小洛
单元化处理是个很好的思路，请教下老师在实践中有什么要注意的地方吗！再次感谢老师您的分享！
作者回复: 核心就两点： 1. 用户ID要在各个处理环节一路传递下去，这个会作为路由根据。 2. 数据如何分布，有些可以按照用户分开分布，比如订单，保存在各自机房；有些和用户无关，比如商品，这个偏静态，在每个机房做全量部署。还有是库存，属于全局，但是动态数据，可以考虑中心化部署，各个机房都直接访问。
2020-04-05

8
Carey
老师，你给的基础性能数据，是在什么样的硬件资源下得到的呢？比如CPU主频是多少，网络带宽是多少？
作者回复: 这个基础数据你大致有数就可以，供参考，不用纠结硬件配置。
2020-08-22


小洛
再次请教下老师您关于第二点中库存中心化部署方案，是不是会出现下单扣减库存时跨机房的调用？作者回复: 核心就两点： 1. 用户ID要在各个处理环节一路传递下去，这个会作为路由根据。 2. 数据如何分布，有些可以按照用户分开分布，比如订单，保存在各自机房；有些和用户无关，比如商品，这个偏静态，在每个机房做全量部署。还有是库存，属于全局，但是动态数据，可以考虑中心化部署，各个机房都直接访问。
作者回复: 如果中心化部署，会有跨机房访问
2020-04-07


特种流氓
事务期间是否事务用到的资源都会被锁定
作者回复: 有读锁和写锁，读锁的话大家都可以访问，写锁的话，大家对资源的修改就是互斥的。
2020-03-27


zeor
老师您好，请问怎么计算出一个系统要多少台机器，能抗住高峰期和平时，都有哪此指标和什么计算工公式？
作者回复: 没有特别好的计算方式，大致根据平时的性能进行估算，然后主要靠压测，在压测中优化。
2020-03-27
2

丁丁历险记
去年维护一个旧系统加了缓存，数据库主从，大表格分区处理。核心业务分解，同步转异步。技术栈而言，没有运维，自己折腾，所以简单粗暴优先。数据库 mysql 从5.1 升至5.7 主要时mysql io 的一个吧bug。缓存直接用redis 消息队列用rabbit mq 先封装数据库查询类，再将业务逐步接口化，tdd 开发流程。测试用例加个描述即文档。再就是业务架构，这点比较难，老板懂一点技术，又有自己的坚持，数据库设计的灵活性造成统计无法准确。只能用香浓第一定律，一点点优化，不段在业务上加约束，减少脏数据，对课时管理，直接删掉直接update 的功能，仅支持增减。小公司的不容易，就是没有前端，于是bootstrap 来实现布局，pjax 实现数据无刷新体验优化，再自己封装分页，弹窗用layer ，微信用weui 图表用echart 再就是slowquery 处理，一本高性能mysql 相伴，explain 再优化，例如defer join ，例如or 引发索引失效。投票服务用mysql 做的流控，转用redis 来处理。然后学了docker 容器化部署， k8s 太难没时间投入。
2020-05-04

23
萧
- 高性能的策略和手段 - 加快单个请求的处理 - 优化处理路径上每个节点的处理速度 - 并行处理单个请求 - 同时处理多个请求 - 请求处理异步化 - 可伸缩的策略和手段 - 节点级别的可伸缩 - 系统级别的可伸缩 - 高性能和可伸缩架构原则 - 可水平拆分和无状态 - 短事务和柔性事务 - 数据可缓存 - 计算可并行 - 虚拟化和容器化
2020-10-14

1
雨霖铃声声慢
我们使用公有云的auto scale功能来保证高可用和可伸缩，AWS和Ali云都有类似的功能。
2020-04-06
1
1
OM
用oracle19c+shareding 搞定
2022-03-23


流云追风
水平拆分,缓存,异步,上云虚拟化
2021-10-26



收起评论