云原生的解释可以说五花八门，本文从深入探讨云原生的内涵以及其使用的关键技术。

云原生是什么？

云原生是有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生根据一套方法论（Pivotal）和技术体系（CNCF），在云上构建一套可运行的应用系统。该应用系统会打破传统的构建方式，充分利用“云”的原生能力，发挥出 “云” 的最大价值，使其具备原生特征，快速为业务赋能。

简单来说，云原生就是某种云服务系统随应用而变化，随应用而生长的技术体系。

如果还不太清楚，我们可以从下面几个方面来理解云原生：

能力

云计算出现与虚拟化技术的发展与成熟密不可分。它是一种新兴的 IT 基础设施交付方式，通过虚拟化技术，对 IT 硬件资源与软件组件进行了标准化、抽象化和规模化，变成 “产品服务” 和 “账单”（pay as you go），某种意义上颠覆和重构了 IT 业界的供应链。具体提供的服务有 IaaS/PaaS/FaaS/DaaS 几种形态：

IaaS（Infrastructure as a Service）

即 “基础设施即服务”，一般指云计算所提供的计算、存储、网络、安全等基本最底层能力。

PaaS（Platform as a Service）

即 “平台即服务”，通常指基于云底层能力而构建的面向领域或场景的高层服务，如云数据库、云对象存储、中间件（缓存、消息队列、负载均衡、服务网格、容器平台等）、应用服务等。

Serverless

即 “无服务器计算架构”，指用户无须购买或关注基础设施，即可运行应用程序，按需付费，弹性扩容，也是 PaaS 演进的一种 “极端” 形态。目前包含 3 种方式：

• 面向函数：开发者只需提供函，通过事件或 HTTP 请求触发实现相应的功能，代表有阿里云（函数计算），AWS（Lambda）。
• 面向应用：开发者只需提供业务应用，无须购买服务器资源，代表有Google（cloud run），阿里云（EDAS Serverless）。
• 面向容器：应用的升级版，载体是容器镜像，屏蔽环境差异，灵活性好，代表有阿里云（Serverless kubernetes），AWS （Fargate）。

DaaS（Data as a Service）

“即数据即服务”，拓展到上层应用，AI 与云服务的结合，产生了很多高价值的服务。比如大数据决策系统、语音面部识别、深度学习、基于场景的语义理解。这也是未来 “云” 的核心竞争力。

随着开源和技术的不断发展，我们可以看到，云厂商提供的产品和能力越来越多，从物理机、虚拟机、容器，到中间件，再到 IT Serverless 架构，每一层都在逐步的被标准化，而且标准化层面越来越高（即附加值也越高），跟业务没有直接关系且相对通用的技术（比如服务网格）也被标准化并且下沉到基础设施。技术每被标准化一层，原本低效繁琐的工作就少一些。另外，应用层面提供 “人工智能” 等新兴技术，帮助企业降低探索成本，加快了新技术的验证和交付，真正赋能业务。

对应用户则可以像宜家一样通过搭积木的方式，选择自己合适的云产品，站在巨人的肩膀上，避免重复造轮，极大提高了软件与服务构建各环节的效率，加速了各类应用和架构的落地，而 “云” 端可以按需启用和随意扩展的弹性资源，能够为企业节省巨大成本。

构建

上面提到了 “云” 有很强大的能力，云上应用该如何适应，那么相比传统应用，新应用从软件架构的设计，开发，构建，部署，交付，监控及运维等整个应用生命周期各环节都需要被重塑，我从 “问题” 的角度切入讲一下：

架构怎么设计

好的架构是演进而来的，不是设计出来的，空谈架构 “如何设计” 是没有意义的，架构演进的目的一定是解决某一类问题。我们不妨从 “问题” 的角度出发，来聊一下云原生架构如何设计，如下图：

