云原生下一步的发展路径分析.docx

云原生下一步的发展路径分析

【摘要】云下一步发展的目标就是让上层应用和业务意识不到云的存在。云原生的下一步发展就是朝这个方向发展。

援引某厂商的说法，云原生已经进入2.0时代，上云也从资源上云进一步向应用上云和业务上云升级，推动企业数字化转型和智能升级。还有一个形象的说法可以概括上述观点，云原生让企业云化从“ON Cloud”走向“IN Cloud”。

一、缘起应用架构演进
我们都知道，商业模式决定了产品形态，产品决定了研发模式，研发模式又决定了需要采用什么样的技术。纵观这些年企业应用架构的发展，我们经历了传统应用时代、互联网应用时代和数字化转型应用时代，所处的时代不同引发的需求也不同，由此带来对技术的要求自然也不同。
传统的应用需求是相对固定的，通常以项目化运作，用户的访问量可以预测，容量是有限的，对停开机的要求也没有那么严格。所对应的应用架构一般是单体应用和垂直架构，集成方式也多是直连模式或者网状集成。
互联网应用的特征是需求持续发展，产品化而非项目制，用户量并非线性，往往会有陡增陡降。应用架构多是SOA架构，集成方式一般通过ESB等应用集成平台。
处在这样一个数字化转型的时代，我们的业务边界和业务活动是完全不可预知的，即便是对于互联公司都是巨大的挑战，要求快速地尝试、快速探测、快速的感知，应用是服务化的方式提供，业务敏捷性前提之下，对技术体系的持续发布、分布式海量并发、灰度发布和线上测试都是基本诉求。业务的敏捷性持续发布，应用平台的弹性诉求，商业环境的变化，这是整个云原生产生的时代背景。

二、微服务是一个躲不开的话题
首先，我们需要再次明确一个概念。微服务，不是一种技术而是一种软件架构模式和方法，是一种基于将应用程序构建为小型服务集合的软件开发体系结构方法。从某种程度上说，微服务是单体应用的对立面。从本质上来讲，微服务就是把单体应用从一个巨型的应用拆分成数个更微小的服务，协作完成原来单体应用所提供的等效业务服务。单体应用跟资源之间是一对一的紧耦合关系，单体应用的协同也都是一些内部协同，不存在外部的动态依赖。而当我们转换到微服务之后，服务与服务之间会有依赖关系，依赖关系会变成网状，变得复杂起来。
容器化的出现，一定程度上带动了微服务架构。架构演化从单体式应用到分布式，再从分布式架构到云原生架构，微服务在其中有着不可或缺的角色。
微服务体系和云原生架构的组成部分有各自的部分，也有重叠的部分。
首先，微服务体系会涉及业务体系部分，从业务需求出发，采用DDD等理念搭建微服务的业务模型，这部分其实并不在云原生架构体系里面。
同样，云原生是构建在新型基础设施上面的，所谓新型基础设施是结合了分布式云和不可变原则的，微服务更强调外部依赖，并不涉及基础设施部分。
微服务跟云原生共同关注的内容其实是技术体系和管理体系两部分，其中技术体系主要是涉及微服务技术架构、集成工具，，面向云原生更多强调云平台和和容器化能力。管理体系更关注从业务角度如何支撑和获取管理支持，比如研发过程中的敏捷、研发规范和度量，运维过程的CI\CD等。
从微服务架构的思想出发，微服务架构、DevOps 和容器技术天然地走到了一块儿，构成了云原生应用架构的雏形。

三、云原生的基本理解
1、基本概念
云原生从字面意思上来看可以分成云和原生两个部分。云原生的定义，CNCF是这样说的，“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”
2、基本特征
CNCF给出了云原生应用的三大特征：
容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。
动态管理：通过集中式的编排调度系统来动态的管理和调度。
面向微服务：明确服务间的依赖，互相解耦。
云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。
我们可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化。
3、演进发展
云原生自诞生依赖，已经度过了概念炒作的阶段，进入架构落地阶段，出现了云原生2.0的概念。云原生1.0与2.0最大的区别在于， 1.0的云原生是ON Cloud，即把容器、微服务、DevOps等云原生的特征堆砌到云上。这样的做法虽然实现了弹性、敏捷等，但还仅仅是解决了基础设施架构层的问题，是以资源为核心，并未实现资源效率的最大化、最优解。
而云原生2.0则是IN Cloud，是以应用为中心。除了具备云原生1.0的容器、微服务、DevOps等特征外，更强调对资源的配备。
从现在基础设施的发展情况来看，我们正在从以资源为中心的资源上云阶段向以应用为核心的应用上云阶段演进，关注点从资源云化向应用云化渗透。第一阶段，我们关注的是以资源自动化为目标的资源融合管理。第二阶段，我们关注的是以应用自动化为目标的应用敏捷管理。
相对概念阶段的云原生以及资源上云来说，云原生2.0的关注点有了以下变化：
高效的资源管理与调度：基于软硬件协同构建多元算力，为应用提供极致的覆盖逻辑、虚拟机、容器、函数等在内的多元算力；基于边云协同和分布式云架构，实现多云算力的纵向融合和横向联动，形成分布式泛在算力平台；以应用为中心，实现资源的高效管理、调度和编排，实现一键部署、一建管理和智能感知。
敏捷的应用交付与管理：通过创新应用开发模式，进一步实现应用的敏捷交付和应用的全生命周期管理，通过侵入式和非侵入式两种模式助力企业应用架构升级。
智能的业务支撑与开放：主要是如何做好数据汇聚融合和数据运营，推动数据资产化、数据业务化和业务数据化，借助AI等新技术，实现数据对业务的二次赋能，实现业务的智能升级。
完善的安全可信与合规：借助云原生对基础资源的融合纳管，在基础资源和基础设施安全的基础上，进一步打造应用、数据和业务安全。

四、可以预见的云原生发展趋势
之前我曾经说过一个观点，云下一步发展的目标就是让上层应用和业务意识不到云的存在。云原生的下一步发展就是朝这个方向发展。云原生将与分布式云深度融合，在充分考虑成本优化和组织优化的基础上，推动全栈云延伸到业务的每个角落。
现有云原生的基础设施，基本处在简单堆砌和简单叠加的状态，基于应用状态的资源动态感知和自动供给尚处于比较困难的阶段，不是普通用户能够企及的。云原生的下一步发展目标就是提升软硬件协同的效率和资源利用率，实现普通客户触手可达的资源与应用状态的相互感知，以及基于复杂的资源调度和编排。
异构的技术栈，在相当长一段时间将持续存在，微服务治理将会是企业应用架构治理的重要工作。Serverless也将持续释放其价值和活力，在头部企业逐步扩大示范效应。
虽然以应用为核心的云原生架构发展会越来越迅猛，但是我们依然要保持清醒的头脑，无论何种架构何种技术，最终目的都是以实现业务高效支撑为目的。所以我们依然认为，持续打造以战略为指引，以需求为核心的企业架构，是一项长期的根本任务。
-全文完-