微服务为什么一定要用Docker？
发布网友
发布时间：2022-04-19 14:38
共5个回答
热心网友
时间：2023-12-09 13:06
早在2013年的时候，docker就已经发行，然而那会还是很少人了解docker。一直到2014年，Martin Fowler提出了微服务的概念，两个不相干的技术终于走在了一起，创造了今天的辉煌！
近几年来，很多互联网关系开始跟风，构建docker+微服务的架构体系。然而，根据笔者观察发现，有些童鞋在使用过程中，只是会用，而根本不了解为什么使用docker，反正对他们来说，公司让用就用！而某些公司呢，虽然用上了docker，然而运维方式并没有发生改变，白白浪费了docker的大好性能
过去:曾记得12年那会，部门要上一个项目。那会，我是这么干的。直接去线上服务器，拷贝一个tomcat，然后改端口号，然后部署应用到webapps文件夹下，重启就好。而且我可以摸着良心说，现在还有很多传统企业是这么做的。
那么这么做的缺点？
很明显，应用之间相互影响。一个应用出现问题，该应用把线程池给拖垮了，这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐。如果还采用这种部署方式，你的应用和某个坑爹团队的应用部署在了同一台服务器上，至于结果，我相信你懂的。
现在:用上了docker容器后，将Docker可以将我们的应用程序打包封装到一个容器中，该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离，在容器中的操作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形！
热心网友
时间：2023-12-09 13:06
这里必须要先说明物理机、虚拟机、容器三者的优缺点。笔者不想去列一堆的概念，直接借用知乎的一个回答
那么，专业的说法就是，容器是一种轻量级、可移植、自包含的软件打包技术，使应用程序可以在几乎任何地方以相同的方式运行。容器之间是共享同一套操作系统资源的，由于容器是共享主操作系统的内核，因此就无法在服务器上运行与主服务器不同的操作系统，也就是说不能再Linux的服务器上运行Windows。就如上面哪个图一样，每个胶囊容器是公用一个厕所，厨房，每个胶囊内无法再构建出自己的厕所和厨房！
容器的优势
隔离强
过去:曾记得12年那会，部门要上一个项目。那会，我是这么干的。直接去线上服务器，拷贝一个tomcat，然后改端口号，然后部署应用到webapps文件夹下，重启就好。而且我可以摸着良心说，现在还有很多传统企业是这么做的。
那么这么做的缺点？
很明显，应用之间相互影响。一个应用出现问题，CPU100%了，这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐。如果还采用这种部署方式，你的应用和某个坑爹团队的应用部署在了同一台服务器上，至于结果，我相信你懂的。
现在:用上了docker容器后，将Docker可以将我们的应用程序打包封装到一个容器中，该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离，在容器中的操作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形！
可移植性
过去:曾几何时我们和测试MM之间聊天内容是这样的
开发:"你去测试环境上，按照开发环境一样，再去搭三套一样的测试环境！"
测试:"我….."
几个小时过去了…
测试:"你帮我看看，为什么启动报错，是不是漏配了什么参数?"
开发:"我…."
于是接下来几个小时就这么愉快的和测试mm一起聊天中过去了！！嗯，我相信有些公司是为了解决开发的单身问题，才不使用docker,用心良苦!
然而，和运维GG之间聊天一般是这样的
运维:"开发这群脑残，发布的新war包，又把生产搞挂了！"
开发:"这帮运维傻叉么，我本地好好的，怎么一上生产就不行了！"
…
于是接下来的几个小时，就在和运维之间的撕*中过去了!嗯，最终苦的是用户啊！
现在:自从用上docker容器后，可以实现开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。
在现在微服务的架构中，一个应用拆成几十个微服务，每个微服务都对应有开发、测试、生产三套环境需要搭建。自己算算，如果采用传统的部署方式，有多少环境需要部署。曾听闻某公司在新建一个项目的时候，要花整整一个礼拜来搭建环境，简直是惨不忍睹!
什么，你和我说，你们用上了docker，却还存在这些问题？
笔者曾见过某些公司是这么用docker的。确实虚拟化出容器了，然后在容器上建立ssh server。接下来就厉害了，部署方式完全没变，直接连上容器，一切部署照旧！对此，我也是一言难尽啊！你们这是给领导搭的docker么？
轻量和高效
过去:在2016年的时候，那会在另一家大厂工作。这家稍微规范一点了，一个应用部署在一个虚拟机上！当时最大的体会就是一个，虚拟机非常重，构建速度慢，且占用资源多，一台物理机上只能起十来个虚拟机！
现在:
和虚拟机相比，容器仅需要封装应用和应用需要的依赖文件，实现轻量的应用运行环境，且拥有比虚拟机更高的硬件资源利用率。在微服务架构中，有些服务负载压力大，需要以集群部署，可能要部署几十台机器上，对于某些中小型公司来说，使用虚拟机，代价太大。如果用容器，同样的物理机则能支持上千个容器，对中小型公司来说，省钱！
热心网友
时间：2023-12-09 13:07
早在2013年的时候，docker就已经发行，然而那会还是很少人了解docker。一直到2014年，Martin Fowler提出了微服务的概念，两个不相干的技术终于走在了一起，创造了今天的辉煌！
近几年来，很多互联网关系开始跟风，构建docker+微服务的架构体系。然而，根据笔者观察发现，有些童鞋在使用过程中，只是会用，而根本不了解为什么使用docker，反正对他们来说，公司让用就用！而某些公司呢，虽然用上了docker，然而运维方式并没有发生改变，白白浪费了docker的大好性能
过去:曾记得12年那会，部门要上一个项目。那会，我是这么干的。直接去线上服务器，拷贝一个tomcat，然后改端口号，然后部署应用到webapps文件夹下，重启就好。而且我可以摸着良心说，现在还有很多传统企业是这么做的。那么这么做的缺点？
很明显，应用之间相互影响。一个应用出现问题，该应用把线程池给拖垮了，这个服务器上的其他应用一起凉凉。一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐。如果还采用这种部署方式，你的应用和某个坑爹团队的应用部署在了同一台服务器上，至于结果，我相信你懂的。
现在:用上了docker容器后，将Docker可以将我们的应用程序打包封装到一个容器中，该容器包含了应用程序的代码、运行环境、依赖库、配置文件等必需的资源。容器之间达到进程级别的隔离，在容器中的操作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形！
热心网友
时间：2023-12-09 13:07
他的理念就是把环境和应用程序打包在一起作为一个整体再进行部署。大多数情况下我们有一个服务器，可以部署很多应用，但是需要重新部署一套时怎么办，得安装服务器，考每个应用，改配置，很麻烦，现在docker把服务器一起给你打包了，然后再部署，当然不是部署在IIS或tomcat里面，而是部署在docker的管理服务程序里面。相当于在系统层和服务器层加了一层程序。
热心网友
时间：2023-12-09 13:08
因为这种服务可以隔离容器，使得应用之间不会相互影响