• 为了解决单体架构 “复杂度问题”，使用微服务架构。
• 为了解决微服务间 “通讯异常问题”，使用治理框架 + 监控 。
• 为了解决微服务架构下大量应用 “部署问题”，使用容器。
• 为了解决容器的 “编排和调度问题”，使用 Kubernetes。
• 为了解决微服务框架的 “侵入性问题”，使用 Service Mesh。
• 为了让 Service Mesh 有 “更好的底层支撑”，将 Service Mesh 运行在 k8s 上。

从单个微服务应用的角度看，自身的复杂度降低了，在 “强大底层系统” 支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现 “强大底层系统” 付出的成本是非常昂贵（很强的架构和运维能力）的。另外，企业为了实现这些功能所使用的技术栈及中间件体系是封闭的，私有化严重，很难满足所有的业务需求（包括阿里也存在这种情况）。“为了解决项目整体复杂度，选择上云托管”，将底层系统的复杂度交给云厂商，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 或 JSON 声明式代码，编排底层基础设施，中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的 “Cloud” 技术体系。

应用怎么交付

为了解决应用 “持续交付问题”，我们引入了 Devops。

Devops 理念大家应该比较熟悉了，我理解它是一系列价值观，原则，方法，实践及工具的集合，目的是实现快速交付价值且具有持续改进能力，其核心是用于打破研发和运维之间的隔阂、加快软件交付流程、提高软件质量。下面贴一张流水线工具平台，如下图：

平台包括：GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 等组件。

那怎么样才能算真正落地和践行 DevOps ，满足灵魂拷问的几个问题：

• 方式：开发每次写完代码是否可以部署到测试、生产环境，不需要运维帮助？
• 工具：是否有成熟运维工具平台和监控体系供开发使用，轻松处理线上各种问题、故障和回滚？
• 文化：开发直接为线上⽤户的体验负责，不管是代码缺陷还是运维故障，自己变更自己背锅，是否有 owner 精神？
• 交付度量：在部署频率、变更前置时间、服务恢复时间、变更失败率等对应指标上能否满足业界要求？

DevOps 本质上是为运维服务的，运维通过使用新技术和开发一系列自动化工具，让开发更接近生产环境，负责开发和运维全部过程，保证了自由度和创新性。在监控、故障防控工具，功能开关的配合下，可以在保障用户体验和快速交付价值之间找到平衡点。

猜想：对于技术人来说，或许未来真的只会有业务解决方案和业务代码，更多更迫切的能力需求将会是如何利用好业界已有的丰富的技术产品和云厂商平台，在面对更加丰富多样且复杂的业务领域需求时，能够更加专注于寻求业界解决方案，以更好地将业务和技术连接起来。对于运维来说，云屏蔽了基础设施的复杂度，从而转向工具链开发的运维中台和规模化运维，重点关注成本、效率、稳定性，并为应用保驾护航向上发展。

特征

• 弹性伸缩性：根据业务负载自动伸缩，做到秒级扩缩容能力，灵活动态分配或释放资源，结合弹性计费策略，这是降低用户费用重要手段之一，对服务而言需要的关键技术点就是服务本身的 “轻量级容器化” 和以此为基础的 “不可变基础设施” 特征。
• 容错性：负载均衡，自动限流降级熔断，异常流量自动调度，故障隔离，宕机自动迁移等。
• 可观测性：丰富且细粒度的监控（实时指标、链路追踪、日志），秒级监控能力，做到自动化报警，可持久化的提供查询。
• 发布稳定性：为应对频繁变更带来的稳定性风险，需建立无人值守的变更发布系统，具备自动化的灰度、蓝绿等发布策略，同时建立变更前中后的监控基线，具备异常变更的熔断和自动化回滚能力。
• 易于管理：需要从人工运维到自动运维的转变，具备自动化异常分析诊断能力，无需登录服务器。
• 极致体验：包括应用分配/创建/资源申请/环境配置/开发测试/发布/监控报警/排障定位等需要做到通畅与简单，一站式体验，避免繁杂的搭积木式操作。
• 弹性计费：支持按量（如流量，存储量，调用次数，时长等），按天（固定的如年/月/日），预留式，抢占式等多种定价策略，业务可根据实际情况灵活动态切换匹配出一个最优计量模式。

