记录一次排查问题的经过——视频通话无法接起

前言

俗话说的好，人在家中坐，bug天上来，凯子哥端午假期直接拉满10天，他的bug就在我手里。

问题

唐桥云sdk集成了IM、音视频通话等功能。
我们开发的小程序 IM页面是webview内H5页面，小程序又集成了音视频通话等功能。
所以就有两个websocket通道(一个websocket建立IM通信，一个websocket建立webrtc通道<转发信令>)。
但是公司层面做了限制，这两个通道的建立不能使用相同appId，所以每次挂断之后重新跳转到新的IM webview内嵌H5页面(利用不同的appId)，但是多次正式发布还是没有效果，但是预发是正常的。

解决流程

预发是正常的，但是正式环境是不可以的，首先我们可以看下发布失败的原因，在发布平台并没有找出错误，我们直接登录正式环境服务器，找到相对应的项目项目log日志，但是在发布的那一段时间区间，我们从日志并没有看到特殊的报错。
也就是说并不是项目报错导致的打包失败，这也基本吻合我们的推断(预发环境没问题，线上有问题)，那可能是pm2有问题，我们看pm2的日志

pm2 log

直接报错如下：

node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by node)
node: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.16' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.17' not found (required by node)
node: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by node)

看到这个错误猜测，有可能是node环境的问题，执行 node -v，同样也是报这个错，那说明猜测没问题。这时候看下centos版本，centos6.7，那有可能是centos版本和node版本不兼容导致的。
ok，这时候我们去寻找node开发工程师雷哥

确定下来了，确实是centos版本太低，node版本太高导致的(包括我自己的服务器是centos7的好像也是因为版本低有一些问题，具体可以看我之前的文章，升级centos内核的)。
那为什么预发是可以的呢？因为预发使用的是容器，但是线上使用的是物理机，ok 我们去申请两台容器，不用物理机了，找个好说话的运维审核一下。

按照公司标配标准项目，申请2核4G的两个节点，申请成功后部署项目。部署成功后没有那个报错了。

ok 找运维 切流量，把nginx负载均衡的请求打到两个容器上+原来的主机上，我们 tail -200f xxx 看项目日志，已经有陆陆续续的流量打到容器了。

我们继续验证线上功能，没问题了，申请下掉主机。

收获

我在申请容器时，查看到其他大型项目的主机大多都是4核8G(多台)，询问了下后端大佬，我们目前前后端都讲究 分布式，即 多次中低配置服务器组成的服务器集群。这样做的原因是为了更好的容灾。

当然，说到容灾，联想到我们前端 node ssr也是做了降级的这种容灾处理，检测服务器请求量阈值，如果过大就自动由ssr降级为csr。
所以针对灾难处理，一定要做到多层防护，这个是相当重要的，直接和公司利润相关。

总结

centos版本过低会和node版本不兼容
熟悉linux的操作和nginx、pm2真的可以解决更多问题
分布式方案确实好，能容灾又便宜