『阿里云云栖社区TB』就是没有架构?,云原生基础架构的最佳状态


『阿里云云栖社区TB』就是没有架构?,云原生基础架构的最佳状态
文章图片
云原生基础架构是通向云原生时代的基石 , 对于很多架构师来说 , 上云之后 , 架构为什么成为了云原生架构而不是传统的架构 , 两者有何区别?云原生基础架构是如何演进的?本文进行了全面梳理 。
什么不是云原生基础架构?
云原生被谈的很多了 , 导致概念很乱 。 有人把云原生基础架构和公有云、容器、容器编排系统等划等号 , 之所以出现这种情况 , 原因是云原生架构并没有一个统一的概念 。
为了更好的理解云原生系统 , 这里先做一些排除 。
首先 , 云原生并不等于公有云 。 云原生基础架构不仅仅是在公有云上运行基础架构 , 这是因为仅仅从云服务商那里租用服务器时长 , 并不会使你的基础架构云原生化 , 管理IaaS和运行物理数据中心本质上没区别 。
其次 , 云原生基础架构不等于在容器中运行应用程序 。 当Netflix率先推出云原生基础架构时 , 几乎所有的应用程序都是用虚拟机镜像部署 , 而不是容器 。 打包应用程序的方式并不意味着将拥有自治系统的可扩展性和优势 。 即使应用程序是通过持续集成和持续交付流水线自动构建和部署的 , 也并不意味着可以从补充API驱动部署的基础架构中受益 。
第三 , 云原生基础架构不意味着只运行一个容器编排器就是云原生 。 容器编排器提供了云原生基础架构所需的许多平台功能 , 但并未按预期方式使用这些功能 , 这意味着应用程序将被动态调度为在一组服务器上运行 。 这是非常好的起步 , 但并不是终点 , 还有很多工作要做 。
第四 , 云原生不是关于微服务或基础架构即代码 。 微服务可以在较小的不同功能上实现更快的开发周期 , 但是单块应用程序可以具有相同的特性 , 使它们能够通过软件有效管理 , 并且还可以从云原生基础架构中获益 。
这是当前的主要几个认知误区 。 当然 , 如果用排除法 , 不可能将当前的认知一一列举 。 从热门的词汇看 , 容器、容器编排器、微服务……如果回到《理解了云原生 , 才能正确迎接云时代的到来》一文中 , 会发现当时讲过它们都是云原生的元素 , 但都不能和云原生基础架构划等号 。
什么是云原生基础架构?
要回答这个问题 , 得先从基础架构说起 。 最早谈的基础架构 , 是服务器 , 后来有了虚拟化 , 再到IaaS、PaaS , 基础架构的演变可以说伴随着时代的变迁 。 这其中基础架构的演进路线是越来越灵活、低成本、维护简便、易获取 。 应该说 , 云原生基础架构还是在按这条路线继续演进 。
那究竟什么是云原生基础架构?
核心定义
其实 , 底层资源如计算、存储、网络没有太大的改变 , 核心在于资源的调用、使用方式 。 如果给云原生基础架构关联几个关键词 , 有三个:由API控制 , 由软件管理 , 目标是运行程序 。 这其中透露的最核心的信息 , 为了业务 , 不用过多人为干预的基础架构 。
之所以强调业务本身 , 是因为基础架构的不同是由上层应用决定的 。 而运行云原生应用程序和传统应用程序所需的基础架构最大的不同在于 , 原本许多本属于基础架构的职责已经转移到了应用程序 。
过去及现在的基础架构负责的是整体资源管理、动态协调、服务发现等 , 与业务之间的关联并不紧密 。 换句话说 , 基础架构管理与应用管理是脱节的 , 未来二者的管理将是一体的 , 应用程序自己会完成原本需要大量人工干预的环节 。 当前所说的“解耦” , 可以适用于此 。 不仅仅指资源和应用程序之间的解耦 , 也指资源之间的解耦、API和应用之间的解耦 。 每一个组件(模块、资源)都是单独成为服务可被发现可被调用的 , 唯一的就是要看这些组件的定义和颗粒度的问题 。
要弥合应用与基础架构之间的鸿沟 , 需要一个中间平台层 , 它能够通过API调用 , 能够自治 。