一次大型线上直播活动，程序高并发 线上炸 随即感悟

因为之前一直在做grpc和graphql，做过许多测试，也和http做过很多比较一直相信并且认可grpc的通信方式，虽然它也是基于http但是相比http，二进制的传输方式，还是相当快。

最近疫情比较严重，公司和教育局做了一个直播活动邀请抗疫前线人员做了一次直播课程，因为是晚上8点开课，在7点55的时候，小程序就开始出现无法登陆的情况，已登录的在直播间看课正常，在腾讯云上看部署nginx和网关的服务器，cpu已经100%，于是将网关迁移到另一台服务器上，这回cpu降了，但是登陆还是不行，查看docker日志，程序一直在运行，也没有奔溃，但是登陆还是一直返回不到数据。在重启登陆的docker程序之后，短暂的恢复，但是不久又炸了。。。。。查看登陆日志，grpc之间的通讯时间40多秒，然后一群人就开始说通讯方式出现问题，说grpc出现堵塞，虽然自己蛮不服的，但是也无力反驳，因为时间就在那摆着。。。。你说什么也无济于事，真的当时确实对grpc有些失望，因为我也是一个谷吹，一下崩了，别人又说这技术不行，确实心里比较难过，一个半小时的直播，只有2000多人成功进来直播间，其余好几万人都没进来，而且有一部分是因为没登陆上。。。。。真的贼揪心。。。不是一般的难过，可能就是因为有的时候你太信任一个人，突然它背叛了你那种感觉吧（这里指grpc吧）。因为我也是一个比较喜欢和别人炫耀技术的人。

直播结束后，一群人反思了一下。老大也打电话了解了一下情况，然后也说grpc可能有原因，但是究其原因还是服务器进来请求后，文件读取速度，以及linuex内核，还有一些其他的问题吧，导致高并发出现的发送请求后，响应不能迟迟到达，在高并发情况下原因有很多吧，明天继续讨论总结经验吧。。。

这次有一些小小的感悟吧，一个人或者一些人认定的东西，不太好改变，只要有问题，他们都会说到是不是你引进来的这个新技术引起的。改变别人的思路比较难，说服别人认同一个东西也比较难，有些东西无需多言自己知道就可以了。。。

从来没经历过几万人同时想要访问你程序，但是你程序崩了，你无力恢复的这种情况，这次虽然崩了，但是也算是长个见识吧。

多学习基础知识，多了解自己的技术，和他们用的成熟的东西有什么优势，不然你都说不清楚原因，出了问题都是你的锅。

今天心态不太好，也比较烦吧。想吐槽一下，说的也比较乱，想到啥说啥，算是做个一日总结吧。