小米科技|全栈监控：如何设计全栈监控策略？( 二 ) 汽车

技术栈。

知道了上面的结构之后，就要分析出整个架构所使用的技术组件有哪些，一一列出。如果有足够的信息支撑，也可以知道每个组件是如何使用的。比如说分库分表、读写分离、单元化部署等等和压测有关的关键技术。
但是如何使用这些技术呢？先看看我从架构上推导出来的内容。由于上面是宏观的描述，落地到具体的细节中，我们需要知道的是宏观的信息如何在具体的业务调用过程中使用的，所以我们推导出如下内容。

业务调用链我画了一个登录调用链你来直观感受一下。

像这样的调用链，画出来当然清晰，但是所有的业务调用链都画一下，这图也没法看了，所以我们可以列出来一个这样的表格。

掌握这些调用链，后面的性能分析才不会在拆分时间时感到混乱。

容量所需的资源我们还能大概计算一下容量所需的资源。比如，根据我的经验，登录服务在一个6C12G的容器（这里指的是登录链路上的所有服务都有这样的硬件配置）中， 700TPS是稳稳的可以撑得住的，要是极端一点，上1000TPS也不是不可能，但对应的响应时间也会增加。这个时候会需要多少硬件资源呢，上面说了，登录业务涉及member和auth两个服务、一个MySQL、一个Redis 。如果我们是想支撑2000TPS的登录业务，那就是近3倍的资源需求（先这样线性计算，实际项目中还是要进行横向扩展测试，同时我们还需要考虑冗余，即水位系数），那么总共需要的资源是多少呢？这里我拿CPU来计算一下，其他资源类似。

技术栈有了上面的架构之后，我们可以列出这样的技术栈来。

微服务框架：Spring Cloud 、Spring Cloud Alibaba
容器+MVC 框架：Spring Boot
认证和授权框架：Spring Security OAuth2
ORM 框架：MyBatis
数据层代码生成：MyBatisGenerator
MyBatis 物理分页插件：PageHelper
文档生产工具：Knife4j
搜索引擎：Elasticsearch
消息队列：RabbitMQ
分布式缓存：Redis
NoSQL 数据库：MongoDB
应用容器引擎：Docker
数据库连接池：Druid
对象存储：OSS、MinIO
JWT 登录支持：JWT
日志收集、处理、转发：LogStash
日志队列和缓冲：Kafka
日志采集：Filebeat
可视化分析与展示：Kibana
简化对象封装工具：Lombok
全局事务管理框架：Seata
应用容器管理平台：Kubernetes
服务保护：Sentinel
分布式链路追踪系统：Zipkin
基础资源监控： Prometheus
容器级链路监控： Weave Scope
可视化看板：Grafana

其实，从架构中得到的信息还远不止上面的三种。请注意，我这里说的架构资料并不限于上面的图，还有架构设计相关的其他各种资料。从这些资料中，我们可以得出企业IT规划、架构设计思路、技术实现逻辑、运维技术的逻辑等等。
你可能会说，这些有什么用呢？这就是做性能要从工程的视角来解释的原因了。只有我们把性能工程覆盖到系统生命全周期中，压测这个动作才有真正的意义，才能贯穿一个系统从原始需求到线上运维的全流程。
现在，我们已经拿到了技术栈，接下来就要对应这个技术栈来确定我们的性能分析决策树了。
全链路压测性能分析决策树性能分析决策树是什么？在第三讲里我讲过，针对项目中用到的技术栈，你通过分析对应的技术组件以及组件对应的模块，得到全量计数器，然后把这个过程通过树状结构展示出来，并画出相应的关联关系，这就是性能分析决策树了。