软件定义基础架构、微服务和容器正在逐渐改变数据中心的构建和运行方式，未来的数据中心将会更加高效并且易于使用。
软件定义基础架构、微服务和容器是当前IT领域最为热门的话题，这些技术对数据中心的构建和运行方式产生了颠覆式影响，并且能够提升系统性能、弹性以及易用性。数据中心正在从传统的死板架构转换为更加灵活和快速响应的全新架构，甚至成为快速资源分配的发起者。
软件定义基础架构的概念并不复杂。比如，通过软件定义数据位于存储中的哪个部分，之后创建一个全新VLAN，将代码移动到虚拟机中形成一系列微服务。这些微服务能够被随意扩展或者缩减。虽然底层的存储或者交换机硬件非常简单，但是标准API架构允许多个厂商之间的微服务同其他任何类型的设备进行通信。事实上，这种方式实施起来有些困难，仍在研究中。
可以将不同微服务组合在一起以实现特定目标，尽管现在相关标准仍在开发过程中，但是这种组合机制将会很快投入使用。在实际环境中，应用程序可能请求某项服务，如果当前没有可用服务，那么系统将会触发生成新的副本。
Hypervisor还是容器?
理想情况下，不断自我复制的微服务能够一直保持可用状态，但是实际操作过程中，使用hypervisor创建虚拟机、在虚拟机上加载微服务镜像，之后启动所有这些组件，整个过程需要花费数分钟时间。相比于计算所花费的时间来说，这几分钟过于漫长了。
而容器能够作为这种敏捷性问题的解决方案。由于容器运行在现有的虚拟机之上，因此无需加载或启动操作系统镜像。而且容器只需要占用非常小的内存空间。更为重要的是，容器中的微服务可以在几微秒之内完成启动过程。
Hypervisor和容器在操作时间上的差异对于敏捷性来说至关重要，容器在存储或者网络微服务中完成特定任务只需要几秒钟时间，因此如果使用hypervisor，那么系统开销占比以及负载等待时间都将受到严重影响。
不断压缩的物理空间也是一个重要问题，超融合系统需要和应用程序以及存储共享计算资源。这还是一种负载问题：容器只需要几MB的系统开销，而hypervisor实例则需要数GB。如果使用容器技术，那么微服务不会占用服务器的大量空间。
微服务和容器所带来的挑战
在容器中快速创建和销毁微服务对网络性能同样提出了挑战。通常，这些微服务需要连接到远程微服务或者实际存储设备。为了能够和LAN集群兼容，存储之间的互联必须通过以太网，如果使用光纤通道还需要创建新的层次，而且不能满足软件定义基础架构的特性，因此全以太网平台更加易于管理。
另外一项任何软件定义基础架构系统都需要面临的挑战是如何发布微服务，可以使用编排工具完成这项任务。比如当前存在多种可用压缩算法，应用程序必须从其中找到最佳算法以及可以从哪里获取相关服务。短期来看，这种方式可能不够灵活，但是编排工具能够不断提升整个过程的灵活性。
微服务+容器架构的安全问题和应用+容器架构的一样多。有人可能会抱怨微服务能够访问VLAN结构和存储，事实上，在任何环境中这种情况都会引发相关安全问题。现在，容器技术推出的多种机制能够保证其在防止内部租户攻击方面像hypervisor一样安全，但是容器的绝对数量以及其创建和销毁速度对于资源控制和微服务的签名验证都提出了很高要求。
软件定义基础架构、微服务和容器将会引发数据中心革命，它们之间既相互独立，又需要相互配合。最终目标应该是IT环境更加易于使用，并且由租户运行、而不是由IT部门精心配置，在资源使用方面总体上更加灵活和高效。
本文作者：Jim O'Reilly
来源：51CTO
