前言
上周四（10月14日）晚，受邀参加了由数列科技主办的线上技术直播——PGUG系列-大促保障之旅，其中我分享的Topic是《大型业务活动，如何保障系统的稳定性》。
分享过程中，参与直播的同学们提了很多问题，碍于很多问题无法一两句概括，因此写了这篇文章，对这些同学提出的问题做一个解答。当然，回答仅限于我个人的角度，仅供参考。
- PGUG系列：大促保障之旅专栏
- PPT下载：大型业务活动，如何保障系统的稳定性？
- 课程回放：大型业务活动，如何保障系统的稳定性？
Question
|
编号 |
提问用户微信名 |
提问的问题 |
|
1 |
Armo |
流量模型具体指得是什么？ |
|
2 |
怎么根据入口流量和内部流量的成份比例关系进行计算？ |
|
|
3 |
流量的预估上是怎么做的呢？ |
|
|
4 |
容量水位是怎么定义的？当前QPS/按照压测的QPS？ |
|
|
5 |
王雷 |
K8S是不是自动扩容？ |
|
6 |
空 |
在压测时，请求参数一般都是重复的吗？ |
|
7 |
在压测过程的时候，怎么确定多少连接数比较合适？比如，Redis连接数，数据库连接数，线程数，Tomcat连接数？ |
|
|
8 |
Macan |
容量水位如何评估是否扩展讲细一点？还有自动扩缩容调度决策如何制定？ |
|
9 |
多的 |
应用服务可以通过这些方式达到高性能高可用，但是相对应的，数据库DB也会有大量的数据读写操作，这也可能导致DB挂掉，请问这种情况怎么办？ |
Answer
PS：很多问题归类下来都很类似，我归纳汇总下来，主要有如下几点：
流量模型
关于流量模型，大家先看下面这幅图：
1、流量模型具体指得是什么？
分布式服务架构下，服务间调用关系是及其复杂的。如上图所示，一个用户请求，要经过层层调用，才能到达数据库。
且调用过程中，对Redis、MQ或其他下游服务的调用可能要多次。这就导致了一种现象：用户请求一次，对下游的其他服务或者中间件可能请求了多次，这样就形成了一个漏斗状的模型。
到这里，流量模型是什么的答案，其实已经出来了。非要做一个定义的话，我认为应该这样定义：
流量模型：系统处理用户请求过程中，请求对系统内部服务及中间件的调用形成的关系集合；
如何理解：所谓的流量模型这种关系集合，一般来说都是都是漏斗形状，即上窄下宽；
2、流量的预估上是怎么做的呢？
流量预估，一般的步骤如下：
- 确定业务目标（技术最终要为业务目标达成负责）；
- 转化为核心链路技术指标（电商行业核心链路一般为订单量）；
- 依赖流量模型，由核心链路进行转化计算（一般都是选取峰值的请求流量）；
3、怎么根据入口流量和内部流量的比例关系进行计算？
以第二个问题的预估步骤为例，参考如下计算方式：
-
业务目标：今年双十一，业务目标是DAU1000W，支付单量100W；
-
假设创建订单接口和发起支付接口比例为3:1，那么支付接口QPS=100W；
-
假设往年大促80%的支付请求分布在双十一0点前一个小时，前一个小时请求中，前十分钟占比60%；
-
由上可得：支付接口QPS=100W*80%*60%=48W，创建订单接口QPS=3*100W*80%*60%=144W；
-
平均到秒级别，支付接口QPS=800，创建订单接口QPS=2400；
-
以核心链路的QPS为基准，按照流量模型调用关系进行放大或者缩小计算，即可得出每个应用大促峰值需要承接的QPS；
PS：QPS如何得到？依赖监控系统！
容量评估
4、K8S是不是自动扩容？
k8s是为容器服务而生的一个可移植容器的编排管理工具，从架构设计层面我们关注的可用性、伸缩性都可以结合k8s得到很好的解决。
从服务部署运维、服务监控、应用扩容和故障处理，k8s都提供了很好的解决方案。具体来说，主要包括以下几点：
- 服务发现与调度；
- 负载均衡；
- 服务自愈；
- 服务弹性扩容；
- 横向扩容；
- 存储卷挂载；
PS：综上所述，服务弹性扩容只是K8S的功能之一，且弹性扩缩容，除了K8S还有其他的实现方式和工具。
5、容量水位是怎么定义的？当前QPS/按照压测的QPS？
如何理解容量？举个例子：一台4C8G的虚拟机，在CPU使用率达到最大值时，它的处理能力(TPS)是500。
但线上正常的服务负载，一般不会让超过40%，这也是所谓的安全水位。在安全水位下，可能这台虚拟机的处理能力只有200。这就是所谓的容量水位，安全水位。
容量水位定义：系统处于X并发情况下，保证安全水位时候的处理能力。
参照上述第三个问题的回答：如果某个核心接口的预估峰值QPS=2400，那这个接口所在的服务集群，最少的机器数量应该为12+（需要留一定的buffer，保证冗余空间）。
PS：需要注意的是：一个服务对应多个接口，需要保证被测接口的请求在该服务占据绝大部分。
6、容量水位如何评估是否扩展讲细一点？还有自动扩缩容调度决策如何制定？
容量水位评估，参照上述第五个问题。
自动扩缩容调度决策，实现的逻辑无非就是单机设定一个阈值，超过该阈值自动扩容服务。需要注意的是，负载均衡有时候不是完美的，还需要一个集群的阈值，配合服务健康检查。
PS：扩容一般都需要有热备的机器，容器相对扩容速度更快一些，如果是ECS等虚拟机，需要考虑机器热备。
压测配置
7、在压测时，请求参数一般都是重复的吗？
压测请求用到的数据，一般有3种：
- 基础数据：数据库表中用于铺底的基础数据，比如商品信息，库存数之类的；
- 幂等数据：常见的只读接口，如果不涉及逻辑校验，可以用重复的数据；
- 热点数据：即参数化数据，比如用户的userid，手机号等，部分业务逻辑涉及到唯一性校验；
参数配置
8、在压测过程中，怎么确定多少连接数比较合适？比如，Redis连接数、数据库连接数、线程数、Tomcat连接数？
一般常用的中间件，应用容器和DB，都会有默认的参数配置和官方推荐的配置。但考虑到不同的业务场景和技术实现方式，都是采用配置测试的方式来调整验证配置。
比如Tomcat的线程数，之前我做过类似的验证：1台16C32G的机器，性能和负载最均衡的线程配置数是256。
官方推荐的好像也是16N（这里的N指的是服务器的物理核数）。当然，配置为512，性能更好一些，但机器负载相对会更高一些。
PS：以Tomcat为例，线程配置也分为最小连接数和最大连接数，活跃线程数和最大等待线程数以及timeout。这几个配置参数之间，也是有关系的，建议看看官方文档了解下不同参数配置的含义。
DB高可用
9、应用服务可以升配扩容达到高性能，但是对应DB也会有大量读写操作，这可能导致DB挂掉，这种情况怎么办？
目前来说，数据库的性能瓶颈只能通过升配、分库分表、拆分实例来提升。当然，优化慢SQL、事务合并、技术改造直连DB为读写缓存，也是一种方式，但根本上还是治标不治本。
结语
上述问题的有些回答，我的回复只能作为参考，因为每个人面临的技术和业务挑战都不一样，还是需要灵活评估解决的。
很多问题或者遇到的疑惑，需要大家自己去探索。成长是一个闭环，需要学习-实践-试错-复盘-不断优化。上述的答疑中留了一些问题，相关同学如果感兴趣，可以尝试思考如何解决它们。