近些年来，微服务被捧上了天，不会docker好像都不好意思说自己是后端研发。首先，docker究竟是什么玩意呢？我们可以把它看成虚拟机，能在一台服务器上隔离出若干个互不干扰的环境，还能限制资源的使用量。
我们先来瞧一瞧，没有使用docker容器部署应用的时候的场景：
hmdgb的公司开发了3个基于java8的web应用，然后部署，仅仅需要放三个jar包到服务器。然后突然某一次更新，其中一个服务出了一个严重的BUG，把整个服务器的资源吃光了，导致另外两个服务也无法响应。
随着hmdgb公司得力的运营推广，三个应用的用户量激增，单服务器已经无法应对。所以紧急扩展了5台服务器来支撑，这个时候，每次更新就需要操作5台服务器。虽然可以通过自动化脚本来自动部署，但是每次扩容，都带来复杂又不稳定的部署问题。
固定的扩容已经带来复杂的运维了，然后得力的运营同学还搞起来限时活动，每一次活动时刻，都需要扩充数倍服务器资源。但是每次活动前都需要手动扩充资源，活动结束后释放资源，对于一家普通企业是无法忍受的。
更可怕的事情还是来了，一个新的应用用了一个新的依赖包，但是该依赖包不兼容以前的版本的依赖包。旧应用又不能短时间迁移过去，新应用又不能降级依赖包。那么只好使用虚拟环境和新开服务器的解决方案了。但是对于分布式系统（简单的说就是多台服务器）来说，只能对不起运维同学了。
依赖包的问题还没摆平，研发部门又要拥抱微服务了，一个团队用一种语言，java6,7,8都出现了。然后python2，python3，php还各种版本。本来线下好好地，结果一放到服务器就各种错误。可怕的还因为测试环境，开发环境与生产环境有细微的差别，结果在生产环境出现了error，还难以发现。
这个时候，为了解决研发层面的这些问题，hmdgb决定使用docker容器部署应用。由于docker容器可以限制cpu和内存的使用，所以一个应用出了问题，仅仅影响到它所属容器。其它容器依旧可以正常响应，问题一解决。
然后docker支持容器编排，并且有docker swarm，mesos，k8s等跨服务器的编排工具。当配置好docker集群，当应用需要扩展的时候，编排软件自行部署到不同的服务器，自此问题二解决。
k8s已经支持配置cpu和内存阈值弹性自动伸缩实例，并且docker集群的扩展相对容易，因此问题3也解决。docker天生就是隔离文件的，所以一台服务器可以跑不同的容器，各个容器还可以基于不同的操作系统，什么应用之间依赖包相互影响的问题也解决了。
并且，开发，测试，生产都是基于同一个镜像，环境问题亦迎刃而解，从起不担心环境问题了。
hmdgb的一个朋友听说hmdgb成功全容器化部署应用解决了很多部署问题，还大大提高了研发效率，也很想把容器化引入自己的研发团队，但是又担心自己这边只是一个小团队，没能力驾驭容器化。对此，hmdgb提供了以下的建议：
第一步可以仅仅用docker保持线上和开发环境的一致性，本地代码调试基于的镜像跟线上保持一致，并且对于本地来说还可以基于vagrant打包virtualbox镜像（包含了docker环境的），那么新员工还可以省去了环境的配置。
第二步，部署应用，以前是上传jar，二进制等来部署的，现在变成基于docker镜像的部署。反正现在云服务商提供了镜像仓库服务，本地打包好上传，服务器直接拉取即可。
第三步，可以用一下docker compose来管理各个应用的容器部署
再进一步，可以部署自己的docker swarm集群，在此之前强力建议上CI持续集成来构建，部署应用
k8s或者mesos这种功能强大的，还是先不要上，当有那个需求的时候，团队已经能有对应的架构师来扛住了
https://baijiahao.baidu.com/s?id=1617292788361683642&wfr=spider&for=pc