1.3 云原生基础架构

云原生基础架构是隐藏在抽象背后的由软件管理并由API进行控制的基础架构，它的目标是运行应用系统。这也就兴起了一种新的管理模式——通过这些特性以可扩展、高效的方式进行基础设施管理。有用的抽象是具有重要意义的，它可以让开发者专注于自己的业务而无须了解底层、实现底层，更可以避免重复实现底层。

由软件来管理基础架构是与云的一个关键区别。软件控制的基础架构使得基础架构能够扩展，也就实现了资源弹性处理、资源置备和资源可维护。这种软件管理基础架构的模式不仅影响了基础架构的管理和运行，也影响了在其上运行的应用系统，从系统架构到系统开发、部署、运维都有了重大变化。

云原生基础架构不仅仅是在公有云上运行基础架构，也不是在容器中运行应用程序，所以公有云和容器化不是云原生基础架构的代名词。但是云原生基础架构可以借助容器化技术和公有云技术去实现。公有云仅仅是IaaS层的实现，一般的公有云还是要借助人力去申请、分配。而云原生基础架构则是用程序代码自动去申请。容器仅仅是应用程序的一种打包方式，这并不意味着这些应用程序具备自治功能。即使应用程序是通过持续集成和持续交付等DevOps流水线自动构建和部署的，也并不一定就是云原生基础架构。

Kubernetes也不能简单地称为云原生基础架构。Kubernetes的容器编排技术为云原生基础架构提供了必要的平台支撑功能。是否是云原生基础架构的关键在于是否使用自动化处理的方式。例如在Kubernetes中手工分配物理卷，就不能称为云原生基础架构，因为物理卷不是自动分配的。而如果使用动态卷，依靠卷声明来分配容量，进而分配使用该卷的容器，则满足了云原生基础架构的要求。

云原生应用对基础架构的基本要求有：

● 运行时间和隔离。

● 资源分配和调度。

● 环境隔离。

● 服务发现。

● 状态管理。

● 监测和日志记录。

● 度量聚合。

● 调试和追踪。

云应用程序肯定会依赖一个或多个服务来提供业务价值。提供一种让服务在每个环境的基础上找到彼此的方法是基础架构的责任。有些应用的服务发现需要调用API来实现，而有些应用则通过DNS或者网络代理透明地发现。具体的实现方式不重要，重要的是使用服务发现服务。云原生应用程序和基础架构协作以发现其相关依赖服务。例如Prometheus抓取监控信息的动作主要在配置文件中描述，但是如果Prometheus监控的目标是动态的，则需要部署人员每次去修改Prometheus配置文件，这是非常麻烦的，而且人工操作易出错。为此，Prometheus实现了一种服务发现方式，主动感知系统监控目标的变化，自动添加、删除和更新服务。以下是一个Kubernetes上的服务允许Prometheus自动发现的代码，其中的prometheus.io/scrape:"true"就是为了让Prometheus感知到该服务。该服务暴露了HTTP协议访问，端口为8080，端点为/metrics。