Docker在公有云的应用处理能力

通过今年的公有云调研发现，通过容器技术将旧有或新业务进行打包，并在云上进行部署，已经成为当前企业关注的热点。然而在写稿之前又收到一个消息，“Kubernetes 中已弃用了 Docker 支持”!在震惊之余，又感到可以理解，毕竟开源是当前软件开发的大趋势，而Docker由开源项目变成公司商标，甚至连鲸鱼logo使用也需要授权的状态，实在与开源软件的宗旨大相违背。也真是由衷的佩服Docker，明明有很多种活法，但非要活成令人讨厌的样子，既然让人讨厌，就别怪被人踢到一边了。

即便让人讨厌，也并不妨碍企业在生产环境中，大量使用经典 Kubernetes+ Docker 方案，同时在一些业务场景中也有单独使用 Docker 的情况。未来即使Docker可能会被抛弃，但是通过容器镜像将应用打包，并在云上进行业务部署的趋势，并不会因此受到过大影响。毕竟Docker也仅仅是Linux容器的一种打包应用方式。去掉Docker部分直接对Linux容器进行调用，对于未来容器应用部署而言未必是一件坏事。

然而利用容器将应用进行打包后，在公有云平台上进行部署，是否会对应用处理能力产生过大影响呢?为了了解这个问题，至顶网懂云帝继续沿用2019年公有云Web应用测试方案，对十大公有云厂商云主机上部署由Docker打包的Web应用性能同样进行了测试。

在本次测试中，同样采用在服务器端，用ab同时保持50个用户访问(ab参数-c 50)并建立1万连接和间隔数分钟后再发起同时保持50个用户访问并建立10万连接的方式，对公有云主机上用Docker部署的Web应用通过高并发的方式进行应用处理能测试。并选用Apache AB所提供的请求速率Requests/s结果进行统计。在得出测试结果后，再与去年公有云主机Web应用测试结果相比对，看一下通过Docker镜像打包后，Web应用的最大处理能力是否出现下降，对比结果如下：

不出所料的是，通过Docker将应用进行打包，在公有云主机上进行部署后，应用处理性能或多或少都会有所下降。但其中下降最严重的Azure云主机，居然从去年的87.97-92.67下降到了37.16-36.83，Web应用性能下降了一倍还不止。这样的结果就有些难以令人理解了。

此外还有UCloud，Web应用性能非但没有下降，反而还有大幅度的提升。询问原因有以下两点，一是UCloud对云主机上容器处理性能进行了大幅优化，另一个原因是去年是对UCloud云主机Braodwell的CPU进行的测试，但今年云主机CPU已经换成了Cascadelake，处理性能也比去年有所增长。

不过从横向对比测试结果来看，即便在今年选择处理器中，其他家也基本选择的是最新Cascadelake处理器，但UCloud云主机的Docker处理性能依然处于最高水平，可见其Docker应用优化，确实是卓见成效。

Docker在公有云上部署，应用处理的性能还会有所降低，那么容器的优势到底是什么?举个我们在云主机上部署的例子，大家就很容易理解了。

今年虽然受到疫情的影响，但是至顶网的业务却反而比去年更加饱满。不然作者也不会在2020跨年的时间，还在辛苦的赶着测试的稿子。今年的公有云测试，也是我们懂云帝几个抽空挤时间来完成的。但是和19年进行公有云主机环境搭建时完全不同。那时候，是我催着乐乐同学，找时间搭一下公有云测试环境。而今年是他主动催我来做测试。并不是因为乐乐同学的事情少，而是因为在Docker下搭测试环境实在是太简单了。

某位同学只需要把云主机建起来之后，把上面这几行代码一粘贴，然后就可以催着我做测试了。这也是头一次让我见识到搭测试环境比跑测试的时间还短的情况。

由此可知，在如此便捷的应用部署能力面前，少许应用处理性能的损失，就显得那么的微不足道了。当然微软的Azure云部署应当除外，但我相信Azure也应当会很快将这个问题给解决一下的。

在原定计划中，还有一项通过Kubernetes对公有云上Docker进行管理的体验，可惜(xing hao)还没找到时间进行，就已经传来“Kubernetes 中已弃用了 Docker 支持”的消息。于是在2020年的公有云测试中，将不再进行Docker的管理控制能力测试了，但是未来容器的将如何进行发展，我们懂云帝还是会继续进行关注。在新的2021年将会邀请一些技术专家一起进行一下座谈，好好探讨一下Docker模式的未来前景，容器技术未来将如何发展，企业应用要如何才能通过容器更好的将业务进行打包，并在云端部署。

总而言之，充满坎坷的2020年已经过去了，在充满希望的2021年，我们相信万事皆有可能!