微服务和容器之间是什么关系？

微服务是一种架构风格，是一种使用一套小服务来开发大型复杂软件应用的方式途径。
容器是一种运行时技术，允许许多应用以互相隔离的方式运行在虚拟机、物理机等之上。同时，分层的容器镜像技术、类似Kubernetes的容器编排技术等的出现，使得运维人员管理成百上千的应用实例变成了非常简单的一件事情。
所以可以看到，使用容器技术作为微服务架构的基础，是非常自然不过的选择。

刚接触容器的人，可以将容器与虚拟机类比来看，那么微服务是部署在容器中，或虚拟机中，或物理服务器中，都是可以的。
但是容器有其独特的优势，快速启停，独立进程等，可以弥补很多的微服务运维上的缺点，所以两者可以说是黄金搭档。
但是两者本身没有依赖性，都是独立的东西，只是两者的理念结合，会更加完美。

容器是一种新的软件交付方式，它把应用和其运行环境以一个标准镜像格式打包， 能保证应用及其运行环境的统一，并能在装有Docker环境上以容器方式运行，不管宿主机是什么环境

微服务是应用软件架构设计模式，推崇单一职责、服务自治、轻量通信和接口明确等原则， 基于此，容器可以比较好的配合使微服务易于开发和维护、按需伸缩等

现在一提到微服务，有很多人会想到容器技术（这里说到的容器技术是指docker）。那么微服务和容器之间到底有什么关系呢，我来简要和大家探讨下。先抛出结论：微服务和容器其实没有半毛钱关系。微服务理念出现的比容器技术要早很多，其理念是在70年代提出的。而容器技术是2013年才提出的，它最初是由一个叫做dotcloud的项目发展而来，后来改名叫做docker。基于微服务的思想开发应用程序是完全可以不用容器技术的，例如现在很流行的spring cloud和dubbo都是可以不使用容器技术来做开发实现的。从2017年开始很多人喜欢同时提到微服务和容器化，这主要是基于以下几个原因：（1）按照微服务的理念，如果使用容器作为基础设施，能够实现快速部署，快速迭代；（2）在云计算浪潮中，容器作为替代vm的基础设施受到大家的关注度更高；（3）k8s作为几乎实际默认的容器化平台标准，其集成了配置中心和注册中心，相当于天然的帮微服务架构解决了自己开发配置中心和注册中心的问题。在我看来，以上三个是促使在2017年度很多时候，大家会将微服务和容器技术一起谈论的重要原因，甚至有些公司直接将自己的新建的微服务应用部署在容器平台上。