(相关资料图)

1.物理主机

1.1.以前数据中心硬件就是建立在单个物理机器的高可靠性上的

1.2.如今通过足够多的主机保证各个服务的负载均衡，使得单台主机的损失不再是灾难性的

1.2.1.希望每台主机都尽可能便宜

1.2.2.数据中心的硬件设备都是一次性的消耗品

2.数据中心的虚拟机

2.1.应用程序并不会直接在硬件上运行，21世纪初的虚拟化浪潮将直接在物理机器上运行软件的方式淘汰了

2.2.虚拟化不利的一面是系统性能的可预测性不强

2.2.1.所有虚拟机相互争夺资源，并且会随机地变慢，而“客户机操作系统”几乎不可能监控到这一点

2.3.当将应用程序设计为在虚拟机上运行时，必须要确保任何一台主机的损失或减速都不会对其造成影响

2.3.1.分布式编程技术需要整个集群的同步响应才能继续发挥作用

2.3.2.密切注意集群管理器或资源锁管理器等“特殊”的机器，除非存在无须重新配置即可取而代之的另一台机器

2.3.3.留心应用程序对请求或事件发生顺序的依赖

2.3.3.1.没有人会将其设计到系统中，但这种依赖可能会意外地蔓延到系统中

2.4.虚拟机使得所有有关时钟的问题都变得更糟

2.4.1.不要相信操作系统的时钟

2.4.2.如果人类使用的时间很重要，可以使用类似本地网络时间协议服务器等外部时间来源

3.数据中心的容器

3.1.永远不会再问生产环境是否与QA环境一致这样的问题

3.2.提供进程隔离和虚拟机封装技术，以及开发人员容易掌握的构建过程

3.3.任何单个容器的“身份”都很短暂，因此，不应该基于每个容器实例来配置

3.4.容器没有太多的本地存储空间

3.4.1.应用程序必须依靠外部存储系统存储文件、数据甚至是缓存

3.5.所有的证书授权信息都必须提供给容器

3.6.联网问题

3.6.1.默认情况下，容器不会在主机上暴露任何端口

3.6.1.1.在其自身的虚拟网络接口上暴露

3.6.2.有选择地将端口从容器转发到主机

3.7.确保在正确的机器上运行足够多的正确类型的容器实例

3.7.1.它们启动时间非常快（是毫秒级而不是分钟级）

3.7.2.意味着容器实例将会像一团团小泡沫一样在主机上时隐时现

3.8.Kubernetes、Mesos和Docker Swarm这样的软件包可以解决容器实例的联网和分配调度问题

3.9.调试正在容器中运行的应用程序非常困难

3.9.1.容器化的应用程序更需要将其“遥测”监控数据发送到数据采集器集中处理

4.12要素应用程序

4.1.指明了各种潜在部署障碍

4.1.1.为解决各种障碍提供了参考方案

4.2.基准代码在版本控制系统中只有一份，每个版本只构建一次二进制包，并将其部署到各个环境中

4.3.显式声明依赖关系

4.4.在环境中存储配置信息

4.5.把后端服务当作附加资源

4.6.严格分离构建和运行

4.7.以一个或多个无状态进程运行应用程序

4.8.通过端口绑定提供服务

4.9.通过进程模型进行扩展

4.10.快速启动和优雅终止可最大化稳健性

4.11.⑩让开发环境、预发布环境和生产环境尽可能一致

4.12.⑾将日志视为事件流

4.13.⑿将后台管理任务当作一次性进程运行

5.云上的虚拟机

5.1.云原生系统将具有更好的运维特性，尤其在可用性和成本方面

5.2.云上的虚拟机还与其他虚拟机共享物理主机，并可能与之争夺资源

5.2.1.无论时间长短，都会遇到虚拟机毫无征兆死机的情况

5.3.机器“身份”的短暂性

5.3.1.每次虚拟机启动时其IP地址都会更改

5.3.2.需要从亚马逊那里租用弹性IP地址

6.云上的容器

6.1.在云上虚拟机中运行的容器，同时继承了容器和云带来的挑战

6.2.这些容器构建成一个整体的系统，从某种意义上讲，容器的使用将复杂性这口“锅”，从容器内部甩给了控制层

免责声明：以上内容为本网站转自其它媒体，相关信息仅为传递更多信息之目的，不代表本网观点，亦不代表本网站赞同其观点或证实其内容的真实性。如稿件版权单位或个人不想在本网发布，可与本网联系，本网视情况可立即将其撤除。