Kamailio和OpenSIPS的性能魔力：解锁高并发环境下的速度与稳定

1. 为什么你的SIP服务器在高并发时“掉链子”？

做VoIP或者实时通信系统的朋友，估计都遇到过这样的场景：用户量一上来，系统就开始卡顿，呼叫失败率飙升，监控面板上的延迟曲线像坐过山车一样。你可能会怀疑是网络问题，或者是后端媒体服务器（比如FreeSWITCH）扛不住了，但排查一圈下来，发现 信令服务器 ——也就是Kamailio或OpenSIPS——才是真正的瓶颈所在。

我自己在搭建一个企业级呼叫中心时，就踩过这个坑。初期测试一切正常，可一旦模拟上千个并发呼叫，Kamailio的响应速度就直线下降，甚至出现进程僵死。当时的第一反应是加机器、做集群，但成本立马就上去了。后来才发现，问题根源在于 默认配置根本不是为了高并发而设计的 。这就好比给你一辆F1赛车，却用城市道路的限速和保养规则去开，根本发挥不出性能。

Kamailio和OpenSIPS，这对同源（都源自SER项目）的“兄弟”，本质上是 纯信令代理 。它们不处理媒体流（RTP），专精于SIP消息的路由、负载均衡、注册、鉴权等。这种设计让它们极其高效、轻量，单机理论上能处理每秒数万甚至十万级的呼叫请求（CPS）。但“理论上”这三个字很关键，要达到这个性能，离不开精细化的调优。

高并发瓶颈通常出现在几个地方：

1. 网络I/O ：默认的UDP/TCP连接处理方式，在连接数暴涨时成为瓶颈。
2. 内存管理 ：不当的共享内存、哈希表大小设置，会导致锁竞争激烈或内存碎片。
3. 进程模型 ：如何利用多核CPU？是单进程多线程，还是多进程？策略选错，性能天差地别。
4. 数据库交互 ：频繁的用户鉴权、位置查询，如果每次都直连数据库，延迟和数据库压力会拖垮整个系统。
5. 脚本逻辑 ：路由脚本里一个低效的正则匹配，或者不必要的数据库查询，在放大一万倍后就是灾难。

接下来的内容，就是我结合多年实战，从系统到架构再到代码，为你梳理的8大性能优化策略。这些不是纸上谈兵，而是我在真实生产环境中验证过、能实实在在帮你把并发处理能力提升一个数量级的方法。

2. 系统层调优：打好地基，释放硬件潜力

在调整Kamailio/OpenSIPS任何一个参数之前，我们必须先确保它运行的操作系统“身强体壮”。很多性能问题，根源在于操作系统默认限制太保守。

2.1 突破文件描述符与网络连接限制

这是最基础也最重要的一步。一个SIP连接（尤其是TCP/TLS）就会占用一个文件描述符。Linux系统默认给单个进程的文件描述符限制（ ulimit -n ）通常是1024，这在高并发下瞬间就会用完。

操作步骤：

1. 修改系统全局限制 ：编辑 /etc/security/limits.conf ，在文件末尾添加：

   * soft nofile 655360
   * hard nofile 655360
   * soft nproc 655360
   * hard nproc 655360
   

   这会将所有用户的文件描述符和进程数软/硬限制提高到655360。对于专用服务器，这个值可以设得更高。
2. 修改进程级限制 ：对于使用systemd的服务，编辑Kamailio/OpenSIPS的service文件（如 /etc/systemd/system/kamailio.service ），在 [Service] 部分添加：

   LimitNOFILE=655360
   LimitNPROC=655360
   

