上周五上午在我们将 .net core 博客站点由 docker swarm 自动驾驶改为 docker-compose 手动驾驶后, 依然发生了翻车, 意料之外的翻车事实告诉我们翻车与驾驶方式无关, 我们仿佛听到了响彻整个高速公路 docker swarm 的吼声 -- "这个锅, 我不背".
怀着错怪 docker swarm 的内疚心情, 我们重新分析了翻车原因, 对比了正常行驶与翻车时上高速的方式(切换流量以及添加服务器的时间点), 最终将怀疑的目前锁定在了汽车引擎的内部 -- 发动机气缸(服务器 CPU), 可能是因为我们对所用的这款阿里云制造的发动机气缸特性不太熟悉, 在上高速之前预热不够.
于是, 周五下午我们继续使用 docker swarm 自动驾驶系统, 但在驶入快速路的时候 (进入访问高峰之前), 就将发动机加到六缸(6 台 4 核 8G 服务器) 进行预热, 预热后的发动机在驶上高速后表现稳定, 在中途出现了小波动时加到了七缸(7 台服务器), 就这样用七缸发动机在高速上行驶了一个下午, 没有出现任何问题. 由于周五下午访问高峰的并发比周一至周四略低一些, 驾驶速度还没有达到飙车的级别, 所以虽然成功驾驶, 但我们不能确认 docker swam 能够自动飙车, 要等下周进一步验证.
周末我们稍微改造了一下车, 用 IMemoryCache 进一步节能降耗.
今天是周一, 一周的飙车又开始了, docker swam 这个非主流自动驾驶系统证明自己的机会来了.
今天早上在访问高峰来临之前, 我们直接用七缸发动机预热 (如果不用 docker swarm 部署, 也需要 7 台服务器), 当驶上比上周五更高的高速后(进入周一的访问高峰),docker swarm 表现出色, 高速飙车过程中, 发动机气缸(服务器 CPU) 运行平稳.
在今天下午的高速飙车中, docker swarm 自动驾驶更是稳如泰山.
事情证明了, 在我们目前这样的并发量级别, docker swarm 完全可以胜任司机工作.
终于走出翻车困境, 开启 docker swarm + .net core 的飙车之旅!
来源: https://www.cnblogs.com/cmt/p/11411809.html