云原生基础架构的最佳状态，就是没有架构？

云栖号资讯：【点击查看更多行业资讯】
在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！

云原生基础架构是通向云原生时代的基石，对于很多架构师来说，上云之后，架构为什么成为了云原生架构而不是传统的架构，两者有何区别？云原生基础架构是如何演进的？本文进行了全面梳理。

什么不是云原生基础架构？

云原生被谈的很多了，导致概念很乱。有人把云原生基础架构和公有云、容器、容器编排系统等划等号，之所以出现这种情况，原因是云原生架构并没有一个统一的概念。

为了更好的理解云原生系统，这里先做一些排除。

首先，云原生并不等于公有云。云原生基础架构不仅仅是在公有云上运行基础架构，这是因为仅仅从云服务商那里租用服务器时长，并不会使你的基础架构云原生化，管理IaaS和运行物理数据中心本质上没区别。

其次，云原生基础架构不等于在容器中运行应用程序。当Netflix率先推出云原生基础架构时，几乎所有的应用程序都是用虚拟机镜像部署，而不是容器。打包应用程序的方式并不意味着将拥有自治系统的可扩展性和优势。即使应用程序是通过持续集成和持续交付流水线自动构建和部署的，也并不意味着可以从补充API驱动部署的基础架构中受益。

第三，云原生基础架构不意味着只运行一个容器编排器就是云原生。容器编排器提供了云原生基础架构所需的许多平台功能，但并未按预期方式使用这些功能，这意味着应用程序将被动态调度为在一组服务器上运行。这是非常好的起步，但并不是终点，还有很多工作要做。

第四，云原生不是关于微服务或基础架构即代码。微服务可以在较小的不同功能上实现更快的开发周期，但是单块应用程序可以具有相同的特性，使它们能够通过软件有效管理，并且还可以从云原生基础架构中获益。

这是当前的主要几个认知误区。当然，如果用排除法，不可能将当前的认知一一列举。从热门的词汇看，容器、容器编排器、微服务……如果回到《理解了云原生，才能正确迎接云时代的到来》一文中，会发现当时讲过它们都是云原生的元素，但都不能和云原生基础架构划等号。

什么是云原生基础架构？

要回答这个问题，得先从基础架构说起。最早谈的基础架构，是服务器，后来有了虚拟化，再到IaaS、PaaS，基础架构的演变可以说伴随着时代的变迁。这其中基础架构的演进路线是越来越灵活、低成本、维护简便、易获取。应该说，云原生基础架构还是在按这条路线继续演进。

那究竟什么是云原生基础架构？

核心定义

其实，底层资源如计算、存储、网络没有太大的改变，核心在于资源的调用、使用方式。如果给云原生基础架构关联几个关键词，有三个：由API控制，由软件管理，目标是运行程序。这其中透露的最核心的信息，为了业务，不用过多人为干预的基础架构。

之所以强调业务本身，是因为基础架构的不同是由上层应用决定的。而运行云原生应用程序和传统应用程序所需的基础架构最大的不同在于，原本许多本属于基础架构的职责已经转移到了应用程序。

过去及现在的基础架构负责的是整体资源管理、动态协调、服务发现等，与业务之间的关联并不紧密。换句话说，基础架构管理与应用管理是脱节的，未来二者的管理将是一体的，应用程序自己会完成原本需要大量人工干预的环节。当前所说的“解耦”，可以适用于此。不仅仅指资源和应用程序之间的解耦，也指资源之间的解耦、API和应用之间的解耦。每一个组件（模块、资源）都是单独成为服务可被发现可被调用的，唯一的就是要看这些组件的定义和颗粒度的问题。

要弥合应用与基础架构之间的鸿沟，需要一个中间平台层，它能够通过API调用，能够自治。

这里强调一下自治，它和自动化不能划等号。自动化是人类输入的一个完整的业务流程，一个流程只能做一件事。而自治不需要人类做出决定，它仍然使用自动化，但只有当系统不能自动确定正确要做的事情时才应该通知人。自治比自动化多了智能化。

总的来看，云原生基础架构一个较为通俗的描述，应用可以通过平台层自动完成资源调用、协调，无需人工干预，所有的资源都是可以随时拉起，随时释放，同时以API的方式提供弹性、按需的计算、存储能力。

如果这种解释令人费解，那么，我们可以这么比喻，只要符合“杯子”的概念都是“杯子”，但是制作流程和工艺、材质有本质的不同。而大体上，市面上有默认的几种模式，这也就形成了通用的标准。

所以，云原生基础架构也没有业内“放之四海而皆准”的标准，它本身也在随着技术的演变而在演变中，只要符合“灵活、低成本、易维护”等特点，就是云原生。我们不必拘泥于概念，而是要不断往前看，为什么要采用“云原生”，为用户带来的好处是什么？

这才是核心。

能带来什么好处？

云原生基础架构带来最大的变革在于API机制。API机制允许用户从标准化基础架构即代码中获益，并增加了随着时间的推移版本化和更改表述的能力。

具体而言，实现了云原生基础架构后，技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的，并且是自动化的，不需要通过手工安装或克隆的方式来管理服务器资源，运维人员和开发人员一起以资源配置的应用代码为中心，不再是一台台机器。

值得一提的是，基础设施的包含范围也会很广泛，不仅包括机器，还包括不同的机柜或交换机、同城多机房、异地多机房等。

换句话说，只需要调整相应的API就能实现资源使用方式的调整，整个过程无需关心底层基础架构的变化。云原生基础架构的理想状态是，它非常容易被忽略，它简单、自动化、可自服务，也就是没有基础架构。

因此好处显而易见，对运维人员是一种解放，对企业而言，能将更多精力投入业务开发、运营中，公司整体运营效率将大幅提升。当前，这种模式已经被证明了可以扩展到巨大数据的基础架构和应用程序的。

云原生基础架构实现

弄清楚了云原生基础架构的本质，这部分简单介绍下云原生基础架构的实现，主要分三部分：设计、开发和测试。

至于具体的方法实践倒是其次，这部分最重要的是转变观念。原本传统的基础架构运维人员要成为基础架构软件工程师，只有适应了身份的转变，才能更好地到达云原生基础架构的彼岸。

作为一名基础架构工程师，不仅要掌握设计、管理和运维基础架构的基本原则，还要把专业知识应用在构建强健的应用程序中，这些应用程序代表了将要管理和改变的基础架构。

回归技术关键，最重要的一个环节就是API，设计、开发，乃至最后的应用，API关乎成败。因为基础架构将需要随着时间的推移而变化或者变异，这是云原生环境的本质。当运维承担改变基础架构的任务时，API的真实价值就体现出来了。

有关API的设计，及更多技术细节这里不做太多讨论，有兴趣的朋友可以找相关书籍查阅，每本书的思想、方法都可能不一致，要学会兼容并蓄，取长补短。

总结全文，云原生基础架构是基础架构的自然而可能预期的演变。实现云原生基础架构是比较难的，如果你认为云原生基础架构是你可以购买的产品，或者可以运行服务的供应商，显然要失望了，就目前阶段而言，只有极少数产品实现了云原生，比如今年，各大云服务商都在推的云原生数据库算是其中的典型代表。实现云原生这条路还很长，要慢慢学，慢慢深入。