3. 优化网络内核参数 ：编辑 /etc/sysctl.conf ，加入或修改以下关键参数，然后执行 sysctl -p 生效。

   # 增大TCP连接队列，应对突发连接
   net.core.somaxconn = 4096
   net.ipv4.tcp_max_syn_backlog = 4096
   # 启用TCP快速回收和重用，加速连接处理
   net.ipv4.tcp_tw_reuse = 1
   net.ipv4.tcp_tw_recycle = 1 # 注意：在NAT环境下慎用此参数，可能引起问题
   net.ipv4.tcp_fin_timeout = 30
   # 增加系统端口范围
   net.ipv4.ip_local_port_range = 1024 65535
   # 优化内存分配，应对大量小数据包（SIP消息通常很小）
   net.core.rmem_default = 262144
   net.core.wmem_default = 262144
   net.core.rmem_max = 16777216
   net.core.wmem_max = 16777216
   net.ipv4.tcp_rmem = 4096 87380 16777216
   net.ipv4.tcp_wmem = 4096 65536 16777216
   # 禁用IPv6（如果不需要），减少内核开销
   net.ipv6.conf.all.disable_ipv6 = 1
   net.ipv6.conf.default.disable_ipv6 = 1
   

实测效果 ：仅仅做完文件描述符和基础网络调优，我在一台4核8G的测试机上，Kamailio的TCP并发连接处理能力就从最初的不足2000提升到了8000以上，且稳定性大增。

2.2 多核CPU利用：选对进程模型

Kamailio和OpenSIPS都支持多种进程模型来利用多核CPU，但策略不同，选错了事倍功半。

Kamailio的多进程策略： Kamailio默认采用 非对称多进程（AMP）模型 。主进程（一个）负责管理，子进程（多个）负责处理SIP消息。关键在于，你需要明确指定子进程的数量和类型。 在 kamailio.cfg 的 mp 模块参数中配置：

# 启动4个UDP接收进程
mpath="mp"
children=4
# 在 socket 模块中绑定，让所有子进程共享监听套接字
socket=udp:0.0.0.0:5060
socket=tcp:0.0.0.0:5060

更精细的控制可以使用 fork 模式，为不同协议指定不同数量的进程：

# 在 kamailio.cfg 的全局部分
children=4
tcp_children=8  # TCP连接需要更多进程来处理连接状态

核心要点 ：UDP是无状态的，进程数可以设置为CPU核心数或2倍。TCP是有状态的，每个连接需要独立的文件描述符和上下文，因此 tcp_children 需要设置得更大，我通常设置为 (最大预期连接数 / 1000) + 核心数 ，并监控进程负载动态调整。

OpenSIPS的多进程/多线程策略： OpenSIPS在2.x版本后，强化了多线程支持。其架构更偏向于 多进程+内部工作线程池 。 在 opensips.cfg 中配置：

# 启动进程数，通常等于CPU核心数
children=4
# 使用工作线程池处理耗时操作（如DNS查询、数据库操作）
# 这能防止阻塞主消息处理循环
mpath="mi_fifo"
mpath="tm"
mpath="sl"

OpenSIPS的 dispatcher 和 load_balancer 模块在集群环境下，其内部状态同步机制在不同进程模型下的性能差异很大。如果使用“共享内存”模式，要特别注意锁的争用。我的经验是，在超过16核的服务器上，可以考虑将OpenSIPS拆分为多个实例，通过前端负载均衡器（如LVS）分发流量，而不是一味增加单个实例的进程数。

踩坑提醒 ：盲目增加进程数不一定能提升性能，反而可能因为进程间切换（context switch）和锁竞争导致性能下降。务必使用 top -H 或 pidstat 监控每个进程的CPU利用率，确保负载均衡。

3. Kamailio核心配置优化：让每一份资源都用在刀刃上

调好了系统，我们进入Kamailio的核心配置文件 kamailio.cfg 。这里面的每一个模块加载和参数设置，都直接影响性能。

3.1 内存与哈希表优化：减少锁竞争

Kamailio大量使用共享内存来存储用户位置（ usrloc ）、事务（ tm ）、对话（ dialog ）等信息。默认的哈希表大小可能很快成为瓶颈。

优化 usrloc 模块 ：用户位置表是访问最频繁的区域之一。

# 在 kamailio.cfg 的 modparam("usrloc", ...) 部分
modparam("usrloc", "db_mode", 0) # 使用0（仅内存）或1（写透缓存）。高并发下，强烈建议先用0，通过定时脚本同步到DB。
modparam("usrloc", "hash_size", 2048) # 哈希桶大小。这个值应该是预期最大在线用户数的2倍以上，以减少哈希冲突。例如10万用户，设为262144。
modparam("usrloc", "mem_cache", 1) # 启用内存缓存，加速查找。

