云原生思想

目录

云原生的起源

容器技术，即：操作系统虚拟化技术，最早出现于 1979 年，名为 Chroot Jail，沿用至今。

2004 年，谷歌开始使用容器技术，到 2006 年，谷歌发布了 Process Container（进程容器）技术。Process Container 的目的是希望能够像虚拟化技术一样，给进程提供操作系统级别的资源限制、优先级控制、资源审计能力和进程控制能力。

2007 年，Process Container 技术进入 Linux Kernel。因为在 Linux Kernel 中，Container（容器）这一名词具有许多不同的意义，所以为了避免混乱，Process Container 就更名为了 Control Groups，简称：Cgroups。

2008 Linux 发布 Linux Container，即 LXC，将 Cgroups 的资源管理能力和 Namespace 的视图隔离能力组合在一起，实现进程级别的隔离。

2013 年，dotCloud 公司基于 LXC（包括：cgroup、namespace、chroot）技术进行封装正式发布了 Docker Container。

2014 年，Kubernetes 容器编排平台也正式发布。Kubernetes 项目的初衷，就是为了提供一种方便、快速、优雅地 Containers 管理平台。

2015 年，由 Google、Redhat 以及 Microsoft 等大型云计算厂商牵头成立了 CNCF（Cloud Native Computing Foundation，云原生计算基金会），隶属于 Linux 基金会旗下，致力于培育和维护一个厂商中立的开源生态社区，并以此来推广云原生技术。而 Kubernetes 则是 CNCF 托管的第一个开源项目（注：实际上也是为了对抗当时大红大紫的 Docker 公司在容器圈一家独大的局面）。

CNCF 中托管的一系列项目，都致力于云原生应用整个生命周期的管理，从部署平台、日志收集、Service Mesh（服务网格）、服务发现、分布式追踪、监控以及安全等各个领域通过开源软件为我们提供一整套解决方案。

截止 2020 年 2 月，CNCF 已有 433 个会员，其中不乏国内各个行业的的龙头企业。

如何定义云原生

2013 年，Pivotal 公司（捷开发领域的领导者）的 Matt Stine 首次提出云原生（CloudNative）的概念。

2015 年，Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性。

2017 年，Matt Stine 将云原生架构归纳为：模块化、可观察、可部署、可测试、可替换、可处理 等 6 大特质。Matt Stine 认为云原生它是一个思想的集合，包括 DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等。

而 Pivotal 官方则对云原生概括为 4 个要点：

1. 容器
2. 微服务
3. 持续交付
4. DevOps

而 CNCF 则将云原生定义为：

• 云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

• 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

• 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

不同的公司、不同的人对云原生都有着不同的定义，同一家公司在不同的时间阶段定义也不一样。根据摩尔定律推断，未来对于云原生的定义还会不断变化。但可以肯定的是 —— Pivotal 是 Cloud Native 概念和方法论的先行者， CNCF 是 Cloud Native 的最佳实践者。

• Pivotal 定位于 PaaS 层端到端的解决方案及数字化转型，从文化、流程、方法论、蓝图规划、软件开发方式等，都有一套模式，主要用户是传统大中型企业 CIO，整体策略是自顶向下。

• CNCF 立足于整个云计算生态和技术创新、变革者，偏重于技术、工具链和底层基础设施，主要用户是开源社区的开发者、互联网及新兴企业，影响力可想而知，整体策略是自底向上。

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

笔者则认为，理解云原生（CloudNative）只需要拆开来看：

• Cloud：表示应用程序位于云中，而不是传统的数据中心；
• Native：表示应用程序原生为云而设计，充分利用和发挥云平台的弹性以及分布式优势。

云原生的代表技术

• Kubernetes 是云原生的基石，云原生的整个生态体系都是依靠 Kubernetes 建立起来的。
• 容器（Container）则是 Kubernetes 的底层引擎。
• 微服务是一种构建与云原生生态之上的软件架构模式。
• 服务网格是微服务的辅助，建立在 Kubernetes 上的针对请求的扩展功能。
• 不可变基础设施是现代运维的基石。
• 声明式 API 是 Kubernetes 的编码方式。

容器

容器提供进程级的隔离，可以将操作系统管理的资源划分到相互隔离的组中，在相互隔离的组之间解决资源使用存在冲突的问题。

容器为 IT 历史带来的显着影响莫过于：改变了代码交付的方式。它包含了一个应用运行所需的完整环境（整个操作系统的文件系统），具有一致性、轻量级、可移植、语言无关等特性，实现 “一次发布，随处运行”（开发、测试、生产），使应用的构建、分发和交付完全标准化。它也是 “不可变基础设施” 的核心基础。

Kubernetes

有了容器，就需要编排管理容器的生命周期，Kubernetes 则是这方面的事实标准。Kubernetes 这个单词来自于希腊语，含义是舵手或领航员。Kubernetes 并不是一件全新的发明，它是谷歌根据其内部使用的 Borg 改造成的一个通用容器编排调度器，于 2014 年 6 月开源。可以说，Kubernetes 是云计算和云原生时代的 Linux。

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

