本文出自我的博客园&＃xff0c;地址《微服务为什么一定要用docker》
以及公众号《微服务为什么一定要用docker》
引言
早在2013年的时候&＃xff0c;docker就已经发行&＃xff0c;然而那会还是很少人了解docker。一直到2014年&＃xff0c;Martin Fowler提出了微服务的概念&＃xff0c;两个不相干的技术终于走在了一起&＃xff0c;创造了今天的辉煌&＃xff01; 近几年来&＃xff0c;很多互联网关系开始跟风&＃xff0c;构建docker&＃43;微服务的架构体系。然而&＃xff0c;根据笔者观察发现&＃xff0c;有些童鞋在使用过程中&＃xff0c;只是会用&＃xff0c;而根本不了解为什么使用docker&＃xff0c;反正对他们来说&＃xff0c;公司让用就用&＃xff01;而某些公司呢&＃xff0c;虽然用上了docker&＃xff0c;然而运维方式并没有发生改变&＃xff0c;白白浪费了docker的大好性能&＃xff01; 因此&＃xff0c;才有了本文的诞生。本文不会教你怎么去用什么docker的api&＃xff0c;毕竟官网document很全面&＃xff0c;而是去讲解docker的优点&＃xff0c;进而说明为什么适合微服务的架构&＃xff01;
正文
这里必须要先说明物理机、虚拟机、容器三者的优缺点。笔者不想去列一堆的概念&＃xff0c;直接借用知乎的一个回答&＃xff0c;回答地址为: https://www.zhihu.com/question/48174633/answer/229253704 这里借用一下这位大神的三张图&＃xff0c;他的回答就三张图&＃xff01;
基本概念
所谓的物理机就是下面这样的别墅
那么虚拟机机就是下面这样的套房
最后就是我们的容器&＃xff0c;就是下面这样的胶囊公寓
那么&＃xff0c;专业的说法就是&＃xff0c;容器是一种轻量级、可移植、自包含的软件打包技术&＃xff0c;使应用程序可以在几乎任何地方以相同的方式运行。容器之间是共享同一套操作系统资源的&＃xff0c;由于容器是共享主操作系统的内核&＃xff0c;因此就无法在服务器上运行与主服务器不同的操作系统&＃xff0c;也就是说不能再Linux的服务器上运行Windows。就如上面哪个图一样&＃xff0c;每个胶囊容器是公用一个厕所&＃xff0c;厨房&＃xff0c;每个胶囊内无法再构建出自己的厕所和厨房&＃xff01;
容器的优势
隔离强
过去:曾记得12年那会&＃xff0c;部门要上一个项目。那会&＃xff0c;我是这么干的。直接去线上服务器&＃xff0c;拷贝一个tomcat&＃xff0c;然后改端口号&＃xff0c;然后部署应用到webapps文件夹下&＃xff0c;重启就好。而且我可以摸着良心说&＃xff0c;现在还有很多传统企业是这么做的。 那么这么做的缺点&＃xff1f; 很明显&＃xff0c;应用之间相互影响。一个应用出现问题&＃xff0c;该应用把线程池给拖垮了&＃xff0c;这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务&＃xff0c;分别交由不同的团队开发&＃xff0c;不同团队之间水平参差不齐。如果还采用这种部署方式&＃xff0c;你的应用和某个坑爹团队的应用部署在了同一台服务器上&＃xff0c;至于结果&＃xff0c;我相信你懂的。
现在:用上了docker容器后&＃xff0c;将Docker可以将我们的应用程序打包封装到一个容器中&＃xff0c;该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离&＃xff0c;在容器中的操作&＃xff0c;不会影响道宿主机和其他容器&＃xff0c;这样就不会出现应用之间相互影响的情形&＃xff01;
可移植性
过去:曾几何时我们和测试MM之间聊天内容是这样的
开发:"你去测试环境上&＃xff0c;按照开发环境一样&＃xff0c;再去搭三套一样的测试环境&＃xff01;" 测试:"我....." 几个小时过去了... 测试:"你帮我看看&＃xff0c;为什么启动报错&＃xff0c;是不是漏配了什么参数?" 开发:"我...."
于是接下来几个小时就这么愉快的和测试mm一起聊天中过去了&＃xff01;&＃xff01;嗯&＃xff0c;我相信有些公司是为了解决开发的单身问题&＃xff0c;才不使用docker,用心良苦!
然而&＃xff0c;和运维GG之间聊天一般是这样的
运维:"开发这群脑残&＃xff0c;发布的新war包&＃xff0c;又把生产搞挂了&＃xff01;" 开发:"这帮运维傻叉么&＃xff0c;我本地好好的&＃xff0c;怎么一上生产就不行了&＃xff01;" ...
于是接下来的几个小时&＃xff0c;就在和运维之间的撕逼中过去了!嗯&＃xff0c;最终苦的是用户啊&＃xff01;
现在:自从用上docker容器后&＃xff0c;可以实现开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件&＃xff0c;可在开发、测试和生产环境上以容器来运行&＃xff0c;最终实现三套环境上的应用以及运行所依赖内容的完全一致。 在现在微服务的架构中&＃xff0c;一个应用拆成几十个微服务&＃xff0c;每个微服务都对应有开发、测试、生产三套环境需要搭建。自己算算&＃xff0c;如果采用传统的部署方式&＃xff0c;有多少环境需要部署。曾听闻某公司在新建一个项目的时候&＃xff0c;要花整整一个礼拜来搭建环境&＃xff0c;简直是惨不忍睹!
什么&＃xff0c;你和我说&＃xff0c;你们用上了docker&＃xff0c;却还存在这些问题&＃xff1f;
笔者曾见过某些公司是这么用docker的。确实虚拟化出容器了&＃xff0c;然后在容器上建立ssh server。接下来就厉害了&＃xff0c;部署方式完全没变&＃xff0c;直接连上容器&＃xff0c;一切部署照旧&＃xff01;对此&＃xff0c;我也是一言难尽啊&＃xff01;你们这是给领导搭的docker么&＃xff1f;
轻量和高效
过去:在2016年的时候&＃xff0c;那会在另一家大厂工作。这家稍微规范一点了&＃xff0c;一个应用部署在一个虚拟机上&＃xff01;当时最大的体会就是一个&＃xff0c;虚拟机非常重&＃xff0c;构建速度慢&＃xff0c;且占用资源多&＃xff0c;一台物理机上只能起十来个虚拟机&＃xff01;
现在: 和虚拟机相比&＃xff0c;容器仅需要封装应用和应用需要的依赖文件&＃xff0c;实现轻量的应用运行环境&＃xff0c;且拥有比虚拟机更高的硬件资源利用率。在微服务架构中&＃xff0c;有些服务负载压力大&＃xff0c;需要以集群部署&＃xff0c;可能要部署几十台机器上&＃xff0c;对于某些中小型公司来说&＃xff0c;使用虚拟机&＃xff0c;代价太大。如果用容器&＃xff0c;同样的物理机则能支持上千个容器&＃xff0c;对中小型公司来说&＃xff0c;省钱&＃xff01;
笔者注&＃xff1a;笔者一直觉得这个特性只是一个障眼法。 比如&＃xff0c;你说容器启动速度快&＃xff1f;难道你工作中吃饱了撑着没事干&＃xff0c;一直重启虚拟机么&＃xff1f; 你说虚拟机消耗资源多&＃xff1f;绝大部分公司的服务器资源利用率应该都不到 50%&＃xff0c;大量的CPU、内存、本地磁盘都是常年浪费的&＃xff0c;所以 虚拟机 的额外开销不过是浪费了原本就在浪费的资源罢了。所以笔者认为&＃xff0c;对于传统应用来说&＃xff0c;使用和不使用Docker可能并不能直接给企业带来好处&＃xff0c;相反使用中遇到了问题肯定会给企业带来麻烦&＃xff0c;对于传统企业来说&＃xff0c;不要盲目跟风&＃xff0c;VM虚拟机其实够用了&＃xff01;。
总结
在技术演进中&＃xff0c;docker只是趋势&＃xff0c;并不是结果。相信在未来&＃xff0c;一定有更高大上的部署架构出现!
京公网安备 11010802041100号