优化 tm 模块 ：事务管理模块，处理INVITE、BYE等事务状态。

modparam("tm", "hash_size", 4096) # 根据并发事务量调整。每秒1万CPS，平均通话时长60秒，则并发事务约60万，hash_size可设为1048576。
modparam("tm", "disable_6xx_block", 1) # 禁用对6xx响应的阻塞，加速事务结束。
modparam("tm", "fr_timer", 5) # 快速重传定时器，默认5秒，在低延迟内网可适当调小，如2秒，加快超时处理。

优化 sl 模块 ：统计回复模块。

modparam("sl", "bind_tm", 1) # 让sl模块与tm模块绑定，减少消息传递开销。

3.2 关键模块与路由脚本优化

禁用不必要的模块 ：每加载一个模块都有开销。如果你不用 presence （在线状态）、 auth_radius ，就不要加载它们。

路由脚本的精简与高效 ： 路由脚本是性能的关键。避免在脚本中进行昂贵的操作，尤其是在 request_route 中。

• 使用 $var 代替 $avp ：如果变量只在当前消息处理中使用，用 $var （临时变量）而非 $avp （持久化属性值对），后者需要更多内存管理开销。
• 慎用正则表达式 ： regex 或 pcre 匹配非常消耗CPU。如果只是简单的前缀或后缀匹配，用 strncmp 、 strstr 或Kamailio自带的 @pm 或 @pmatch 等快速匹配操作符。

  # 低效
  if (uri =~ "^sip:10\.") { ... }
  # 高效（假设检查以“sip:10.”开头的URI）
  if ($rU =~ "^10\.") { ... }
  # 或者使用前缀匹配
  if ($rU == "10.") { ... } # 注意：`==` 操作符用于前缀匹配
  

• 异步化耗时操作 ：对于DNS查询、数据库写入（如CDR记录），尽量使用Kamailio的异步机制，如 async 模块，或者通过 event_route 在事务结束后处理，避免阻塞主处理流程。

  # 在事件路由中异步写入CDR
  event_route[E_CALL_ENDED] {
      $var(cdr) = "call from " + $fU + " to " + $rU + " duration: " + $DLG_time;
      # 通过消息队列或HTTP异步发送到CDR服务器
      rest_post("", "$var(cdr)", "$var(resp)");
  }
  

4. OpenSIPS核心配置优化：聚焦事务与对话管理

OpenSIPS的配置哲学与Kamailio略有不同，其 opensips.cfg 脚本更结构化，一些性能优化点也各有侧重。

4.1 进程、内存与定时器调优

进程配置 ：

# opensips.cfg 开头部分
children=8
# 对于TCP，可以设置更多监听进程
tcp_children=16
# 设置监听队列，应对突发连接
tcp_accept_priority=yes
listen=udp:0.0.0.0:5060
listen=tcp:0.0.0.0:5060

共享内存优化 ：OpenSIPS的共享内存区域用于存储对话（ dialog ）、注册表（ usrloc ）等。通过 shm_* 参数调整。

# 在 opensips.cfg 的全局参数部分
shm_hash_size=2048  # 共享内存哈希表大小
shm_force_alloc=yes # 启动时预分配所有共享内存，避免运行时动态分配带来的延迟和碎片。

定时器优化 ：OpenSIPS内部有很多定时器（如注册过期、对话超时）。调整定时器进程的唤醒频率可以平衡精度和CPU消耗。

# 调整定时器粒度，默认是1秒。如果对注册过期不要求秒级精确，可以设为2或4秒，减少锁竞争。
timer_grp=2

4.2 对话（Dialog）与负载均衡模块优化

dialog 模块 ：这是OpenSIPS管理通话状态的核心。不当配置会导致内存泄漏或性能下降。

modparam("dialog", "dlg_match_mode", 1) # 对话匹配模式。1=按Call-ID、From tag、To tag精确匹配，性能最好。
modparam("dialog", "default_timeout", 86400) # 默认对话超时，根据业务设置。太短会过早清理，太长浪费内存。
modparam("dialog", "db_mode", 0) # 与Kamailio类似，高并发下优先使用内存模式。
modparam("dialog", "track_cseq_updates", 0) # 如果不依赖CSeq严格序列控制，可以关闭以提升性能。

