系统层次划分
任何一个系统按照逻辑部署维度都可以划分成应用层与基础设施层，开发的应用软件还有使用第三方的应用可以抽象成一些组件的集合，为了运行这些组件需要基础设施层来提供支撑，基础设施层有物理机、存储、虚拟机、容器这些元素。
基础设施层中最基本的是物理机，随着技术的发展慢慢出现了虚拟机和容器。
我们先来看看基础设施架构的演进。
基础设施架构演进
基础设施架构不是一步到位的事情，是需要循环渐进不断完善，随着系统复杂度的提升和业务发展不断的演进。接下来我们以Ngnix+web+db这样最基础的架构看看一个系统的基础设施从简单到复杂的演变的过程：
一台主机运行多个组件
在系统上线初期用户量比较小，对系统的可用性要求也比较低。这样我们可以将所有组件都部署在一台主机上。
一台主机运行一个组件
随着系统业务发展，系统有了性能方面的要求，这时候就需要独立部署，一个组件部署到一台机器上，每台机器的配置也不尽相同，比如数据库和web服务器配置会更高点。
一个组件运行在多台主机上
随着业务的继续发展，系统有了可用性方面的要求，这时候就需要将组件进行多实例部署，每个实例部署在不同的机器上，通过集群软件来支持主备切换，这样就形成了既保证性能又保证可用性的架构。
主机有多台，每台运行多个组件，有负载均衡和主备切换机制
随着系统复杂度的提升，部署的组件越来越多。如果再采用一台机器部署一个组件的话会导致运营成本上升过快，考虑到资源成本这时候就会考虑交叉式的部署架构。一台机器部署多个组件，但是他们之间是交叉进行部署。这样既保证了组件有多实例又保证了任何一台机器挂了的话最少还有一个实例能提供服务。
一个组件用一台虚拟机运行，一台物理机运行多个虚拟机
物理机的性能相对都比较高，如果一台物理机只部署几个组件实际上是对物理机的浪费。为了提高物理机的资源利用率这时候我们将物理机拆分成虚拟机来对外提供部署能力。
一台物理机首先划分出若干个虚拟机，这些组件分别部署在这些虚拟机里。这样就实现了资源的充分利用也提升了系统的可用性还有运维的便利度。
一个组件用一个容器运行，一台物理机上运行多个容器
再往后我们可以将虚拟机替换成容器实现，容器是更轻量的技术，使用容器可以有更高的资源使用率
这就是一个系统基础设施演进的过程，当然这些方案并不是说只能选择其中一种，可以根据实际场景组合使用，演变成既有物理机也有虚拟机、容器的混合状态。
基础架构核心问题
基础设施原则上是解决组件到运行环境的映射问题，基础设施架构需要考虑下面十个方面的核心问题：
主机硬件配置
需要选择什么样的配置来支撑组件部署？
主机与组件的对应关系
主机与组件之间是什么关系？哪些组件部署在哪些主机上？
主机管理
如何管理这些主机？
组件管理
如何管理众多的组件？
环境隔离
不同开发环境之间如何隔离？
资源隔离
一个组件占用太多资源的话势必会导致其他组件资源变少？如何给组件分配合适的资源？
总体资源利用率
系统的利用率是否处在一个合理的状态？
性能
部署架构下各个组件的性能是否能得到保障？会不会出现瓶颈？
可用性
主机挂了系统的可用性能否得到保障？
成本
如何在有限的预算下去支撑所有组件的运行，或者说是能否通过一些好的设计去节省预算？