Kubernetes 作为云应用的部署标准，直接面向业务应用，大大提高了云应用的可移植性，解决云厂商锁定的问题，让云应用可以在跨云之间无缝迁移，甚至用来管理混合云，成为企业 IT 云平台的新标准。

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

微服务

微服务需要从两个方面去理解：“微” 和 “服务”。

对此，亚马逊 CEO Bezos 给出了一个很好的诠释：单个服务的实现，所有参与人从设计、开发、测试、运维所有人加起来只需要 2 个披萨就够了（2 pizza 定律）。

所谓服务，一定要区别于系统，服务是一个或一组相对较小且独立的功能单元，是用户可以感知最小功能集。传统的单体架构，以整个系统为单位进行部署。而微服务，则是以每一个独立组件为单位进行部署。

可以使用 Martin Fowler 的这张图来解释，图中左边是单体架构的集群，右边是微服务集群。

服务网格（Service Mesh）

对许多公司来说，Docker 和 Kubernetes 这样的工具已经解决了云原生应用部署的问题，但他们还没有解决微服务运行时的问题，这就是服务网格（Service Mesh）的由来。

Service Mesh 一般用于微服务应用的可配置基础架构层（Configurable infrastructure layer），以处理服务与服务之间通信。最早与 2016 年 9 月由 Buoyant 公司提出。而 Istio（由 Google、IBM、Lyft 支持）则是目前最广为人知的一款服务网格架构。Kubernetes 是目前 Istio 唯一支持的容器组织框架。

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

Service Mesh 的出现，弥补了 Kubernetes 在微服务的连接、管理和监控方面的短板，为 Kubernetes 提供更好的应用和服务管理。因此，Istio 一经推出，就被认为是可以和 Kubernetes 双剑合璧的微服务管理的利器，而受到了业界的推崇。

不可变基础设施

不可变基础设施，是相对于可变基础设施而言的。

• 可变基础设施：在传统的可变服务器基础架构中，物理服务器会不断更新和修改。使用此类基础架构的工程师和管理员需要通过 SSH 连接到他们的物理服务器，手动升级或降级软件包，逐个服务器地调整配置文件，以及将新代码直接部署到现有服务器上。所有说，这些服务器是可变的。它们可以在创建后进行更改。

• 不可变基础架构：是另一种基础架构范例，其中的物理服务器在部署后永远不会被修改。程序设计中不可变变量（ImmutableVariable）就是在完成赋值后就不能发生更改，只能创建新的来整体替换旧的。由于具有这样的特性这种变量可以在并发环境下安全的使用。对于基础设施的不可变性，最基本的就是指运行服务的物理服务器在完成部署后，就不在进行更改。

不可变基础架构的好处，包括：基础架构中更高的一致性和可靠性，以及更简单，更可预测的部署过程。它可以缓解或完全防止可变基础架构中常见的问题，例如：配置漂移和雪花服务器。但是，有效地使用它通常包括全面的部署自动化，云计算环境中的快速服务器配置，以及处理状态或短暂数据（如日志）的解决方案。

声明式 API

声明式（Declarative）的编程方式一直都会被工程师们拿来与命令式（Imperative）进行对比。

• 命令式编程：要求我们描述为了达到某一个效果或者目标所需要完成的指令，常见的编程语言：Go、Ruby、C++ 都是命令式的编程方法。

声明式 API 和命令式 API 是两种截然不同的编程方式：

• 命令式 API：我们可以直接发出服务器要执行的命令，例如：“运行容器”、“停止容器” 等。
• 声明式 API：我们声明系统要执行的操作，系统将不断向该状态驱动。

简而言之，命令式编程是第一人称，我要做什么，我要怎么做，是单纯的被动执行；而声明式编程则类似于 “第二人称”，也就是：你要做什么，是一种主动向目前前进的执行方式。

云原生与云计算

谈云原生就离不开云计算。

• 云计算传统的三层架构，即：基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS），它们重塑了 IT 基础设施的形态，节约 IT 成本、提升业务敏捷性。后来再扩展至 “无服务器计算架构”（Serverless，指用户无须购买或关注基础设施，即可运行应用程序，按需付费，弹性扩容，也是 PaaS 演进的一种 “极端” 形态）；

• 而基于云计算的云原生，则重塑了应用程序，摈弃传统的软件架构，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，即云原生应用。

简而言之，云计算是面向 IT 资产的，而云原生则是面向业务形态的。

云原生应用

云原生应用的特征

• 普遍可访问（Universal Availability）：服务可在任何地方从多前端访问。

• 高可用性（High Availability）：基本服务随时在线。升级扩容服务无中断。单点失败影响范围小。失败触发自动恢复。负载均衡，自动限流降级熔断，异常流量自动调度，故障隔离，宕机自动迁移等。

• 高扩展性（Scalability）：服务可以随业务需要随时迅捷线性伸缩。