dispatcher 模块 ：这是实现负载均衡的核心。其算法选择直接影响后端媒体服务器的利用率。 OpenSIPS的 dispatcher 模块支持多种算法（ round-robin , weight , call-load , pstn 等）。在高并发场景下， call-load （基于当前呼叫数）通常比简单的 round-robin 更均衡。

modparam("dispatcher", "db_url", "mysql://opensips:password@localhost/opensips")
modparam("dispatcher", "table_name", "dispatcher")
modparam("dispatcher", "force_dst", 1)
modparam("dispatcher", "flags", 2) # 设置标志，例如2表示使用基于权重的负载均衡。
# 在路由脚本中使用
if (!ds_select_dst("2", "4")) { # 使用算法2（call-load），分组4
    send_reply("503", "Service Unavailable");
    exit;
}

关键技巧 ：将 dispatcher 的目标集（destination set）缓存到共享内存中，避免每次查询数据库。可以通过 dispatcher_reload 命令或MI接口在目标服务器状态变化时动态更新。

5. 数据库与缓存策略：告别IO等待

无论是用户鉴权 ( auth_db )、位置查询 ( usrloc )，还是拨号规则 ( dialplan )，频繁的数据库查询都是性能杀手。

5.1 连接池与读写分离

数据库连接池 ：确保Kamailio/OpenSIPS使用连接池连接数据库，而不是为每个请求新建连接。

# Kamailio 示例 (db_mysql 模块)
modparam("db_mysql", "pool_size", 10) # 连接池大小
modparam("db_mysql", "max_async_connections", 20) # 最大异步连接数
# OpenSIPS 示例 (db_mysql 模块)
modparam("db_mysql", "conn_pool_size", 10)

连接池大小并非越大越好，需要根据数据库服务器（如MySQL）的 max_connections 和服务器内存来设置。通常起始值为 (核心数 * 2) + 磁盘数 。

读写分离 ：将实时性要求不高的数据（如CDR话单、历史注册记录）写入到单独的从库或日志库，减轻主库压力。可以在路由脚本中根据SQL操作类型选择不同的DB URL。

5.2 内存缓存与防穿透

使用 cachedb 模块 ：这是性能提升的“银弹”。将频繁读取、极少变动的数据（如用户权限、路由规则、黑名单）缓存到Redis或Memcached中。

# Kamailio 加载 cachedb_redis
loadmodule "cachedb_redis.so"
modparam("cachedb_redis", "cachedb_url", "redis://localhost:6379/")
# 在路由脚本中使用缓存
if (cache_fetch("redis:user_auth_$fU", $var(auth_result))) {
    # 缓存命中
    if ($var(auth_result) == "1") {
        # 认证通过
    }
} else {
    # 缓存未命中，查询数据库
    $var(auth_result) = sql_query("SELECT password FROM subscriber WHERE username='$fU'");
    cache_store("redis:user_auth_$fU", "$var(auth_result)", 300); # 缓存300秒
}

缓存防穿透与雪崩 ：

• 防穿透 ：对于不存在的用户查询，也缓存一个空值或默认值（如 "NULL" ），并设置一个较短的过期时间（如30秒），防止恶意攻击反复查询数据库。
• 防雪崩 ：为缓存键设置随机的过期时间偏差（例如 300 + random(30) ），避免大量缓存同时失效，导致数据库瞬时压力过大。

6. 负载均衡算法进阶：从“轮询”到“最闲”

默认的轮询（Round Robin）算法简单，但在后端服务器处理能力不均或呼叫时长差异大时，容易导致负载不均衡。我们需要更智能的算法。

6.1 理解不同算法的适用场景