技术

容器

容器雏形最早出现在 1979 年叫 Chroot Jail ，定义于 2008 年 即 LXC（Linux Container），将 Cgroups 的资源管理能力和 Namespace 的视图隔离能力组合在一起，实现进程级别的隔离。然而容器最大的创新在于容器镜像（即集装箱，Docker “现象级” 开创），它包含了一个应用运行所需的完整环境（整个操作系统的文件系统），具有一致性、轻量级、可移植、语言无关等特性，实现 “一次发布，随处运行”（开发、测试、生产），使应用的构建、分发和交付完全标准化。它也是 “不可变基础设施” 的核心基础。

Kubernetes

Kubernetes 是云计算和云原生时代的 Linux。

Kubernetes 是 Google 基于 Borg 开源的容器编排调度系统，让容器应用进入大规模工业生产。

声明式的 API 与可扩展（CRD + Controller）的编程接口，先进的设计思想使其在容器编排大战中（Kubernetes、Swarm、Mesos）处于王者地位，成为容器编排系统的事实标准。

通过采用 Kubernetes 平台，用户不必操心资源管理问题，使基础设施更加标准化，复杂度降低，资源使用率提升。同时 Kubernetes 也简化了混合云，多云，边缘云等跨数据中心的部署成本。

ServiceMesh

ServiceMesh 核心是业务逻辑与非业务逻辑解耦，实现开发只需关注业务逻辑的伟大目标。将一大堆和业务逻辑无关的客户端 SDK（如服务发现，路由，负载均衡，限流降级等）从业务应用中剥离出来，放到单独的 Proxy（Sidecar） 进程中，之后下沉到基础设施中间件 Mesh（类似 TDDL 到 DRDS 的模式）。针对应用减少了系统框架变更带来的风险、瘦身后变的干净和轻量化，加快了应用的启动速度，使得应用往 Serverless 架构迁移变得轻松。针对 Mesh 可以根据自身需求自行迭代和升级功能，更加利于全局服务治理、灰度发布、监控等。同时，Mesh 边界可以扩展到 DB Mesh，Cache Mesh、Msg Mesh等，真正做到服务通信的标准化即服务之间通信的 TCP/IP。

基础设施即代码（IaC）

将基础设施及其完整的生命周期（创建、销毁、扩容、替换）以代码的方式进行描述、通过相应的工具（terraform、ROS、CloudFormation等）编排执行和管理。比如应用用到的所有基础资源（如：ECS、VPC、RDS、SLB、Redis 等），无需在控制台不停的切换页面申请购买，只需定义相应代码，一键创建。这样做的受益是基础设施代码版本化，可 Review，可测试，可追溯，可回滚，一致性、防止配置漂移，方便共享、模板化和规模化，提升了运维整体效率和质量，通过代码也可以轻松了解基础设施的全貌。

Cloud IDE

云端 IDE 深入研发的整个生命周期，提供了完整的开发、调试、预发、生产环境及CI/CD 发布一体化体验。云端可提供丰富的代码库模板，通过分布式运算提升编译速度，以 “智能” 方式实现代码推荐、代码优化、自动扫描发现 BUG、识别逻辑和系统性风险。可以想像云时代开发模式与本地开发完全不同，拥有更高的研发效率，更快的迭代速度，更完善的质量控制。

云原生落地思考

作为 GTS 交付的一员，身上肩负着企业数字化转型的重任，怎么样能够帮助传统企业转型（通过互联网经验降维打击），更好的拥抱云原生，简单梳理了下云原生的落地路径，如下图：

图中纵坐标为业务敏捷性，云原生业务敏捷性方面的转型大致包含以下几步：