• 自动弹性伸缩（Elasticity）：服务可以随业务需要按定义自动伸缩。根据业务负载自动伸缩，做到秒级扩缩容能力，灵活动态分配或释放资源，结合弹性计费策略，这是降低用户费用重要手段之一，对服务而言需要的关键技术点就是服务本身的 “轻量级容器化” 和以此为基础的 “不可变基础设施” 特征。

• 可观测性（Observability）：可以通过运维工具实时收集健康信息。丰富且细粒度的监控（实时指标、链路追踪、日志），秒级监控能力，做到自动化报警，可持久化的提供查询。

• 安全性（Security）：高度安全，可抵御常规威胁。

• 可迁移性（Deployable to Different Cloud Suppliers）：基础设施分离。易于迁移到不同的云计算供应商。

• 快速迭代（Fast Iteration）：服务更新快速频繁。创新速度提高。为应对频繁变更带来的稳定性风险，需建立无人值守的变更发布系统，具备自动化的灰度、蓝绿等发布策略，同时建立变更前中后的监控基线，具备异常变更的熔断和自动化回滚能力。

• 演进式设计（Evolutionary Design）：持续改进。

• 易于管理：需要从人工运维到自动运维的转变，具备自动化异常分析诊断能力，无需登录服务器。

• 弹性计费：支持按量（如流量，存储量，调用次数，时长等），按天（固定的如年/月/日），预留式，抢占式等多种定价策略，业务可根据实际情况灵活动态切换匹配出一个最优计量模式。

云原生应用的架构

• 云化微服务架构（Micro Service Architecture）：性能专注，系统组成部件高度解耦。独立开发,快速部署，仿真测试，实时运维，资源独立。系统组件化。组件独立化。

• 基于云基础设施和服务（Based on Cloud Infrastructure and Services）：通过按需自获取或释放的云基础设施（计算，网络，存储）和服务。

• 分布式云化部署（Distributed Deployment）：服务部署在分布式的云基础设施上。快捷全球上线。

• 无状态（Stateless）：请求可以由任何服务器处理。单点失败对服务功能无影响。

• 无本地依赖（Localless）：依赖其它云资源，比如云存储（CloudData Service），云计算资源，基于云的缓存，消息队列等等云服务。

• 可水平扩展（Horizontal Scalable）：应用性能可以随调整通用性服务器数量得到线性调整。

• 冗余性（Fault Tolerance）：利用多点部署，负载均衡（ELB）。单节点失败对服务无影响。

• 服务注册与发现（Service Registration and Discovery）

• 自动弹性伸缩（Auto Scaling）：服务可以随业务需要按定义自动伸缩。

• 去中心化（Decentralization）：开放分布式系统。独立数据存储。

如何构建云原生应用

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

从单个微服务应用的角度看，自身的复杂度降低了，在 “强大底层系统” 支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现 “强大底层系统” 付出的成本是非常昂贵（很强的架构和运维能力）的。

另外，企业为了实现这些功能所使用的技术栈及中间件体系是封闭的，私有化严重，很难满足所有的业务需求（包括阿里也存在这种情况）。“为了解决项目整体复杂度，选择上云托管”，将底层系统的复杂度交给云厂商，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 或 JSON 声明式代码，编排底层基础设施，中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的 “Cloud” 技术体系。

云原生的工具

• 持续集成（Continuous Integration）

• 依赖与版本管理（Dependency and Version Management）

• 持续交付流水线（CD Pipeline）

• 部署和回滚自动化（Automated Deployment and Rollback）

• 开发者工具网站（Simple developer web portal）

• 灰度发布（Gray Release）

• 端到端调试与分析（Full Stack Debugging and Profiling) –distributed tracing

• 设置管理（Configuration Management）

• 自助环境获取（Self Serviced Environment Acquisition）

• 统一标准的服务开发框架（Standardized Service Framework)

• 测试自动化（Continuous Automated Testing）

• A/B 测试（A/B Testing）

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

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

云原生的运维

DevOps 就是为了解决应用 “持续交付问题”。DevOps 平台包括：GitHub、Travis、Artifactory、Spinnaker、FIAAS、Kubernetes、Prometheus、Datadog、Sumologic 和 ELK 等组件。

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

云原生的运维具有以下特征：

• 服务状态的实时感知（Real time Service Status through Monitoring）
• 实时报警（Real time Alerting）
• 基于日志的运维数据采集与处理（Log Based Data Collection and Processing)
• 运维和业务相关指标的数据仪表盘（Visualized Dashboards of Operational and Business Relevant Metrics）
• 动态调度（Resource Dynamic Orchestration）
• 历史审计（Audit Trail Information）
• 可测量的服务SLA （Measurable Service Level Agreement）
• 快速问题定位（Issue Isolation）
• 从故障中自动恢复（Automated Recovery from Failure）
• 工单系统（Ticketing System）–跟踪处理在线系统故障。
• 生产线探针（Probe in Production）
• 资源记账（Resource Accounting）