• Round Robin (RR) ：最简单，适用于服务器配置完全一致、呼叫类型单一的场景。
• Weighted Round Robin (WRR) ：根据服务器权重分配流量，适用于服务器配置不同的场景。
• Least Connections (LC) / Call-Join-Shortest-Queue (CJSQ) ：将新呼叫分配给当前活动呼叫数最少的服务器。这比RR更合理，是OpenSIPS dispatcher 和 Kamailio dispatcher 模块的常用算法。
• Transaction-Least-Work-Left (TLWL) ：这是更高级的算法，它不仅考虑活动呼叫数，还考虑不同事务类型（如INVITE和BYE）的资源消耗权重。研究表明，处理一个INVITE事务的资源消耗远大于BYE事务。TLWL算法能更精确地评估服务器“剩余工作负载”，实现最优分配。虽然Kamailio/OpenSIPS原生模块未直接提供TLWL，但可以通过 dispatcher 的目标状态检测和自定义脚本逻辑来近似实现。

6.2 在OpenSIPS中实现基于响应时间的动态权重

我们可以结合 dispatcher 和 statistics 模块，实现一个简单的基于后端服务器响应时间的动态负载均衡。

1. 为每个 dispatcher 目标设置一个初始权重。
2. 在路由脚本中，使用 ds_next_dst() 尝试下一个目标时，记录失败或超时。
3. 通过MI（Management Interface）或Event Interface，定期（如每10秒）计算每个目标的平均响应时间或失败率。
4. 根据计算结果，动态更新 dispatcher 目标集的权重（使用 ds_set_state 或 ds_update ）。

# 伪代码逻辑示例
route[DISPATCH] {
    $var(start_time) = $Ts;
    if (!ds_select_dst("2", "4")) {
        $var(selected_dst) = $du;
        # 记录失败
        update_stat("dst_failures_$var(selected_dst)", "+1");
        send_reply("503", "Service Unavailable");
        exit;
    }
    # 转发请求...
    t_on_reply("REPLY_HANDLER");
    route(RELAY);
}
onreply_route[REPLY_HANDLER] {
    $var(rsp_time) = $Ts - $var(start_time);
    # 记录该目标的响应时间到统计变量
    update_stat("dst_rsp_time_$du", "$var(rsp_time)");
}

然后，用一个外部脚本定期读取这些统计变量，计算健康分数，并通过MI命令 ds_set_weight 动态调整权重。

7. 网络与安全优化：保障高效与稳定

高并发下，网络处理和安全检查也可能成为瓶颈。

7.1 TCP与TLS连接优化

TCP连接复用 ：对于出局TCP连接（如转发到后端媒体服务器），启用连接复用可以大幅减少TCP三次握手和TLS协商的开销。 在Kamailio中，确保 tm 模块参数 tcp_connection_lifetime 和 tcp_connection_idle_timeout 设置合理，以允许连接池保持活跃连接。

modparam("tm", "tcp_connection_lifetime", 3600) # 连接最大存活时间
modparam("tm", "tcp_connection_idle_timeout", 300) # 空闲连接超时

TLS会话复用与加速 ：如果启用了SIPS（TLS），务必配置会话票证（Session Ticket）或会话ID复用，以减少昂贵的TLS握手。

# Kamailio tls 模块
modparam("tls", "session_cache", 1)
modparam("tls", "session_id", "your_server_name")

考虑使用硬件SSL加速卡，或者在操作系统层面使用 ssl_engine （如OpenSSL的异步模式）来卸载TLS加解密计算。

7.2 防攻击与限流

高并发系统也是DDoS攻击的重点目标。必须在性能优化时兼顾安全。

• pike 模块 ：用于检测和限制来自单一IP的请求频率，防止洪水攻击。

  loadmodule "pike.so"
  # 检测到每秒来自同一IP超过50个请求，则阻塞该IP 60秒
  modparam("pike", "sampling_time_unit", 1)
  modparam("pike", "reqs_density_per_unit", 50)
  modparam("pike", "remove_latency", 60)
  

• htable 模块 ：实现更灵活的自定义限流。例如，针对某个被叫号码进行限速。

  # 在路由脚本中
  if ($sht(rate_limit=>$rU) > 10) {
      xlog("L_ERR", "Rate limit exceeded for $rU\n");
      send_reply("429", "Too Many Requests");
      exit;
  }
  $sht(rate_limit=>$rU) = $sht(rate_limit=>$rU) + 1;
  # 设置过期时间，例如1秒后清零
  $shtex(rate_limit=>$rU) = 1;
  

