云原生已来，只是分布不均

前言

Internet 改变了人们生活、工作、学习和娱乐的方式。技术发展日新月异，云计算市场风起“云”涌，从最初的物理机到虚拟机（裸金属），再到容器（Container），而互联网架构也从集中式架构到分布式架构，再到云原生架构。如今 “云原生” 被企业和开发者奉为一种标准，并被认为是云计算的未来，让我想到一句话：“未来已来，只是分布不均”。

伴随着 “云原生” 技术（架构）越来越火，火得一塌糊涂，每个人对它的理解都各不相同，网上和阿里内部关于 Cloud Native 的相关文章和讨论也非常多。不过，我发现大家对于云原生的定义、理解及实践还处于探索阶段，还没有一个非常明确或者顶层设计的标准化定义。

最近参与了一个上云项目，里面用到很多云原生的技术，借此机会结合大家的各种讨论，以及项目中的实践，聊一下个人对于云原生的一些粗浅思考。

追本溯源

在正式讨论之前，我们不妨先来看看几位网红主播是怎么定义云原生的。

Pivotal 的定义

Pivotal 公司是敏捷开发领域的领导者（曾经 Google 也是其客户），出生名门（EMC、VMware等投资），是标准的富二代。它推出了 Pivotal Cloud Foundry（2011 ~ 2013 PAAS 界网红）和 Spring 生态系列框架，也是云原生的先驱者和探路者（开山鼻祖）。云原生具体定义如下图：

Pivotal 公司的 Matt Stine 于 2013 年首次提出云原生（Cloud Native）的概念。2015 年，云原生推广时，Matt Stine 在《迁移到云原生架构》的小册子中定义了符合云原生架构的几个特征：12 因素应用、微服务架构、自敏捷架构、基于 API 协作、抗脆弱性。到了 2017 年，Matt Stine 改了口风，将云原生架构归纳为：模块化、可观测性、可部署性、可测试性、可处理性、可替换性等 6 大特征。而 Pivotal 最新官网对云原生概括为 4 个要点：DevOps、持续交付、微服务、容器。

CNCF 的定义

CNCF（Cloud Native Computing Foundation，云原生基金会）相信大家已经非常熟悉。它是由开源基础设施界的翘楚 Google、RedHat 等公司共同牵头发起的一个基金会组织，其目的非常明确，就是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面，具体情况（有很多故事）不在这边细说了。CNCF 通过 Kubernetes 项目在开源社区编排领域一骑绝尘，之后就扛起了云原生定义和推广的大旗，风光无限。云原生具体定义如下：

2015 年 CNCF 掺和进来，最初把云原生定义为：应用容器化、面向微服务、容器编排。到了 2018 年，CNCF 更新了云原生的定义，加入了声明式 API 和服务网格（2017 年社区新技术，和微服务并列，注意它不是微服务的升级版本），这些技术能够构建容错性好，易于管理和便于观察的松耦合系统。

小结

随着云原生生态和边界不断的扩大，云原生自身的定义一直在变。不同的公司（Pivotal & CNCF）不同的人对它有不同的定义，同一家公司在不同的时间阶段定义也不一样。根据摩尔定律推断，未来对于云原生的定义还会不断变化。

针对两家公司对云原生的定义不一样的情况，不妨跳出技术界面，我尝试用组织和立场的角度来分析下两位网红提出者：

Pivotal 定位于 PAAS 层端到端的解决方案及数字化转型，从文化、流程、方法论、蓝图规划、软件开发方式等，都有一套模式，主要用户是传统大中型企业 CIO，整体策略是自顶向下。
CNCF 立足于整个云计算生态和技术创新、变革者，偏重于技术、工具链和底层基础设施，主要用户是开源社区的开发者、互联网及新兴企业，影响力可想而知，整体策略是自底向上。

结论：Pivotal 是 Cloud Native 概念和方法论的先行者， CNCF 是 Cloud Native 的最佳实践者。

