容器和微服务
近几年微服务突然变火，其实跟容器有很大的关系。
第一容器够小，可以解决微服务独立部署的问题，解决微服务对机器数量的诉求。
第二容器独立，可以解决多语言的问题。
第三是开发环境与生产环境相同，针对非 Windows 开发者，如果使用容器技术，就比较容易使本机的开发环境与生产环境相同。Windows 开发者需要自己部署一台服务器，保持服务器跟线上相同。当一个公司里面有多语言时，有一个镜像就容易解决这个问题。
第四是容器效率高，省钱。
第五是代码和 image 一体化。简网以前以服务为核心，每个服务的管理体系比较难做，现在用 Docker 后可以把 image 做完，再把服务和 image 做一一对应后，管理就可以实现一体化。
第六是容器的横向扩展。容器很容易横向扩展，但纵向扩展对公司来说更有意义。从整个公司的层面来看，机器利用率并不好，这是一个客观存在的问题，当时的技术无法解决问题，因为要多少机器是业务决定的，运维并没有决策权。此时，可以把内存和 CPU 做一个动态调整，最初，可以调低一点，当增上来之后再进行扩容。
但是这样做仍然存在一些问题。
第一是 Image 管理问题，有很多服务做，但是谁真正有资格做 Image 管理呢?Image 镜像越来越多，如果开放给所有人，每发布一个升级就多一个镜像，那这是需要治理的。
第二是系统安全管理问题，在 KVM 里面套一个 Docker ，用 KVM 做隔离，这样做，不仅加强了安全性，又利用了 Docker 快速部署、快速开发微服务管理的体系，系统安全上，短期内无解，但在公司内部运用还可以。
第三是授权管理问题，授权管理很多时候是特指数据库，如果服务是有状态的，扩容的时候需要做数据库授权，这个授权的操作和管理是有难度的，特别是发布后发现系统有漏洞，管理的难度很高。
第四是系统成熟度问题，虽然现在 Docker 很火，但整体来说系统成熟度没有达到理想的状态，运用过程中多少会出现一些问题。
第五是社区成熟度问题，Docker 在两三年的时间内突然变热，但社区成熟度是需要时间沉淀的