近些年来，微服务被捧上了天，不会docker好像都不好意思说自己是后端研发。首先，docker究竟是什么玩意呢？我们可以把它看成虚拟机，能在一台服务器上隔离出若干个互不干扰的环境，还能限制资源的使用量。

我们先来瞧一瞧，没有使用docker容器部署应用的时候的场景：

哈二的公司开发了3个基于java8的web应用，然后部署，仅仅需要放三个jar包到服务器。然后突然某一次更新，其中一个服务出了一个严重的BUG，把整个服务器的资源吃光了，导致另外两个服务也无法响应。
随着哈二公司得力的运营推广，三个应用的用户量激增，单服务器已经无法应对。所以紧急扩展了5台服务器来支撑，这个时候，每次更新就需要操作5台服务器。虽然可以通过自动化脚本来自动部署，但是每次扩容，都带来复杂又不稳定的部署问题。
固定的扩容已经带来复杂的运维了，然后得力的运营同学还搞起来限时活动，每一次活动时刻，都需要扩充数倍服务器资源。但是每次活动前都需要手动扩充资源，活动结束后释放资源，对于一家普通企业是无法忍受的。
更可怕的事情还是来了，一个新的应用用了一个新的依赖包，但是该依赖包不兼容以前的版本的依赖包。旧应用又不能短时间迁移过去，新应用又不能降级依赖包。那么只好使用虚拟环境和新开服务器的解决方案了。但是对于分布式系统（简单的说就是多台服务器）来说，只能对不起运维同学了。
依赖包的问题还没摆平，研发部门又要拥抱微服务了，一个团队用一种语言，java6,7,8都出现了。然后python2，python3，php还各种版本。本来线下好好地，结果一放到服务器就各种错误。可怕的还因为测试环境，开发环境与生产环境有细微的差别，结果在生产环境出现了error，还难以发现。

这个时候，为了解决研发层面的这些问题，哈二决定使用docker容器部署应用。由于docker容器可以限制cpu和内存的使用，所以一个应用出了问题，仅仅影响到它所属容器。其它容器依旧可以正常响应，问题一解决。

然后docker支持容器编排，并且有docker swarm，mesos，k8s等跨服务器的编排工具。当配置好docker集群，当应用需要扩展的时候，编排软件自行部署到不同的服务器，自此问题二解决。

k8s已经支持配置cpu和内存阈值弹性自动伸缩实例，并且docker集群的扩展相对容易，因此问题3也解决。docker天生就是隔离文件的，所以一台服务器可以跑不同的容器，各个容器还可以基于不同的操作系统，什么应用之间依赖包相互影响的问题也解决了。

并且，开发，测试，生产都是基于同一个镜像，环境问题亦迎刃而解，从起不担心环境问题了。

哈二的一个朋友听说哈二成功全容器化部署应用解决了很多部署问题，还大大提高了研发效率，也很想把容器化引入自己的研发团队，但是又担心自己这边只是一个小团队，没能力驾驭容器化。对此，哈二提供了以下的建议：

第一步可以仅仅用docker保持线上和开发环境的一致性，本地代码调试基于的镜像跟线上保持一致，并且对于本地来说还可以基于vagrant打包virtualbox镜像（包含了docker环境的），那么新员工还可以省去了环境的配置。
第二步，部署应用，以前是上传jar，二进制等来部署的，现在变成基于docker镜像的部署。反正现在云服务商提供了镜像仓库服务，本地打包好上传，服务器直接拉取即可。
第三步，可以用一下docker compose来管理各个应用的容器部署
再进一步，可以部署自己的docker swarm集群，在此之前强力建议上CI持续集成来构建，部署应用
k8s或者mesos这种功能强大的，还是先不要上，当有那个需求的时候，团队已经能有对应的架构师来扛住了

https://baijiahao.baidu.com/s?id=1617292788361683642&wfr=spider&for=pc