8. 监控、压测与持续调优：让优化成果可视化

优化不是一劳永逸的，需要建立监控和压测闭环。

8.1 构建关键性能指标监控

• 系统层面 ：CPU使用率（特别是用户态）、内存使用、网络带宽、TCP连接状态（ ESTABLISHED , TIME_WAIT ）、打开文件数。
• Kamailio/OpenSIPS层面 ：
  • 核心统计 ：使用 kamcmd 或 opensipsctl 工具获取 core 模块的统计信息，如接收/发送消息数、错误数、当前活跃事务/对话数。
  • 模块统计 ：监控 tm （事务）、 sl （回复）、 usrloc （用户位置）、 dialog （对话）等模块的计数器和内存使用。
  • 自定义统计 ：利用 statistics 模块在脚本中埋点，记录关键路由路径的处理时长、特定错误码的出现频率等。
• 数据库层面 ：监控连接数、慢查询、锁等待。

推荐将监控数据接入Prometheus + Grafana，实现可视化仪表盘和告警。

8.2 使用SIPp进行科学压测

SIPp是开源SIP压测的黄金标准。设计科学的测试场景至关重要。

1. 基准测试 ：模拟最简单的注册+呼叫流程，逐步增加并发用户数（UAC）和呼叫速率（CPS），找到系统的最大吞吐量和响应时间的拐点。
2. 稳定性测试 ：以最大吞吐量的70%-80%的负载，进行长时间（如24小时）压测，观察内存是否泄漏，性能是否下降。
3. 异常测试 ：模拟网络抖动、后端服务器宕机、畸形SIP包等场景，测试系统的容错和恢复能力。

一个简单的SIPp呼叫场景XML示例片段：

<scenario name="Basic UAC">
  <send retrans="500">
    <![CDATA[
      INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
      From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
      To: sut <sip:[service]@[remote_ip]:[remote_port]>
      Call-ID: [call_id]
      CSeq: 1 INVITE
      Contact: sip:sipp@[local_ip]:[local_port]
      Max-Forwards: 70
      Subject: Performance Test
      Content-Type: application/sdp
      Content-Length: [len]
      v=0
      o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
      s=-
      c=IN IP[media_ip_type] [media_ip]
      t=0 0
      m=audio [media_port] RTP/AVP 0
      a=rtpmap:0 PCMU/8000
    ]]>
  </send>
  <recv response="100" optional="true"/>
  <recv response="180" optional="true"/>
  <recv response="200" rtd="true">
    <action>
      <ereg regexp="Contact: <sip:(.*)>" search_in="hdr" assign_to="dummy,remote_contact"/>
    </action>
  </recv>
  <send>
    <![CDATA[
      ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
      From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
      To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
      Call-ID: [call_id]
      CSeq: 1 ACK
      Contact: sip:sipp@[local_ip]:[local_port]
      Max-Forwards: 70
      Content-Length: 0
    ]]>
  </send>
  <pause milliseconds="30000"/> <!-- 通话保持30秒 -->
  <send retrans="500">
    <![CDATA[
      BYE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
      From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
      To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
      Call-ID: [call_id]
      CSeq: 2 BYE
      Contact: sip:sipp@[local_ip]:[local_port]
      Max-Forwards: 70
      Content-Length: 0
    ]]>
  </send>
  <recv response="200" rtd="true"/>
</scenario>

压测时，要密切关注之前设置的各项监控指标，特别是Kamailio/OpenSIPS的共享内存使用情况、各进程CPU占比，以及系统TCP重传率。根据压测结果，回头调整前面提到的各项参数，如哈希表大小、进程数、超时时间等，进行迭代优化。

性能优化是一场永无止境的旅程，尤其是在业务量不断增长的情况下。这8大策略是一个系统性的框架，从底层系统到上层应用，从内部配置到外部架构。我的经验是，不要试图一次性应用所有优化，而应该遵循“测量 -> 优化 -> 再测量”的科学方法，每次聚焦一个瓶颈点，验证效果后再进行下一步。记住，最适合你业务场景的配置，才是最好的配置。