传统的 ASP.NET Core MVC 应用程序的部署方法使其很难满足响应式伸缩扩展变化。
这使得存在两个问题较难解决:
- 如何在短期内快速增加服务器的容量。
- 在增加容量后的服务器满足了短期内的需求激增问题后，一旦需求高峰期过后，应用程序就不在需要增加的容量。
举个例子，在大型活动中扩展了 50 台服务器，活动结束后这 50 台服务器就不需要了。那么你就产生一个问题，如何去产能。
响应性问题
在实际工作运行中，大多数的 ASP.NET Core 应用程序均部署在 Internet Information Services（IIS）中,这使得在 Windows Server 上增加容量是一项重大决定，因为需要采购额外的硬件以及修改运行环境中对应的服务器。
其结果是 ASP.NET 应用程序只能努力提供恰到好处的容量来处理他们的工作量，要么遭受太多高峰时段的访问，但是容量很小（这会影响用户体验），或者高峰时段以外的容量太大（这会导致从而增加了运行应用程序的成本，并束缚了用于其他服务程序的容量。
Docker 如何解决响应性问题？
容器是围绕应用程序的轻量级打包工具，只提供足够的资源给应用程序的运行。在确保与其他容器隔离的同时运行应用程序。根据应用，单个服务器可以运行许多容器，而 Docker 提供了集成集群，称为swarm，它可以进行大规模的容器部署，而不需要对集群或配置进行任何特殊的修改或处理。通过容器的低资源需求和swarm的结合意味着，扩展容器化的 ASP.NET Core MVC 应用只需添加或删除容器即可。而且由于每个容器都是隔离的，所以将服务器中闲置的容量资源分配给其他应用程序的容器，可以动态的平衡集群的工作负载。
Docker 容器是虚拟机吗？
乍一看，容器看起来很像虚拟机，并且使用容器和虚拟机，即使它们以不同的方式工作。两者都可以缩放通过添加或删除实例创建应用程序，并且两者都可用于创建标准化环境用于运行应用程序。
但是，容器不是虚拟机。虚拟机提供了一个完全隔离的软件栈，包括操作系统。例如，一个单一的服务器可以用来运行混合的虚拟系统，比如说，一个服务器可以用来运行虚拟的机器，每台机器都可以是不同的操作系统，允许需要 Linux 和 Windows 中并排运行在不同的虚拟机上。
Docker 只隔离了单个应用，而服务器上的所有容器都是在服务器的操作系统中。这意味着，所有的应用程序都在 Linux 服务器上的 Linux 容器中运行，或者在 Windows 服务器上的 Windows 容器中运行。
由于 Docker 容器仅隔离应用程序，因此与虚拟容器相比，它们需要的资源更少，这意味着一台服务器可以运行比虚拟机更多的容器。
这个并不意味着运行容器的服务器可以整体上处理更多的工作，但是它确实可以用更少的资源去运行和处理更多较低级别操作系统的任务，毕竟它们多数都是重复的嘛。
对比
图中显示了 ASP.NET Core MVC 部署在 Docker 和传统虚拟机的对比，但它们的关键区别在于，Docker 提供了一些功能，使其能够轻松创建重复的容器，无需任何额外的配置，自动运行在一起，自动处理 HTTP 请求作为容器集群的一部分，让应用在工作集群中共享负载能力。
这一点，是和传统服务器部署存在云泥之别，而 Docker 之所以这么有用，是因为它解决了一致性和响应性的问题，以一种优雅的方式来解决，这是使用传统虚拟机难以实现的。
Docker 容器是有限制的
Docker 容器并不适合每个项目。容器最适合 MVC 应用程序，因为它们的工作方式是无状态，这样一个客户端的一系列 HTTP 请求可以由在不同容器中运行的应用程序实例来处理。但这并不意味着 MVC 应用程序不能有任何的状态数据，但它确实意味着需要存储状态数据，以便可以从任何容器中访问如通过使用数据库等。
