如果是多家同时宕机,大概率是云服务提供商的锅,如果是这个原因,这几家应该都是同一底层云服务商吧。
另一个说法,是B站流量如滔天洪水,崩了以后大量的用户没地方去,跑到微博,知乎,a站,豆瓣,晋江等入口吐槽,然后其他几家没抗住,也崩了……
并不是说这些网站太弱,接纳不住这么多用户,而是技能树没点这个分支。
一般来讲,没有双十一秒杀场景的话,能够支撑同时在线的用户数足够即可,所以一般网站或APP不太需要“瞬时高并发”的处理和承载能力,但是昨天这种情况,就是瞬时高并发,类似微博突然爆了个大瓜,一般网站都没有应对这种突发流量的应对方案,所以就崩了。
B站股票先跌后涨,大家都看到B站流量之大,可以冲垮其他站点,用户粘性之强,接近凌晨依然有这么大的流量,未来可期。
谢邀。正准备刷视频,发现上不了,结果害我反复开关WiFi n次。
盲猜一下吧,我觉得应该是etcd挂了。
因为表现上是B站全部的业务都挂了,而且是几乎在一瞬间。服务器返回的错误大多数是502(Bad Gateway)。也就是前端的reverse proxy无法访问到upstream的服务器。
通常来说,能造成几乎所有请求都502的,要不就是前端和后端之间的网络通路全挂了,要不就是后端的服务全都挂了。
那么现在的大型互联网公司的基础设施是怎样的呢,大多数使用了kubernetes,实现全国各地的数据中心的容器编排、网络虚拟化等。
而kubernetes的设计上,网络插件和pod编排又是相对独立的。
如果只是网络插件出问题了,那么部分服务器上的网络插件的缓存还在,一定有部分用户还能正常使用。
如果只是pod编排除了问题,也是一样的道理。
现在所有的都挂了,那只能是etcd挂掉,导致反向代理无法通过etcd找到对应的pod的虚拟ip,有无法通过网络插件与对应的pod通信。
分析个皮,现在信息都是矛盾的
这它Mother的信息是完全矛盾的,或者发生时间至少不同。因为在骨干网(包括网络基础服务例如路由,dns),区域节点,云服务商,互联网企业间反复横跳。
这知乎的IT人员是真够水的,高赞几乎都在瞎掰。
以目前的信息量,只有在问题节点上的IT人员可能分析出来。总不能凭谣言传闻debug.
目前只有一点是确定的,B站自己的服务肯定出了问题,因为牙用了比较长的时间恢复。而其它企业恢复得比较快。不过,这特马可能也是错误信息。
AP被黑得最惨的一次
性能差?
那就来领教领教什么叫做性能!
内置16天线,10750M速率(你没看错,万兆),有线侧是2个万兆电口,1个万兆SFP+光口
当然价格嘛,那不是AP的缺点,是你的缺点。
==============================================
说正事,AP+AC指的是转发与控制分离的架构,MESH本意是指在AP之间采用网格状、自组网、自恢复的无线接力回传。企业级的APAC产品也可以采用MESH组网,就是调试比较麻烦,很少这么用而已。家用级别的支持MESH的套装路由器产品本质上来说就是一套预先调试好的低配版AC+AP,只不过没有单独的AC,而是根据启动顺序、优先级、网络中的位置等选举出一台设备执行AC的管理功能。
所以你是要怎么结合?用企业APAC做MESH?算了吧,你先要明白的是,网络的根本目的是服务终端设备,其自身采用什么方案应该根据你的现场实际情况,需求, 以及预算做一个综合考量。切勿本末倒置,一上来就考虑哪个方案好那个方案不好,还想着怎么结合。殊不知你的那点知识很多都是错的。
你要是比绥靖,比卖队友,比一将无能累死三军,比民众艰苦抗争统治阶级脑满肠肥,比前方吃紧后方紧吃,那二战时蒋光头统帅的中华民国尚有一战之力。
你比综合国力?对不起啊,就你那一年钢产量不足十万吨(1945年数据约12万吨,疑似因为收复了日本人的钢铁厂)的中华民国别说比英国啊,你连当时的印度往前退位了三十年的大清你都可能比不了啊!哦,对了,北宋一年的生铁产量都有可能比这个多!丢先人脸呢?