目前，针对定义唯一让我感到困惑的是 Pivotal 提 “概念” 把容器技术放进来，CNCF 提 “技术” 把微服务概念放进来，难道这两项是目前互联网圈最 “火” 的，为了吸引大众眼球？欢迎大家在下面留言讨论。

我眼中的哈姆莱特（云原生）

思维、概念

互联网从刚开始诞生发展，到现在的互联网思维、互联网+（即 Internet Native ），云计算从诞生到发展至今，需要云原生思维（即 Cloud Native），类比企业发展到一定阶段需要价值观思维（即 Values Native ）。它们是一种抽象的思维模式，所以任何技术的变革和推广，一定是思想先行，随后才有具体的产品帮助落地。

上面讲了思维方式，再具象点，结合 Pivotal 和 CNCF 对云原生定义及基于我自己的理解：

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

还是有点抽象，那要怎么理解这一段话，我简单列一下 4 个要点，即灵魂拷问：

充分利用 “云” 的能力，“云” 有什么能力？
云上应用打破传统构建方式，怎么构建？
应用具备云原生特征，有什么关键特征？
云原生技术体系，有什么关键技术？

“云”有什么能力

云计算出现与虚拟化技术的发展与成熟密不可分。它是一种新兴的 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 交付的一员，身上肩负着企业数字化转型的重任，怎么样能够帮助传统企业转型（通过互联网经验降维打击），更好的拥抱云原生，简单梳理了下云原生的落地路径，如下图：

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

第一步：上云是基石。
第二步：构建 PaaS 平台。ACK PaaS （阿里容器平台）为运维人员屏蔽底层资源和运维的复杂度，提供高性能可伸缩的容器应用管理能力，而为开发人员提供了构建应用程序的环境，旨在加快应用开发的速度，实现平台即服务，使业务敏捷且具有弹性、容错性、可观测性。
第三步：基于 PaaS 实现 DevOps。PaaS 平台是通过提高基础设施的敏捷而加快业务的敏捷，而 DevOps 则是在流程交付上加快业务的敏捷。通过 DevOps（云效）可以实现应用的持续集成、持续交付，加速价值流交付，实现业务的快速迭代。
第四步：实现微服务治理。通过对业务进行微服务化改造，将复杂业务分解为小的独立单元，不同单元之间松耦合、支持独立部署更新，真正从业务层面提升敏捷性。在微服务的实现上，客户可以选择采用阿里 EDAS（支持 SpringCloud、 Dubbo 等），但随着技术的发展，微服务最好治理的治理方向应该是服务网格ServiceMesh（ASM 兼容 Istio）。
第五步：实现微服务高级管理。在微服务之上实现 API 管理、微服务的分布式集成以及微服务的流程自动化。通过 API 管理帮助企业打造多渠道（自营、微信、天猫等）生态，最终实现 API 经济。通过微服务的分布式集成和流程自动化，企业可实现统一的业务中台。

图中横坐标是业务健壮性，通常建设步骤为：

第一步：建设单数据中心。大多数企业级客户，如金融、电信和能源客户的业务系统运行在企业数据中心内部的私有云。在数据中心建设初期，通常是单数据中心。
第二步：建设多数据中心。随着业务规模的扩张和重要性的提升，企业通常会建设灾备或者双活数据中心，这样可以保证当一个数据中心出现整体故障时，业务不会受到影响。
第三步：构建混合云。随着公有云的普及，很多企业级客户，开始将一些前端业务系统向公有云迁移，或者使用多家云厂商，这样客户的 IT 基础架构最终成为混合云、多云的模式。

“云原生” 看起来极其美好，可一旦深入进去到落地环节发现实际非常复杂，这个复杂体现在概念新、涉及技术面比较广，也体现在客户的期望价值差异很大，更体现在客户对未来的判断有很多不确定性。在未来的一段时间，我会不断整理自己的所闻所见、所思所想和实践中的思考，拿出来和大家分享，和大家探讨，这是开头的第一篇，希望能不断写下去，为企业数字化转型出一份自己的绵薄之力。