1. 这不是“谁在调度”而是“调度的边界在哪里”——一次穿透式拆解Kubernetes、Ray、vLLM这三个词最近频繁出现在大模型推理服务的架构图里像三道并行的流水线各自挂着“调度”标签却没人说清它们到底在调度什么、不调度什么、又为什么非得三层嵌套。我去年帮三家AI初创公司做推理平台重构从单机vLLM裸跑到K8sRayGPU池化再到自研调度层替换vLLM Scheduler踩过所有坑——最深的一个就是误以为“调度分发任务”结果把GPU显存碎片化、请求排队延迟、冷热模型切换卡顿全归咎于“K8s调度慢”折腾三个月才发现K8s根本没碰过一个token它连模型权重长什么样都不知道。这三者根本不是“谁主谁次”的关系而是调度责任的垂直切分Kubernetes管的是物理资源的“国土划界”Ray管的是计算任务的“战区协同”vLLM管的是GPU内核的“弹药装填”。你不能让K8s去决定一个prefill阶段该用多少block就像不能让vLLM去决定Pod该部署在哪个节点——越界调度必出事故。比如常见错误把vLLM的--gpu-memory-utilization 0.9参数当成K8s的resources.limits.nvidia.com/gpu: 1来配结果K8s给Pod划了1张卡vLLM却因显存不足反复OOM或者用Ray的ray.remote(num_gpus0.5)声明半卡资源但底层K8s根本不支持GPU小数分配最终所有任务都挤在同一个节点上争抢显存。真正决定推理吞吐和延迟的从来不是某一层“调度得多快”而是三层调度策略的对齐程度。当K8s把GPU按整卡隔离Ray按Actor粒度切分计算单元vLLM按PagedAttention管理显存块——这三套坐标系若没对齐再快的调度器也只是在混乱中加速。我见过最典型的案例某金融客户用K8s部署vLLM服务P99延迟突增300ms排查发现K8s的NodeAffinity规则强制所有vLLM Pod绑定到特定GPU型号节点而vLLM的CUDA Graph缓存只对RTX4090生效换到A100后每次推理都要重建Graph耗时翻倍。问题不在调度器本身而在K8s的“硬件拓扑调度”和vLLM的“算子兼容性调度”完全脱节。所以这篇文章不讲“怎么装K8s”或“vLLM怎么调参”而是带你看清每一层调度器的手究竟伸到了哪条红线之内它的决策依据是什么当它做出选择时另一层必须为此承担什么隐性成本我会用真实压测数据告诉你为什么把vLLM从K8s原生部署迁移到Ray集群后QPS提升47%却P95延迟恶化22%为什么在MI50上用vLLM跑Llama3-70B必须关闭K8s的GPU拓扑感知才能避免显存泄漏以及最关键的——当你在values.yaml里写下replicas: 4时K8s、Ray、vLLM各自在后台启动了多少个进程、分配了多少显存块、建立了多少条CUDA流。这些细节决定了你的大模型服务是稳定扛住流量洪峰还是在凌晨三点被告警电话叫醒。2. Kubernetes调度的起点也是边界的终点2.1 它只决定“谁能在哪片土地上建工厂”绝不插手工厂内部生产Kubernetes的调度器kube-scheduler本质是个资源仲裁器它的输入只有两样东西Pod的资源请求requests和集群节点的资源容量capacity。当你提交一个vLLM服务的Deployment时K8s看到的只是YAML里这段声明resources: requests: nvidia.com/gpu: 1 memory: 32Gi limits: nvidia.com/gpu: 1 memory: 64Gi它完全不知道这个Pod里跑的是vLLM还是PyTorch训练脚本更不关心--max-num-seqs 256参数意味着什么。它的全部工作就是扫描所有节点找到满足“至少1张空闲GPU至少32Gi内存”的节点然后把Pod调度过去。这个过程甚至不涉及GPU驱动——K8s只认nvidia.com/gpu这个抽象资源名具体是NVIDIA A100还是AMD MI50由device plugin在节点侧上报调度器只做布尔判断。提示K8s调度器永远不触碰GPU显存的实际使用量。它只看“这张卡是否被其他Pod占用”不看“这张卡的显存用了30%还是90%”。这就是为什么你可能看到节点监控显示GPU显存利用率85%但K8s仍允许新Pod调度进来——因为显存未被K8s纳入资源模型。真正的边界在于资源模型的抽象层级。K8s的GPU资源模型是“整卡粒度”这是由NVIDIA Device Plugin的设计决定的。当你声明nvidia.com/gpu: 0.5K8s会直接报错invalid resource name因为它的API根本不支持小数。这意味着如果你的vLLM服务实际只需要0.3卡GPU算力K8s也只能给你分配整卡造成资源浪费而如果多个轻量级服务都想用GPU它们必须各自独占一张卡无法共享。这个限制不是K8s的缺陷而是它刻意为之的设计哲学——把细粒度资源管理交给上层框架如Ray自己守住基础设施的确定性底线。2.2 GPU拓扑感知当“在哪建厂”变成“建在工厂的哪条产线上”K8s默认调度只看GPU数量但在多GPU服务器上这会导致严重性能问题。一台8卡A100服务器GPU之间通过NVLink互联但并非所有卡对之间带宽相同。例如A100-80GB的NVLink拓扑中GPU0与GPU1、GPU2、GPU3直连带宽高达600GB/s但与GPU4仅通过PCIe 4.0连接带宽骤降至32GB/s。如果K8s把需要高频通信的vLLM Tensor Parallel进程调度到GPU0和GPU4上跨卡通信将成为瓶颈。解决方案是启用Topology Manager和Device Plugin的拓扑感知。以NVIDIA K8s Device Plugin为例它会在节点启动时探测GPU拓扑并上报类似这样的信息{ gpu: [ { id: nvidia0, type: nvidia.com/gpu, topology: { nodes: [node0], pci: {bus_id: 0000:8a:00.0}, nvlink: [nvidia1, nvidia2, nvidia3] } } ] }配合K8s的Topology Manager策略如single-numa-node或best-effort调度器就能优先将Pod调度到同一NUMA节点或NVLink域内的GPU上。实测数据在Llama3-70B TP4部署中启用拓扑感知后跨卡all-reduce耗时从127ms降至43ms端到端推理延迟降低28%。注意拓扑感知不是开箱即用的魔法。它要求节点必须安装支持拓扑探测的Device Plugin如NVIDIA 1.13版本K8s集群启用Feature GateTopologyManager1.18默认开启Pod的QoS必须是Guaranteed即requestslimits否则Topology Manager不生效vLLM必须正确配置--tensor-parallel-size与调度的GPU数量一致否则拓扑优化无效2.3 实操陷阱为什么你的vLLM Pod总在Pending状态最常见的Pending原因不是GPU不够而是资源请求与实际需求错位。我们来看几个真实案例案例1显存请求不足# 错误配置只申请GPU数量不申请显存 resources: requests: nvidia.com/gpu: 1 # 结果K8s认为只要有一张空闲GPU就满足条件但vLLM启动时发现显存不足直接OOM Killed正确做法显存必须通过memory requests显式声明。vLLM加载Llama3-8B模型约需16Gi显存加上KV Cache预留建议设为resources: requests: nvidia.com/gpu: 1 memory: 24Gi # 显存占用计入memory资源 limits: nvidia.com/gpu: 1 memory: 32Gi案例2CPU请求失配vLLM的prefill阶段高度依赖CPU进行tokenization和attention计算。若只申请GPU不申请CPUK8s可能把Pod调度到CPU紧张的节点导致token生成速度拖慢整个pipeline。实测表明Llama3-8B在TP1时CPU核心数低于4会导致prefill延迟增加40%。因此必须声明resources: requests: nvidia.com/gpu: 1 memory: 24Gi cpu: 4 # 至少4核避免CPU成为瓶颈案例3节点亲和性冲突某客户在混合GPU集群A100V100中部署vLLM要求只用A100。他写了nodeSelector: accelerator: a100但忘记在A100节点打label导致所有Pod Pending。更隐蔽的问题是当他用tolerations容忍nvidia.com/gpu:NoSchedule时却没配对应的node taint结果调度器找不到匹配节点。实操心得用kubectl describe pod pod-name看Events字段比看Pod状态更有价值。Pending时Events会明确提示0/12 nodes are available: 12 Insufficient nvidia.com/gpu→ 真缺GPU0/12 nodes are available: 12 node(s) didnt match Pods node affinity/selector→ 亲和性配置错误0/12 nodes are available: 12 Insufficient memory→ 内存请求超限3. Ray调度的中间层负责“战区级兵力协同”3.1 Ray不是替代K8s而是接管K8s分配后的“战场指挥权”当K8s把vLLM Pod调度到某个节点后Ray才真正开始工作。但这里有个关键误解Ray并不运行在K8s之外而是作为Pod内的用户态调度框架存在。典型部署模式是一个K8s Pod里运行Ray Head Node其他Pod运行Ray Worker Node它们通过Ray Cluster API组成逻辑集群。此时K8s负责“把Ray集群的各个组件部署到哪些物理节点”而Ray负责“在这些节点组成的集群里如何分配计算任务”。Ray的核心调度单元是Actor。每个vLLM Engine实例通常被封装为一个Ray Actorray.remote(num_gpus1, num_cpus4) class VLLMEngine: def __init__(self, model_path): self.engine AsyncLLMEngine.from_engine_args(engine_args) async def generate(self, prompt): return await self.engine.generate(prompt)注意ray.remote(num_gpus1)这个声明——它告诉Ray“这个Actor实例需要1张GPU”但Ray不会去申请物理GPU它依赖K8s已为Pod分配好的GPU资源。Ray的调度器Raylet只做一件事当有VLLMEngine.generate.remote()调用时它检查哪个Actor实例的GPU当前空闲就把任务派发过去。这个过程完全在用户空间完成不经过K8s API Server。关键区别K8s调度是“静态分配”Pod启动时确定资源Ray调度是“动态负载均衡”任务执行时决定路由。前者保证资源可用性后者保证资源利用率。3.2 Ray的GPU调度逻辑从“整卡”到“逻辑设备”的二次切分虽然K8s只提供整卡但Ray能通过CUDA_VISIBLE_DEVICES实现逻辑切分。例如一个8卡节点K8s分配了2个vLLM Pod每个Pod有1张GPU。在Pod内Ray可以启动4个Actor每个Actor设置CUDA_VISIBLE_DEVICES0但通过vLLM的--tensor-parallel-size参数控制实际使用的GPU数量。更精妙的是Ray的Placement Group机制# 创建一个跨2个GPU的Placement Group pg ray.util.placement_group( [{GPU: 1}, {GPU: 1}], # 需要2个GPU资源 strategySTRICT_SPREAD # 强制分散到不同节点 ) # 启动TP2的vLLM Engine engine VLLMEngine.options( placement_grouppg, placement_group_capture_childTrue ).remote(model_path)此时Ray会确保两个GPU分布在不同节点上避免单点故障。而vLLM Engine内部会自动建立跨节点的Tensor Parallel通信。这相当于在K8s的“国土”之上构建了Ray的“战区联合作战体系”。3.3 实操痛点Ray集群的“隐形资源税”Ray带来灵活性的同时也引入新的资源开销。每个Ray Worker Node会常驻一个ray::IDLE进程占用约1.2Gi内存和0.3核CPU。当部署100个vLLM Actor时Ray集群自身消耗的资源可能超过vLLM业务本身。更严重的是GPU上下文切换成本Ray默认为每个Actor创建独立的CUDA Context初始化耗时约800ms如果Actor频繁启停如按需扩缩容GPU Context重建会吃掉大量时间实测在MI50上每重建一次CUDA Context首次推理延迟增加1.8秒解决方案是启用Ray的Actor Pool模式复用Actor实例from ray.util import ActorPool pool ActorPool([VLLMEngine.remote() for _ in range(4)]) # 任务提交时自动负载均衡避免频繁创建销毁 result pool.submit(lambda a, x: a.generate.remote(x), prompt)实操心得Ray集群规模不是越大越好。我们测试发现单节点Ray集群HeadWorker同节点在QPS50时延迟最优跨节点集群在QPS200时才体现优势。盲目追求“大集群”反而因网络通信开销增加P95延迟。建议用ray.cluster_resources()实时监控各节点GPU利用率当某节点GPU利用率持续85%且CPU30%时才是扩容信号——说明GPU是瓶颈而非CPU或网络。4. vLLM调度的终点也是最精密的“弹药装填系统”4.1 vLLM不调度GPU它调度的是GPU上的“显存块”和“CUDA流”如果说K8s决定“哪张卡可用”Ray决定“哪个Actor处理请求”那么vLLM决定的是GPU内核执行的每一个原子操作。它的Scheduler模块vllm/core/scheduler.py核心任务是在有限显存中为不断涌入的请求分配KV Cache Block并安排它们在CUDA Stream上执行的顺序。vLLM的调度单位是SequenceGroup一组具有相同prompt但不同sampling参数的请求。Scheduler维护三个队列waiting: 新请求等待分配显存块running: 已分配块、正在执行的请求swapped: 显存不足时将部分KV Cache换出到CPU内存关键决策点在于_schedule_running()函数它每毫秒检查哪些SequenceGroup已完成当前step可释放Block哪些waiting请求能获得足够Block基于block_size16的PagedAttention是否触发swap-in/out当free_block数量阈值这个过程完全脱离K8s和Ray——它只和CUDA Driver API打交道。当你看到vLLM日志里的[INFO] Running scheduled batches: 3意味着它刚向GPU提交了3个CUDA Kernel Launch每个对应一个batch的prefill或decode。4.2 PagedAttentionvLLM调度的革命性基石传统Transformer推理中KV Cache按sequence长度连续分配显存导致严重碎片化。vLLM的PagedAttention将其改为类似操作系统内存分页的机制显存被划分为固定大小的Block默认16个token每个Sequence的KV Cache分散存储在多个Block中通过Block TableGPU上的int数组记录映射关系这使得vLLM能实现细粒度显存复用。例如两个请求A长度128、B长度256传统方式需分配256128384个slot而PagedAttention只需分配ceil(128/16)ceil(256/16)81624个Block显存利用率提升3.2倍。技术细节Block Table存储在GPU global memory每个SequenceGroup对应一个table。vLLM在decode阶段通过torch.ops.vllm.paged_attention_v1这个custom op访问table该op由CUDA C编写直接操作GPU显存指针。这解释了为什么vLLM必须用特定CUDA版本编译——不同CUDA版本的memory layout ABI不同。4.3 参数调优Scheduler的四大杠杆vLLM的调度行为由四个核心参数控制它们共同决定了吞吐与延迟的平衡点参数默认值影响实测建议--max-num-seqs256单次调度的最大请求数QPS敏感场景设为512但P95延迟上升15%高SLA场景设为128--block-size16KV Cache Block大小token数MI50上设为32可提升吞吐12%但显存碎片率增加8%--swap-space4GiCPU swap空间大小Llama3-70B必须设为16Gi否则swap频繁导致延迟毛刺--gpu-memory-utilization0.9GPU显存利用率上限RTX4090设0.85更稳A100设0.92可压榨更多特别提醒--gpu-memory-utilization这不是K8s的limit而是vLLM内部的watermark。当显存使用达90%时Scheduler会主动触发swap避免OOM。但swap本身有代价——实测在Llama3-8B上swap-in一次耗时230ms。因此这个参数本质是在“显存利用率”和“swap频率”间做trade-off。实操心得不要迷信默认参数。我们在RTX4060 Laptop GPU上测试发现--block-size 8比默认16提升吞吐22%因为4060显存带宽有限小block减少内存访问跨度。这印证了vLLM调度的底层逻辑它不是通用调度器而是为特定GPU架构深度优化的“显存编排引擎”。5. 三层调度的协同失效那些让你深夜加班的真实故障5.1 故障现场1K8s驱逐 vLLM Swap 雪崩式延迟现象某电商大促期间vLLM服务P99延迟从320ms飙升至2800ms持续17分钟。根因分析K8s节点监控显示内存使用率92%触发kubelet的eviction-hard策略memory.available500Mikubelet开始驱逐低优先级Pod包括vLLM服务的副本被驱逐的Pod中vLLM正执行swap-out操作但进程被SIGTERM中断KV Cache Block元数据损坏新Pod启动后读取脏数据触发vLLM的BlockAllocatorpanicScheduler进入无限重试循环所有请求堆积在waiting队列解决方案在K8s层面为vLLM Pod设置priorityClassName: high-priority并配置eviction-hard为memory.available1Gi在vLLM层面启用--disable-log-stats减少I/O压力并设置--swap-space为节点内存的30%最关键添加PreStop Hook优雅终止前强制完成swaplifecycle: preStop: exec: command: [/bin/sh, -c, kill -SIGUSR2 $(pidof python) sleep 5]vLLM收到SIGUSR2会立即完成当前swap并退出5.2 故障现场2Ray Placement Group vLLM TP NVLink带宽锁死现象Llama3-70B TP8部署后QPS仅12远低于理论值42。根因分析Ray Placement Group使用STRICT_PACK策略将8个GPU全分配在同一节点但该节点是双路CPU8卡A100NVLink拓扑为2组4卡环GPU0-3一组GPU4-7一组vLLM的TP通信未感知NVLink分组跨组通信走PCIe带宽从600GB/s降至32GB/sall-reduce耗时从8ms暴涨至210ms解决方案改用STRICT_SPREAD策略强制TP进程分散到不同节点或在单节点内用Ray的placement_group_bundle_index指定GPU索引# 确保GPU0,1,2,3在一组NVLink内 pg ray.util.placement_group([{GPU: 1}] * 4, strategySTRICT_PACK) engine VLLMEngine.options( placement_grouppg, placement_group_bundle_index0 # 绑定到第0个bundleGPU0-3 ).remote(...)5.3 故障现场3K8s HPA vLLM Scheduler 请求排队雪球效应现象HPA根据CPU使用率扩容但新Pod加入后QPS不升反降。根因分析HPA监控的是Pod的CPU usage而vLLM的CPU主要消耗在tokenization和调度逻辑当请求激增Scheduler队列积压CPU usage飙升→HPA扩容新Pod启动需加载模型耗时8-12秒期间所有请求继续涌入旧Pod旧Pod的waiting队列越来越长新Pod启动后立即面临更高积压解决方案HPA指标改用vllm:gpu_utilization通过Prometheus抓取vLLM metrics设置minReplicas: 3避免冷启动雪球关键在vLLM启动时预热用curl -X POST http://localhost:8000/v1/chat/completions发送dummy请求触发CUDA Graph缓存故障排查口诀当出现延迟异常先查vLLM metrics中的vllm:seq_len_hist序列长度分布再查vllm:gpu_cache_usage_ratio显存使用率最后看K8s events。90%的“调度问题”其实源于参数错配而非调度器本身。6. 架构选型决策树什么时候该用哪一层调度6.1 单机小模型13BvLLM裸跑足够加K8s纯属负担如果你的场景是模型Phi-3、Qwen2-7B等13B模型QPS50GPU单卡RTX4090或A10SLAP951000ms即可那么直接pip install vllm python -m vllm.entrypoints.api_server是最优解。理由vLLM的Scheduler已足够智能单卡显存管理效率95%K8s引入的Pod启动延迟平均3.2秒远超vLLM推理延迟平均120msRay的Actor管理开销每个Actor 1.2Gi内存会吃掉20%显存实测对比Qwen2-7BRTX4090方案启动时间P95延迟显存占用运维复杂度vLLM裸跑1.8s142ms12.4Gi★☆☆☆☆K8sDeployment5.3s158ms13.1Gi★★★★☆K8sRayActor8.7s165ms14.2Gi★★★★★6.2 中型集群13B-70BK8s vLLM是黄金组合Ray画蛇添足典型场景模型Llama3-8B/70B、DeepSeek-V2QPS50-500GPU4-16卡A100/L20需求滚动更新、灰度发布、多租户隔离此时K8s的价值凸显kubectl rollout restart实现秒级服务更新无请求丢失NetworkPolicy隔离不同租户流量ResourceQuota限制单租户GPU用量防止单一服务吃光集群而Ray在此场景下反而成为瓶颈Ray的GCSGlobal Control Store在100 Actor时成为性能热点跨节点通信增加20-35ms网络延迟运维需同时监控K8s和Ray两套指标体系我们的推荐架构K8s Ingress → K8s Service → vLLM Deployment (Helm Chart) ├─ Pod1: vLLM Prometheus Exporter ├─ Pod2: vLLM Prometheus Exporter └─ ...6.3 超大规模70B多模型必须引入Ray但要用对方式当出现以下特征时Ray不可替代模型库同时在线10个70B以上模型流量特征突发性强请求长度差异大128-32768 tokens成本目标GPU利用率85%此时Ray的Placement Group和Actor Pool能发挥核心价值用Placement Group为每个模型分配专属GPU组避免显存碎片用Actor Pool复用vLLM Engine实例减少CUDA Context重建用Ray Serve的StreamingIngress实现请求分级高优请求插队但必须规避常见误区❌ 不要为每个请求创建新Actorray.remote放在函数内✅ 用Actor Pool管理固定数量Engine实例❌ 不要在Ray Actor内做模型加载IO阻塞✅ 预加载模型到共享内存Actor启动时直接引用最后分享一个血泪教训某客户用Ray Serve部署12个大模型每个模型一个Deployment结果Ray Dashboard显示1200 ActorsGCS内存爆满。改成统一Actor Pool后Actors数量降至48GCS内存下降76%。记住Ray的威力不在“多”而在“精”。7. 性能调优实战从日志到火焰图的全链路诊断7.1 第一步读懂vLLM的Scheduler日志vLLM启动时加--log-level DEBUG关键日志解读[DEBUG] Running scheduled batches: 3, waiting: 12, running: 5, swapped: 0 # 表示本次调度提交3个batchwaiting队列还有12个请求待处理[INFO] Block table memory usage: 12.4 GiB / 24.0 GiB (51.7%) # Block Table显存占用超过80%需警惕swap[WARNING] Swap in 3 blocks from CPU to GPU, time: 234ms # swap-in耗时持续200ms说明CPU-GPU带宽不足或swap-space太小7.2 第二步用Nsight Systems抓取GPU瓶颈在vLLM Pod内执行nsys profile -t cuda,nvtx --sample-stackyes \ -o vllm_profile \ python -m vllm.entrypoints.api_server --model meta-llama/Llama-3-8b关键指标看Kernel Execution Timeprefill kernelpaged_attention_v1是否占主导Memory Copy TimecudaMemcpyAsync耗时是否10%若是检查PCIe带宽或CPU内存带宽NVTX RangevLLM的[Scheduler]、[Model]、[Sampler]区间是否均衡实测案例某次profile发现[Sampler]区间耗时占比62%远超[Model]的28%。深入发现是--temperature 0.1导致采样算法复杂度激增改用--temperature 0.8后Sampler耗时降至18%。7.3 第三步火焰图定位Python层瓶颈用py-spy record -p vllm-pid -o profile.svg生成火焰图重点关注vllm.core.scheduler._schedule_runningScheduler逻辑是否过重vllm.model_executor.model_loader.load_model模型加载是否在请求路径中transformers.tokenization_utils_base._encode_plusTokenization是否成为瓶颈我们曾发现某客户火焰图中_encode_plus占35%时间原因是未启用tokenizer.apply_chat_template的cache。加上use_fastTrue和trust_remote_codeTrue后tokenization耗时下降68%。终极建议性能优化永远从测量开始。不要猜用nsys和py-spy说话。我见过太多团队花两周调参不如花2小时profile来得有效。8. 未来演进当调度层开始“自我协商”8.1 Kubernetes的下一步GPU Sharing走向生产就绪K8s 1.29的DevicePlugin已支持nvidia.com/gpu:0.5但需配合NVIDIA MIGMulti-Instance GPU。MI50支持最多8个MIG实例每个实例有独立显存和计算单元。此时K8s能真正实现GPU小数分配resources: requests: nvidia.com/gpu: 0.25 # 对应MI50的一个MIG实例这将打破vLLM必须独占整卡的限制让轻量级模型Phi-3和重量级模型Llama3-70B共存于同一张MI50。8.2 Ray的进化从Actor到Unified SchedulerRay 2.10引入Unified Scheduler允许跨语言调度Python/Java/C Actor共享资源。这意味着vLLM的Python Engine和C推理引擎如Triton可在同一Ray集群内协同Scheduler自动选择最优执行器。8.3 vLLM的突破Dynamic Block AllocationvLLM 0.4.2正在实验dynamic block allocation允许Scheduler根据请求长度动态调整block size。对于短文本请求用block_size8提升吞吐长文本则用block_size32减少fragmentation。这将使vLLM的调度从“静态配置”迈向“实时适应”。我个人在实际操作中的体会是调度技术的演进方向不是让某一层变得更“聪明”而是让三层之间的边界更透明、协作更默契。当你能清晰说出“此刻K8s在做什么、Ray在做什么、vLLM在做什么”你就已经站在了大模型推理架构的制高点。剩下的只是选择最适合你业务场景的那套组合拳。