这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

云原生介绍

云原生介绍

1 - 云原生概述

云原生概述

2 - 云计算的历史

云计算的演进历史

在介绍云原生之前，先看看过去几十年间，云计算领域的发展演进历程。

云计算的远古时代

云计算的历史事实上需要追溯到60多年前的计算机远古历史：

  • 1955年，John McCarthy（备注：John McCarthy是Artificial Intelligence/人工智能一词的提出者）创造了一种在用户群中共享计算时间的理论。

  • 1959年6月，在国际信息处理大会上克里斯托弗Christopher Strachey发表了《Time Sharing in Large Fast Computer》论文，提出了虚拟化概念。该文被公认为虚拟化技术的最早论述。

  • 1965年8月，IBM推出System/360 Model 67 和 TSS 分时共享系统（Time Sharing System），通过虚拟机监视器（Virtual Machine Monitor）虚拟所有的硬件接口，允许多个用户共享同一高性能计算设备的使用时间，也就是最原始的虚拟机技术。

  • 在20世纪60年代中期，美国计算机科学家 JCR Licklider 提出计算机互联系统(an interconnected system of computers)的想法。

  • 1969年，在 JCR Licklider 的革命性创意的帮助下，Bob Taylor 和 Larry Roberts 开发了互联网的前身 ARPANET（Advanced Research Projects Agency Network），允许不同物理位置的计算机进行网络连接和资源共享。

  • 1972年，IBM发布了名为VM（Virtual Machine）的操作系统。在90年代，虚拟机的使用开始流行

  • 1974年，Popek和Goldberg发表了《Formal Requirements for Virtualizable Third Generation Architectures》提出了虚拟化准备的充分条件，指出满足条件的控制程序可以被称为虚拟机监视器Virtual Machine Monitor （VMM）：（1）一致性：一个运行于虚拟机上的程序，其行为应当与直接运行于物理机上的行为基本一致，只允许有细微的差异如系统时间方面；（2）可控性：VMM对系统资源有完全的控制能力和管理权限；（3）高效性：绝大部分的虚拟机指令应当由硬件直接执行而无需VMM的参与。

  • 1978年，IBM获得了独立磁盘冗余阵列（Redundant Arrays of Independent Disks，RAID）概念的专利。该专利将物理设备组合为池，然后从池中切出一组逻辑单元号（Logical Unit Number，LUN）并将其提供给主机使用。虽然该技术直到1988年IBM才与加利福尼亚州立大学伯克利分校联合开发了第一个实用版本，但该专利第1次将虚拟化技术引入存储之中。

“Time-Sharing”的背景：自20世纪50年代，人类使用大型计算机系统来处理数据。而在早期，大型计算机体积庞大而且价格高昂。为了提高投资回报率，购买大型机的组织开始实施“分时调度（time-sharing）”，然后从没有处理能力的终端访问大型计算机。“分时”理论可以充分利用可用的计算时间，可以用于为无力购买自己的大型机的小公司提供计算时间。

这里便陆续出现了云计算的基本前提：共享计算能力和共享网络，并出现了虚拟机，虚拟网络和早期基础设施。

但是在2000年前后虚拟化技术成熟之前，市场处于物理机时代。当时如果要启用一个新的应用，需要购买一台或者一个机架的新服务器。

虚拟化技术成熟

在2000年前后，虚拟化技术逐渐发展成熟：

  • 1998年，VMware成立并首次引入X86的虚拟技术，通过运行在Windows NT上的VMware来启动Windows 95。
  • 1999年，VMWare推出可在X86平台上流畅运行的第一款VMware Workstation，从此虚拟化技术终于走下了大型机的神话。之后，研发人员和发烧友开始在普通PC和工作站上大量使用该虚拟化解决方案。
  • 1999年，IEEE颁布了用以标准化VLAN实现方案的802.1Q协议标准草案，从而可以将大型网络划分为多个小网络，使得广播和组播流量不会占据更多带宽的问题；同时，可以利用VLAN标签提供更高的网络段间的安全性。
  • 2000年，IEEE颁布了虚拟专用网（Virtual Private Network）VPN标准草案，从而使得私有网络可以跨公网进行建立。
  • 2000年，Citrix桌面虚拟化产品正式发布。
  • 2001年，VMware发布了第一个针对x86服务器的虚拟化产品ESX和GSX，即ESX-i的前身。
  • 2003年10月，Xen虚拟化项目首次面世推出了1.0版本，此时仅支持半虚拟化Para-Virtualization。之后，基于Xen虚拟化解决方案陆续被Redhat、Novell和Sun等的Linux发行版集成，作为默认的虚拟化解决方案。
  • 2003年，Microsoft收购Connectix获得虚拟化技术进入桌面虚拟化领域，之后很快推出了Virtual Server免费版。
  • 2005年，Xen 3.0发布，该版本可以在32位服务器上运行，同时该版本开始正式支持Intel的VT技术和IA64架构，从而使得Xen虚拟机可以运行完全没有修改的操作系统。该版本是Xen真正意义上可用的版本。
  • 2006年10月，以色列的创业公司Qumranet在完成了虚拟化Hypervisor基本功能、动态迁移以及主要的性能优化之后，正式对外宣布了KVM的诞生。同年10月，KVM模块的源代码被正式接纳进入Linux Kernel，成为内核源代码的一部分。备注：Qumranet在2008年被RedHat收购。
  • 2009年4月，VMware推出业界首款云操作系统VMware vSphere。

云计算的重要里程碑之一是2001年VMWare带来的可用于X86的虚拟化计划。通过虚拟机，可以在同一台物理机器上运行多个虚拟机，这意味着可以降低服务器的数量，而且速度和弹性也远超物理机。

基于虚拟机的云计算

在虚拟化技术成熟之后，云计算市场才真正出现，此时基于虚拟机技术诞生了众多的云计算产品，也陆续出现了IaaS、PaaS等平台和公有云、私有云、混合云等形态：

  • 2006年，AWS推出首批云产品Simple Storage Service (S3)和Elastic Compute Cloud（EC2），使企业可以利用AWS的基础设施构建自己的应用程序
  • 2008年4月，Google App Engine发布，是 Google 管理的数据中心中用于 WEB 应用程序的开发和托管的平台。
  • 2009年，Heroku 推出第一款公有云 PaaS （Platform-as-a-Service）
  • 2010年1月，微软发布 Microsoft Azure云平台服务。备注：Microsoft Azure 于2008年宣布。
  • 2010年7月，Rackspace Hosting和NASA联合推出了一项名为OpenStack的开源云软件计划
  • 2011年，Pivotal推出了开源版PaaS Cloud Foundry，作为Heroku PaaS的开源替代品，并于2014年底推出了Cloud Foundry Foundation。
  • 2013年底，Google 推出 Google Compute Engine （GCE）正式版。备注：GCE的测试版本于2008年发布，预览版于2012年发布。
  • 2014年，AWS推出 Lambda，允许在AWS中运行代码而无需配置或管理服务器，即Faas/Serverless。

在这期间，出现了云计算的多个重要里程碑：

  1. IaaS的出现：通过按时计费的方式租借服务器，将资本支出（Capex）转变为运营支出（Opex），这使得云计算得以大规模兴起和普及。
  2. PaaS的出现
  3. 开源IaaS的出现：云计算已经开始进入开源时代
  4. 开源PaaS的出现
  5. FaaS的出现

补充术语介绍，Capex Vs. Opex：

  • Capex = capital expenditure / 资本支出
  • Opex = operational expenditure / 运营支出

容器的兴起和编排大战

2013年，在云计算领域发生了一件影响深广的技术变革：容器。

容器技术可以说是过去十年间对软件开发行业改变最大的技术，而从虚拟机到容器，整个云计算市场发生了一次重大变革，甚至是洗牌。基于容器技术的容器编排市场，则经历了Mesos、Swarm、kubernetes三家的一场史诗大战，最终以kubernetes全面胜利而告终：

  • 2008年，LXC（Linux Container）容器发布，这是一种内核虚拟化技术，可以提供轻量级的虚拟化，以便隔离进程和资源。LXC是Docker最初使用的具体内核功能实现
  • 2013年，Docker发布，组合LXC，Union File System和cgroups等Linux技术创建容器化标准，docker风靡一时，container逐步替代VM，云计算进入容器时代
  • 2014年底，CoreOS正式发布了CoreOS的开源容器引擎Rocket（简称rkt）
  • 2014年10月，Google 开源 kubernetes，并在2015年捐赠给 CNCF
  • 2015年6月，OCI组织成立，旨在制定并维护容器镜像格式和容器运行时的正式规范，以便在不同的操作系统和平台之间移植
  • 2015年7月，Google联合Linux基金会成立了CNCF组织，kubernetes 成为 CNCF 管理的首个开源项目
  • 2015年，CNCF组织开始力推 Cloud Nativ ，完全基于开源软件技术栈，Cloud Native 的重要理念是：以微服务的方式部署应用，每个应用都打包为自己的容器并动态编排这些容器以优化资源利用
  • 2017年9月，Mesos宣布了对Kubernetes的支持
  • 2017年10月，Docker宣布将在下一版Docker，将同时支持自家调度引擎Swarm和来自Google的调度平台Kubernetes
  • 2018年3月，Kubernetes 从 CNCF 毕业，成为 CNCF 第一个毕业项目

这里有两个重要的里程碑：

  1. 2013年，Docker发布，容器逐步替代VM，云计算进入容器时代
  2. 2017年底，Kubernetes 赢得容器编排的胜利，云计算进入 Kubernetes 时代

在容器编排大战期间，以 kubernetes 为核心的CNCF Cloud Native生态系统也得以迅猛发展，云原生成为云计算市场的技术新热点。

云计算演进总结

云计算的发展演进历史，有以下规律：

  • 核心构建块的变化：

    从早期的物理服务器，通过虚拟化技术演进为虚拟机，再摆脱机器的限制缩小为构建块，最后通过容器化技术演进为目前的container

  • 隔离单元：无论是启动时间还是单元大小，物理机、虚拟机、容器一路走来，实现了从重量级到轻量级的转变

  • 供应商：从闭源到开源，从单一供应商到跨越多个供应商

下图形象的概述了这二十年云计算的演进过程：从传统预制IT、托管到云，以及云的不同形态如IaaS、PaaS、SaaS等。

对于XaaS的一路演进，可以简单归纳为：

  • 有了IaaS，客户不用关注物理机器
  • 有了PaaS，客户不用关注操作系统
  • 有了FaaS，客户不用关注应用程序

在这过去的二十年间，云计算几乎重新定义了整个行业的格局，越来越多的企业开始降低对IT基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是开始通过上云的方式来获取更强大的计算、存储能力，并实现按时按需付费。这不仅仅降低IT支出，同时也降低了整个行业的技术壁垒，使得更多的公司尤其是初创公司可以更快地实践业务想法并迅速推送到市场。

参考资料

3 - 云原生出现的背景

云原生出现的背景

软件正在改变世界

Software is Eating The World —— by Mark Andreessen, in 2011

Mark Andreessen是风险投资公司Andreessen-Horowitz的联合创始人和合伙人，该公司投资了Facebook，Groupon，Skype，Twitter，Zynga和Foursquare等，Mark Andreessen也是LinkedIn的投资者。

在2011年8月20日的华尔街日报上，Mark Andreessen发表了名为 “Why Software Is Eating the World” 的文章，当时正值惠普宣布放弃陷入困境的个人电脑业务，转而投入软件投资，并看好未来的增长潜力；与此同时，谷歌计划收购手机制造商摩托罗拉移动公司；苹果在过去几周成为美国最大的公司，以市值来判断，超越埃克森美孚。

援引原文部分内容：

我们处于戏剧性和广泛的技术和经济转变的中间，软件公司准备接管大量的经济。

越来越多的主要企业和行业正运行在软件上并提供在线服务 - 从电影到农业再到国防。许多获奖者都是硅谷式的创业技术公司，他们正在入侵和推翻既有的行业结构。

为什么现在发生这种情况？

计算机革命六十年，微处理器发明四十年，现代互联网兴起二十年，通过软件转变行业所需的所有技术终于有效，并可在全球范围内广泛传播。

十年前，当我在创办的Netscape公司时，大概5000千人使用了宽带互联网，而现在有超过20亿人使用宽带互联网。在接下来的10年里，我预计全球至少有50亿人拥有智能手机，每个人每天都可以随时随地使用这种手机充分利用互联网。

在后端，软件编程工具和基于互联网的服务可以轻松地在许多行业中推出新的全球软件驱动的初创企业 - 无需投资新的基础设施和培训新员工。2000年，当我的合伙人Ben Horowitz担任第一家云计算公司Loudcloud的首席执行官时，运营基本互联网应用程序每月的成本约为15万美元。今天在亚马逊云中运行相同的应用程序每月花费大约1500美元。

文中列出了被重塑的产业，具体有 : 最大的书店 Amazon、最多人订阅的Video service Netflix、最大的音乐公司iTune、 Spotify and Pandora等、成长最快的娱乐领域 videogame、最好的电影制片厂 Pixar、最大的行销平台 : Google、Groupon、 Facebook等、成长最快的电信公司 : Skype 、成长最快招聘公司 LinkedIn。

文章发表于2011年，在8年后的2019年再来看，感触更加深刻。

补充：有兴趣的同学可以看一下这个文章： A Review of ‘Why Software is Eating The World’: How have the companies fared?: 这是在2018年，有人撰文分析了在上文中提到的几家主要软件公司的发展情况：Facebook/Apple/Amazon/Netflix/Google。

移动互联网在加剧变化

在“Software is Eating The World”一文中，作者展望互联网规模时，写道：

在接下来的10年里，我预计全球至少有50亿人拥有智能手机，每个人每天都可以随时随地使用手机充分利用互联网。

在8年之后的2019年，我们已经可以清晰的确认Mark Andreessen的预测很正确，移动互联网时代的用户规模已经开始向人口基数看齐。

而移动互联网如此巨大的用户规模会对软件开发有什么影响？

援引Netflix的一页PPT，这里按照规模和变更速度将软件企业划分为四个象限/四种类型：

  1. 企业IT：规模小，变化慢，容易处理
  2. 电信：规模大，变化慢，主要应对硬件失败
  3. 初创公司：规模小，变化快，主要应对软件失败
  4. 网络规模的互联网企业：规模大，变化快，软硬件或者说所有东西都会出问题

在十年前乃至二十年前的互联网时代，大多数软件企业都位于上图左边的两个象限：规模或许有大有小，但是变更速度相对今天都不高。当企业发展壮大时，体现的也更多是在规模上，变更速度并不会发生质的变化。

而今天的移动互联网时代，则都位于上图右边的两个象限：无论规模是大是小，变更速度都要求非常高。并且当企业逐步发展壮大，规模十倍百倍增长时，对变更速度的要求并不会降低，甚至会要求更快。

在移动互联网时代，能够成长并发展起来的这些公司，他们的共同点是什么：

  • 快速变更，不断创新，随时调整
  • 提供持续可用的服务，因对各种可能的错误和中断
  • 弹性可扩展的系统，因对用户规模的快速增长
  • 提供新的用户体验，以移动为中心

这样的背景下，对软件开发的有了更高的要求，软件开发的方式也不得不跟随时代而变化：首当其冲的就是如何解决规模越来越大同时变更越来越快的难题。

Pivotal公司的Matt Stine对此描述如下：

We’re trying to bring a perceived conflict into balance: software-driven business agility vs. software system resiliency. We want to move fast and yet not break things. In order to do this, we’re going to change how we build software, not necessarily where we build software.

我们正努力平衡感知到的冲突：软件驱动的业务敏捷性 vs. 软件系统的弹性。我们希望快速前行而不破坏事物。为了做到这一点，我们将改变我们构建软件的方式，而不是在哪里构建软件。

软件上云大势所趋

将软件迁移到云上是应对这一挑战的自然演化方式，在过去二十年，从物理机到虚拟机到容器，从IaaS诞生到PaaS、CaaS、SaaS、FaaS一路演进，应用的构建和部署变的越来越轻、越来越快，而底层基础设施和平台则越来越强大，以不同形态的云对上层应用提供强力支撑。

关于云的定义，Matt Stine表示：

Obviously, we need a place to do this: “cloud.” I define cloud as any computing environment in which computing, networking, and storage resources can be provisioned and released elastically in an on-demand, self-service manner.

显然，我们需要一个地方来做到这一点：“云”。我将云定义为可以按需，自助服务方式弹性配置和发布计算，网络和存储资源的任何计算环境。

2006年AWS通过提供EC2服务开创了IaaS市场。通过按时计费的方式租借服务器，客户不承担资本支出，仅在使用服务时付费。将资本支出（Capex）转变为运营支出（Opex），这是云计算时代的真正开始，而之后PaaS，SaaS等的演进只是超云这个方向一步一步继续前行：

总结

前面我们谈到了软件对各行各业的渗透和对世界的改变，以及移动互联网时代巨大的用户基数下快速变更和不断创新的需求对软件开发方式带来的巨大推动力，结合上一篇文章描述的过去二十年间云计算的发展演进和软件上云的趋势，我们可以清晰的看到这样一个波澜壮阔的技术浪潮：

  • 软件正在改变世界
  • 移动互联网让这个变革影响到每一个人
  • 传统软件开发方式受到巨大挑战
  • 云计算普及，软件上云成为趋势
  • 云的形态持续在演进

援引InfoQ主编徐川老师对云计算的总结：

  • 云计算的技术逐渐发展成为它本来该有的模样；
  • 以及与这样的云所匹配的软件架构；
  • 以及与这样的架构所匹配的开发流程与方法论。

云原生由此诞生！

参考资料

4 - 云原生的定义

云原生的定义与文化

云原生定义

云原生意味着应用程序原生就被设计为在云上以最佳方式运行。

云原生是一种专门针对云上应用而设计的方法，用于构建和部署应用，以充分发挥云计算的优势。这些应用的特点是可以实现快速和频繁的构建、发布、部署，结合云计算的特点实现和底层硬件和操作系统解耦，可以方便的满足在扩展性，可用性，可移植性等方面的要求，并提供更好的经济性。同时通过拆解为多个小型功能团队来让组织更敏捷，让人员、流程和工具更好的结合，在开发、测试、运维之间进行更密切的协作。

但是当需要回答“什么是云原生”这个问题时，还是会有些困难：在过去几年间，云原生的定义一直在变化和发展演进，不同时期不同的公司对此的理解和诠释也不尽相同，因此往往会带来一些疑惑和误解。

我们一起来看看云原生定义在不同时期的变化。

Pivotal的定义

Pivotal 是Cloud Native/云原生应用的提出者，并推出了Pivotal Cloud Foundry和Spring系列开发框架，是云原生的先驱者和探路者。

2015年，来自Pivotal公司的Matt Stine编写了一本名为 迁移到云原生应用架构 的电子书，提出云原生应用架构应该具备的几个主要特征：

  • 符合12因素应用(Twelve-Factor Applications)
  • 面向微服务架构(Microservices)
  • 自服务敏捷架构(Self-Service Agile Infrastructure)
  • 基于API的协作(API-Based Collaboration)
  • 抗脆弱性(Antifragility)

在2017年10月，也是Matt Stine，在接受InfoQ采访时，则对云原生的定义做了小幅调整，将Cloud Native Architectures定义为具有以下六个特质：

  • 模块化(Modularity):（通过微服务）
  • 可观测性(Observability)
  • 可部署性(Deployability)
  • 可测试性(Testability)
  • 可处理性(Disposability)
  • 可替换性(Replaceability)

而在Pivotal最新的官方网站 https://pivotal.io/cloud-native 上，对cloud native的介绍则是关注如下图所示的四个要点：

  • DevOps
  • Continuous Delivery
  • Microservices
  • Containers

CNCF的定义

2015年CNCF建立，开始围绕云原生的概念打造云原生生态体系，起初CNCF对云原生的定义包含以下三个方面：

  • 应用容器化(software stack to be Containerized)
  • 面向微服务架构(Microservices oriented)
  • 应用支持容器的编排调度(Dynamically Orchestrated)

云原生包含了一组应用的模式，用于帮助企业快速，持续，可靠，规模化地交付业务软件。云原生由微服务架构，DevOps 和以容器为代表的敏捷基础架构组成。援引宋净超同学的一张图片来描述云原生所需要的能力与特征：

在2018年，随着社区对云原生理念的广泛认可和云原生生态的不断扩大，还有CNCF项目和会员的大量增加，起初的定义已经不再适用，因此CNCF对云原生进行了重新定位。

2018年6月，CNCF正式对外公布了更新之后的云原生的定义（包含中文版本）v1.0版本：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

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

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

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

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

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

新的定义中，继续保持原有的核心内容：容器和微服务，但是非常特别的将服务网格单独列出来，而不是将服务网格作为微服务的一个子项或者实现模式，体现了云原生中服务网格这一个新生技术的重要性。而不可变基础设施和声明式API这两个设计指导理念的加入，则强调了这两个概念对云原生架构的影响和对未来发展的指导作用。

可以通过访问 https://github.com/cncf/toc/blob/master/DEFINITION.md 查看。

云原生定义之外

从上面可以看到，云原生的内容和具体形式随着时间的推移一直在变化，即便是CNCF最新推出的云原生定义也非常明确的标注为v1.0，相信未来我们很有机会看到v1.1、v2版本。而且云原生这个词汇最近被过度使用，混有各种营销色彩，容易发生偏离。因此，云原生的定义是什么并不重要，关键还是云原生定义后面的理念、文化、技术、工具、组织结构和行为方式。

Joe Beda，Heptio 的CTO，指出：

There is no hard and fast definition for what Cloud Native means. In fact there are other overlapping terms and ideologies. At its root, Cloud Native is structuring teams, culture and technology to utilize automation and architectures to manage complexity and unlock velocity.

Cloud Native并没有硬性和牢靠的定义。实际上，还有其他重叠的术语和意识形态。从根本上说，Cloud Native正在构建团队，文化和技术，以利用自动化和架构来管理复杂性和解锁速度。

We are still at the beginning of this journey.

我们还处在这个旅程的开始阶段。

Christian Posta 指出：

“Cloud native” is an adjective that describes the applications, architectures, platforms/infrastructure, and processes, that together make it economical to work in a way that allows us to improve our ability to quickly respond to change and reduce unpredictability. This includes things like services architectures, self-service infrastructure, automation, continuous integration/delivery pipelines, observability tools, freedom/responsibility to experiment, teams held to outcomes not output, etc.

“云原生”是一个形容词，用于描述应用，结构，平台/基础设施和流程，这些共同促使我们以比较经济的工作方式来提高能力，实现快速响应变化和减少不可预测性。包括服务架构，自助服务基础设施，自动化，持续集成/交付管道，可观察性工具，实验的自由/责任，坚持结果而不是产出的团队等。

在下一节，我们将深入分解云原生的理念和诉求，来看看云原生是通过什么方式来实现目标。

参考资料

5 - 云原生的目标

云原生的目标

关键目标

根据前面对云计算历史的追溯，对云原生出现背景的分析，以及对不同时期云原生定义的回顾总结，这里给出云原生的几个关键目标：

  • 规模：

    要求云原生服务能够适应不同的规模（包括但不限于用户规模/部署规模/请求量），并能够在部署时动态分配资源，以便在不同的规模之间快速和平滑的伸缩。典型场景如：初创公司或新产品线快速成长，用户规模和应用部署规模在短时间内十倍百倍增长；促销、季节性、节假日带来的访问量波动，高峰时间段的突发流量等。

  • 可用：

    通过各种机制来实现应用的高可用，以保证服务提供的连续性。

  • 敏捷

    快速响应市场需求

  • 成本

    充分有效的利用资源

TBD：这里稍后补充详细信息。

解决各目标之间的冲突

在这四个核心目标之间，存在彼此冲突的情况：

  • 规模和敏捷之间的冲突：

    规模大而又要求敏捷，我们比喻为“巨人绣花”。

  • 规模和可用性之间的冲突：

    规模大而要求可用性高，我们比喻为“大象起舞”。

  • 敏捷和可用性之间的冲突：

    敏捷而要求高可用，我们比喻为“空中换发”。

而云原生应用，必须要在同时满足这三个目标的前提下，还要实现成本控制。

稍后的章节，将通过飞轮效应来讲解云原生是如何逐步产生并积累出来的，并在云原生特征中将这四个核心目标拆解为十几个特征来分别介绍各个目标的达成方式。后面会详细讲解云原生的代表技术和理念是如何围绕这些核心目标和特征来实现的。

6 - 云原生的飞轮效应

云原生的飞轮效应

6.1 - 云原生的飞轮效应概述

云原生的飞轮效应概述

在云原生之前

在云原生出现之前，软件开发领域存在如下图的基本循环：

  • 软件供应商开发软件产品
  • 产品提供各种功能
  • 这些功能可以满足客户的需求
  • 于是有更多的客户使用这些产品，产品普及率的增加会带来更多利润，促使软件开发商继续改进产品和加强功能

在这个闭环中，迭代速度通常并不快（典型如大型电信产品一年只做一两次大版本发布），用户规模也比较小（除了电信软件，和目前移动互联网时代相比有一到两个数量级的差异），因此客户（包括开发、测试、运维、市场运营等）需求主要集中在产品的功能性。

云原生时代的新挑战

随着互联网，尤其是移动互联网的发展，用户规模剧增，对功能性的要求急剧增加：

而在满足功能之外，对效率的要求更加迫切：需要在开发、测试、部署、运维等几乎所有环节都大幅提升工作效率，以快速变更来实现对市场的快速响应，同时还必须尽量控制成本：

对速度和成本的追求催生了云计算市场，并一步一步演进到云原生架构，出现了容器、微服务、服务网格、不可变基础设施等技术和理念：

云原生架构，不仅仅体现在功能性方面的进一步改善和加强，而且在易用性方面有了质的飞跃：

最终，云原生不仅仅在功能性方面可以满意客户需求，还通过改善易用性极大的提升了客户体验。在下图中，我们将客户需求升级为客户体验。而良好的用户体验，会直接帮助客户提升各种效率：

因此，在原有的闭环之外，云原生还形成了一个新的闭环：

  • 通过云原生架构，在功能性之外提供易用性
  • 通过提供易用性，提升客户体验
  • 提供提升客户体验，来帮助客户提高效率
  • 而效率的持续改进，会促使云原生架构进一步演进，出现更多易用性更好的理念和技术，云原生提供商也愿意加强产品易用性方面的表现

最终，在云原生时代，以客户体验为中心，形成功能性和易用性两个闭环：

7 - 云原生特征

云原生的特征

7.1 - 概述

云原生的特征概述

云原生的特征列表

在前面我们将云原生的目标分解为四个核心目标：

现在将这四个云原生核心目标拆解为多个云原生特性：

特征 规模（Scale） 可用（Available） 敏捷（Agility） 成本（Cost）
隔离性(Isolation) ✔️ ✔️ ✔️
模块化(Modularity) ✔️ ✔️ ✔️
可组合(Composable) ✔️ ✔️
容器化(Containerized) ✔️ ✔️ ✔️
弹性(Resiliency) ✔️ ✔️
可替换性(Replaceability) ✔️ ✔️
自动化(Automation) ✔️ ✔️ ✔️ ✔️
可观测性(Observability) ✔️ ✔️
可测试性(Testability) ✔️ ✔️
可移植性(Portability) ✔️ ✔️ ✔️
安全(Security) ✔️
移动性(Mobility) ✔️

7.2 - 隔离性(Isolation)

云原生特征之隔离性

隔离性是云计算的最基本的特征。

系统层面的隔离性

云计算中分享的计算能力、网络能力、存储能力，都必须以某种方式实现隔离，才可以提供给客户（或者说租户）使用。

而云原生应用也要求与物理机器和操作系统解耦，理论上说，云原生应用是在更高的抽象级别（即云）上运行，和物理机器和操作系统不应该有直接的依赖关系。

虚拟化技术的历史

系统层面隔离性的实现直接依赖于虚拟化技术。虚拟化技术是云计算的最重要的也是最关键的基础技术：没有虚拟化技术，隔离性和云计算都无从谈起。

在云计算的历史上，虚拟化有两个关键技术出现，都极大的推动了云计算的发展：

  1. 虚拟机（Virtual Machine）技术

  2. 容器（Container）技术

虚拟化技术的飞轮

在虚拟机技术出现之前的物理机时代，客户需要直接面对物理机器，比如自行购买机器、安装操作系统、搭建机房、准备网络等。当然也出现了一些改善型的服务，比如服务器托管就免除了机房和网络的工作，而服务器租用则将购买服务器变成了租用服务器，但原则上用户依然是需要面对物理机器。

后来通过在服务器软件（比如说在web应用服务器如Apache、IIS）之上，提供虚拟主机服务，容许用户运行静态网站、或者PHP、ASP等脚本语言，一定程度上实现了有限的隔离性。

虚拟机技术出现之后，基于虚拟机技术（尤其是成熟后的Xen、KVM等）的 VPS 可以提供更多的功能，带来更好的客户体验，更充分的利用物理机器的资源。之后基于虚拟机技术的云计算模式一路发展，IasS/PaaS/SaaS/FaaS 相继出现并成熟。

虚拟机技术有非常好的隔离性，但相对较重，在 LXC、cgroup 等技术发展成熟后，基于共享内核的容器技术出现，由于轻量高效的特点迅速普及，CaaS  出现，IasS/PaaS/SaaS/FaaS 等也随即从基于虚拟机转为基于容器。之后以 Kubernetes 为代表的容器编排技术更是将容器的优点充分发挥。

但从隔离性上说，容器技术由于共享Liunx内核，在隔离性上始终存在不足，而传统虚拟机技术和容器相比又显得太重。最近，以 gvisor 和 kata container 为代表的新型虚拟机/容器技术正在迅速发展，目标是希望能融合虚拟机/容器的优点。目前这些技术还在早期发展阶段，尚未普及。未来会带来什么样的新变化，值得期待。

子系统间的隔离性

当单个应用程序，通过模块化技术（如微服务）拆解为多个相互调用相互协作的服务之后，就出现了子系统之间隔离性的要求。

如图所示，假定当前系统中所有服务的可用性就是99.99%，那么多一个服务依赖多个服务（包括级联依赖），由于被依赖的服务可能失败，因此当前服务的可用性是无法维持在99.99%的，而是随着服务依赖的数量增加而下降：

从实际情况看，通常服务有10个左右的依赖服务（注意包括级联依赖）是很正常的，某些特殊的服务有100个左右的依赖服务也是可能的，而这种情况下，服务的可用性会直接下降到99.9%和99%。

因此，为了达到可用性的目标，将最终的可用性维持在99.99%，有两个方法：

  1. 提供每个组件的可用性：要求每个组件的可用性上升一个等级，比如达到99.999%，很明显这个难度很大，尤其成本会无法控制

  2. 隔离发生故障的组件：

    打破导致系统失败的级联依赖，实现子系统隔离: 让失败只发生在一个组件中，而不导致级联系统失败。

而子系统隔离需要实现：

  • 主动/被动健康检查：排除不健康的实例
  • 熔断、重试、超时
  • 服务失败时提供fallback
  • 金丝雀推出 （Canary Push）
  • 蓝绿部署：应该就是现在常说的蓝绿部署
  • 灰度发布：先小范围试错，验证OK再全面上线
  • Zone Isolation：区域隔离，以应对基础设施失败，如电力故障
  • Region Isolation：地域隔离，通过DNS等技术手段切换Region

7.3 - 可组合(Composable)

云原生的特征之可组合(Composable)

可组合(Composable)

Each service is composable: this implies that the service is designed to allow it to be part of other applications. At the minimum, each Service has an Application Programming Interface (API) that is uniform and discoverable, and in addition can have well defined behaviors for registration, discovery, and request management.

每个服务都是可组合的：这意味着该服务旨在使其成为其他应用程序的一部分。每个服务至少具有统一且可发现的应用程序编程接口（API），此外还可以为注册，发现和请求管理定义良好的行为。

7.4 - 容器化(Containerized)

云原生的特征之容器化(Containerized)

容器化(Containerized)

以容器方式打包的应用程序实现了 dev/prod 的一致性，促进代码和组件重用并简化运维。

打包为轻量级容器：云原生应用程序是打包为轻量级容器的独立自治服务的集合。与虚拟机不同，容器可以快速扩展和扩展。由于扩展单元转移到容器，因此优化了基础架构利用率。

部署在自助服务，弹性云基础架构上：云原生应用程序部署在虚拟，共享和弹性基础架构上。它们可以与底层基础架构保持一致，以动态增长和缩小 - 根据不同的负载调整自身。

7.5 - 模块化(Modularity)

云原生的特征之模块化(Modularity)

模块化的理念

在软件设计中，模块化是管理系统复杂度的重要手段。随着应用程序规模的增大，复杂性越来越高。为了降低应用的复杂度，增加代码重用，需要将应用分解为更小更易于理解的部分。实践中，我们通常将应用程序按照功能的不同划分为独立但相互协作的部分，称为“模块”。

模块是可以部署、管理、重用和组合的单元，多个模块相互协作，组成完整的应用程序，对外提供功能和服务。

模块化的演进

模块化技术由来已久，早不是新的概念，而对于云原生应用来说模块化尤为重要：云原生架构从诞生开始就以SOA、微服务等方式在践行模块化，近年来还出现了Function规模的模块。

我们来看一下模块化的演进过程：

可以清晰的看到，模块化的演进方向是模块的粒度越来越小。

模块化技术的飞轮

结合飞轮理论来细致的追溯模块化演进过程中的粒度变化带来的技术发展：

  1. 进程内模块：早期的模块化更多的是关注如何拆解系统为多个子系统，拆分功能模块为类库、动态链接库等可重用机制，为了更好的管理这些拆分出去的功能模块，实现组合和重用，还建立了非常完备的依赖管理体系，如Java中我们非常熟悉的Java Maven、Gradle等。

    此时的模块只是在打包、发布时独立存在，应用程序运行起来之后就被应用程序加载，隔离性并不好。因此后来出现了加强进程内模块隔离和管理的思路，出现了典型如 OSGi 技术和 Java9 中引入的 Modular 技术。

    由于模块都在同一个进程内，因此此时对模块的调用都是方法调用。

  2. 服务：后面出现SOA架构，提倡服务化，即将模块以服务的方式从应用进程中分离除去并独立部署，应用以远程调用的方式调用SOA服务提供的公共API。SOA架构在进程层面将应用分解，通过对SOA服务的组合和重用来满足应用的需求。SOA时代，产生了一系列非常优秀的服务化框架如dubbo/HSF/SOFA等。

  3. 微服务：在SOA长期实践的基础上，微服务的理念产生，除了颗粒进一步缩小，还要求不同的微服务也要进程分离，同时为了满足高内聚的要求，对数据库等内在资源的访问也要求隔离。微服务时代，出现了大家熟悉的spring cloud。

    在微服务理念出现时，正值容器技术出现，微服务+容器的组合相互促进成为市场热点。后面service mesh理念出现，k8s等容器编排系统成熟，service mesh + k8s成为微服务+容器组合的升级版本。

  4. 函数：再进一步，将模块的颗粒缩小到函数级别，配合FaaS、Serverless平台使用。

微服务

微服务在云原生中的重要性，我们可以从前面云原生的定义中感受到：所有方式的云原生定义，都会将微服务作为重点。甚至在很多强调模块化的地方，都会明确指明微服务。

可以说，微服务是云原生中模块化最典型的实现模式。

参考资料

7.6 - 弹性(Resiliency)

云原生的特征之弹性(Resiliency)

应对单个容器，机器甚至数据中心的故障，满足不同水平的需求。

如果服务能够在中断和故障中存活并保持在线，则服务具有弹性。此外，他们还可以充分利用云中提供的自动故障转移和灾难恢复机制。

Each service is resilient: this means that each service is highly-available and can survive infrastructure failures. This characteristic limits the failure domain, due to software bugs or hardware issues.

每项服务都具有弹性：这意味着每项服务都具有高可用性，可以承受基础架构故障。由于软件错误或硬件问题，此特性限制了故障域。

Resiliency

Resiliency refers to the application’s ability to survive and remain online during an infrastructure outage or failure. A properly designed cloud-native application would have multiple techniques to retry failed transactions and there would be multiple instances of the application services running on other servers or VMs.

Legacy applications that were not designed for a cloud can use tools within a hypervisor or cloud infrastructure such as traffic load balancing, clustering, and server/VM failover, but these are not as effective and transparent to the end user as a cloud-native application’s resiliency. There are many other aspects of resiliency and cloud-native application design benefits that will be covered later in this chapter.

弹性

弹性是指应用程序在基础设施中断或故障期间生存并保持在线的能力。正确设计的云原生应用程序将具有多种技术来重试失败的事务，并且将在其他服务器或VM上运行多个应用程序服务实例。

不是为云设计的传统应用程序可以使用虚拟机管理程序或云基础架构中的工具，例如流量负载平衡，群集和服务器/ VM故障转移，但这些应用程序对于最终用户而言并不像云原生应用程序那样有效和透明。弹性。弹性和云原生应用程序设计优势还有许多其他方面，本章稍后将对此进行介绍。

7.7 - 可替换性(Replaceability)

云原生的特征之可替换性(Replaceability)

可替换性的由来

可替换性和虚拟化技术密切相关，当应用运行的平台从物理机到虚拟机再到容器，然后配合自动化技术，尤其是Kubernetes这种功能强大的成熟的容器编排平台，创建和销毁一个应用的速度和开销都很理想。加上容器和镜像带来的不可变性，如果应用本身是无状态的，那么这个应用就可以非常容易的做到随意替换任何一个运行中的实例。

虽然说在物理机和虚拟机时代实现类似的可替换性也是有办法的，但是毫无疑问的是在容器时代实现可替换性要简单和实用的多。“容器化 + 自动化 + 不可变性 + 无状态” 为可替换性带来了巨大的实用价值。

Pets vs. Cattle

关于可替换性，有一个非常流行的谚语：“Pets vs. Cattle”，宠物和奶牛（或者直白一点翻译为 牲口 更容易理解）。

援引一段对Pets(宠物)的解释：

Servers or server pairs that are treated as indispensable or unique systems that can never be down. Typically they are manually built, managed, and “hand fed”. Examples include mainframes, solitary servers, HA loadbalancers/firewalls (active/active or active/passive), database systems designed as master/slave (active/passive), and so on.

服务器或服务器对，被视为必不可少或独一无二的系统，永不停机。通常，它们是手动构建，管理和“手工伺候”的。示例包括大型机，单独服务器，HA负载均衡器/防火墙，设计为主/从的数据库系统等。

援引一段对Cattle(奶牛/牲口)的解释：

Arrays of more than two servers, that are built using automated tools, and are designed for failure, where no one, two, or even three servers are irreplaceable. Typically, during failure events no human intervention is required as the array exhibits attributes of “routing around failures” by restarting failed servers or replicating data through strategies like triple replication or erasure coding. Examples include web server arrays, multi-master datastores such as Cassandra clusters, multiple racks of gear put together in clusters, and just about anything that is load-balanced and multi-master.

两个以上服务器的部署，使用自动化工具构建，专为故障而设计，其中每一台都是可以替代的，甚至两台，三台也是可以替代的。通常，在故障事件期间不需要人为干预，因为部署可以通过重新启动故障服务器或通过三重复制或擦除编码等策略复制数据来展示“故障路由”的属性。示例包括Web服务器部署，多主数据存储（如Cassandra集群），以及几乎任何负载均衡和多主机。

简单说，如何判断某个机器、服务是宠物还是牲口，只要简单评估一下：如果它发生失败无法工作，你是倾向于让它恢复，还是倾向于简单抛弃然后拿另一个替换。

云原生下的角色转变

在云原生时代，有一些概念发生了角色转变：有些从宠物转变为牲口，有些从牲口转变为宠物。

IP地址：从宠物到牲口

在云原生之前，尤其是容器技术出来之前，IP地址是非常重要的，某些情况下几乎等同于一台机器（物理机或者虚拟机）的标致，通常IP是固定的不会轻易更改，外部系统也经常是通过IP地址来实现对这个机器的访问。

而在容器时代，容器被频繁创建和销毁，容器的IP地址不再固定而是动态变化，这是IP地址已经不在适合作为标识而使用。举例，在Kubernetes中取而代之的是标签（Label）和标签选择器（Label Selector），通过诸如 “app: service-1” 这样的方式来定位目标容器

端口：从牲口到宠物

TBD

参考资料

7.8 - 自动化(Automation)

云原生的特征之自动化性(Automation)

自动化性(Automation)

The CN application needs to be abstracted completely from the underlying infrastructure stack. This is key as development teams can focus on solely writing their software and does not need to worry about the maintenance of the underlying OS/Storage/Network. One of the key challenges with monolithic platforms (http://www.vamsitalkstech.com/?p=5617) is their inability to efficiently leverage the underlying infrastructure as they have a high degree of dependency to it. Further, the lifecycle of infrastructure provisioning, configuration, deployment, and scaling is mostly manual with lots of scripts and pockets of configuration management.

CN应用程序需要从底层基础架构堆栈中完全抽象出来。这是关键，因为开发团队可以专注于单独编写软件，而无需担心底层OS /存储/网络的维护。单片平台（http://www.vamsitalkstech.com/?p=5617）面临的主要挑战之一是它们无法有效利用底层基础架构，因为它们对它有很高的依赖性。此外，基础架构配置，配置，部署和扩展的生命周期大多是手动的，具有大量脚本和配置管理口袋。

另一方面，考虑到其规模，CN应用程序必须非常轻松。的规定部署规模循环高度与所述应用程序自动调整为满足需求，资源约束和从故障中恢复无缝自动化。我们在之前的博客中讨论了Kubernetes。

The CN application, on the other hand, has to be very light on manual asks given its scale. The provision-deploy-scale cycle is highly automated with the application automatically scaling to meet demand and resource constraints and seamlessly recovering from failures. We discussed Kubernetes in one of the previous blogs.

自动化功能：云原生应用程序可以高度自动化。它们与基础设施概念作为代码相得益彰。实际上，仅需要一定程度的自动化来管理这些大型和复杂的应用程序。

7.9 - 可观测性(Observability)

云原生的理念之可观测性(Observability)

可观测性(Observability)

7.10 - 可测试性(Testability)

云原生的特征之可测试性(Testability)

可测试性(Testability)

support Continuous Integration and Continuous Delivery…

The reduction of the vast amount of manual effort witnessed in monolithic applications is not just confined to their deployment as far as CN applications are concerned. From a CN development standpoint, the ability to quickly test and perform quality control on daily software updates is an important aspect. CN applications automate the application development and deployment processes using the paradigms of CI/CD (Continuous Integration and Continuous Delivery).

The goal of CI is that every time source code is added or modified, the build process kicks off & the tests are conducted instantly. This helps catch errors faster and improve quality of the application. Once the CI process is done, the CD process builds the application into an artifact suitable for deployment after combining it with suitable configuration. It then deploys it onto the execution environment with the appropriate identifiers for versioning in a manner that support rollback. CD ensures that the tested artifacts are instantly deployed with acceptance testing.

特色＃4他们支持持续集成和持续交付……

就CN应用程序而言，单片应用程序中大量手动工作的减少不仅限于它们的部署。从CN开发的角度来看，快速测试和执行日常软件更新质量控制的能力是一个重要方面。CN应用程序使用CI / CD（持续集成和持续交付）的范例自动化应用程序开发和部署过程。

CI的目标是每次添加或修改源代码时，构建过程开始，测试立即进行。这有助于更快地捕获错误并提高应用程序的质量。完成CI过程后，CD过程将应用程序与适当的配置组合后，将应用程序构建为适合部署的工件。然后，它以支持回滚的方式将其部署到具有适当版本控制标识符的执行环境中。CD确保通过验收测试立即部署测试的工件。

和其他的关系

  • 自动化

7.11 - 可移植性(Portable)

云原生的特征之可移植性(Portable)

可移植性(Portable) No Lock In

开源软件堆栈支持在任何公有云或私有云（或两者组合的混合云）上部署，避免Cloud绑定（供应商绑定）。

  • Software is eating the world
  • Open Source is eating Software
  • Cloud is eating Open Source

如果没有通用开源软件，我们将冒着Cloud绑定的风险。

7.12 - 安全(Security)

云原生的特征之安全(Security)

安全(Security)

It goes without saying that security is a critical part of CN applications and needs to be considered and designed for as a cross-cutting concern from the inception. Security concerns impact the design & lifecycle of CN applications ranging from deployment to updates to image portability across environments. A range of technology choices is available to cover various areas such as Application level security using Role-Based Access Control, Multifactor Authentication (MFA), A&A (Authentication & Authorization) using protocols such as OAuth, OpenID, SSO etc. The topic of Container Security is very fundamental one to this topic and there are many vendors working on ensuring that once the application is built as part of a CI/CD process as described above, they are packaged into labeled (and signed) containers which can be made part of a verified and trusted registry. This ensures that container image provenance is well understood as well as protecting any users who download the containers for use across their environments.

毫无疑问，安全性是CN应用程序的关键部分，需要从一开始就考虑并设计为一个跨领域的关注点。安全问题影响CN应用程序的设计和生命周期，从部署到更新，再到跨环境的映像可移植性。一系列技术选择可用于涵盖各个领域，例如使用基于角色的访问控制的应用程序级安全性，多因素身份验证（MFA），使用OAuth，OpenID，SSO等协议的A＆A（身份验证和授权）.Container的主题安全性是本主题的基础，并且有许多供应商致力于确保一旦应用程序构建为上述CI / CD过程的一部分，它们被打包成带标签（和签名）的容器，这些容器可以成为经过验证和信任的注册表的一部分。这样可以确保容器图像出处得到充分了解，并保护下载容器以便在其环境中使用的任何用户。

TDWI调查还向组织询问了云分析采用的障碍。毫不奇怪，两个最重要的问题是安全性和数据隐私 - 这些问题一直困扰着云计算的采用。

Authentication systems

Applications that might have run within existing enterprise datacenters often utilized the internal corporate Microsoft Active Directory or some other identity management system to authenticate user logons. Ideally, applications hosted in a cloud should not assume Active Directory or the internal identity system is available; instead, they should favour an industry standard for authentication and directories such as LDAP, OAUTH, or SAML. These provide authentication capabilities with OAUTH and SAML a bit more robust and appropriate as part of a single sign-on (SSO) system.

There is also a growing trend towards IaaS and SaaS identity management systems, where firms ‘outsource’ authentication and authorization to vendors when integrate at the API level with various directory protocols and identity systems [eg. Centrify and Azure EMS].

认证系统

可能在现有企业数据中心内运行的应用程序通常使用内部企业Microsoft Active Directory或其他一些身份管理系统来验证用户登录。理想情况下， 托管在云中的应用程序不应假定Active Directory或内部标识系统可用 ; 相反，他们应该支持行业标准的身份验证和目录，如LDAP，OAUTH或SAML。这些提供OAUTH和SAML的身份验证功能更加健壮，适合作为单点登录（SSO）系统的一部分。

IaaS和SaaS身份管理系统也呈增长趋势，当API级别与各种目录协议和身份系统集成时，公司将认证和授权外包给供应商[例如。Centrify和Azure EMS]。

7.13 - 移动性(Mobility)

云原生的特征之移动性(Mobility)

移动性(Mobility)

Mobility

With the increasing number of applications hosted in a cloud environment, users or consumers often use mobile computing devices such as tablets or smartphones. The legacy assumption that end users only have desktop PCs or a particular PC operating system (OS) is no longer true.

The concept of mobile first was adopted over the past few years but is more recently replaced with ubiquitous access the intention of both being that applications need to be designed with the ability for users to access the system through any form of computer device, from any location, and have the same experience. Mobility might also require additional security and asset configuration management features and tools to ensure identity, data encryption, data privacy, and synchronization to mobile devices for offline viewing.

Key Take-Away

Ubiquitous access, elasticity, resiliency, and persistent data are the keys to successful cloud-native applications. Applications and data must always be accessible, from any form of computing device and any location, and with a consistent user experience.

流动性

随着云环境中托管的应用程序数量的增加，用户或消费者通常使用平板电脑或智能手机等移动计算设备。最终用户只有台式PC或特定PC操作系统（OS）的传统假设不再适用。

移动优先的概念 在过去几年中被采用，但最近被无处不在的访问所取代， 其意图是需要设计应用程序，使用户能够通过任何形式的计算机设备从任何位置访问系统，并有相同的经验。移动性还可能需要额外的安全性和资产配置管理功能和工具，以确保身份，数据加密，数据隐私以及与移动设备的同步以供离线查看。

Key Take-Away

无处不在的访问，弹性，弹性和持久数据是成功的云原生应用程序的关键。必须始终可以从任何形式的计算设备和任何位置访问应用程序和数据，并且具有一致的用户体验。

因此，CN应用程序需要本地支持移动应用程序。这包括支持一系列移动后端功能的能力 - 包括移动设备的身份验证和授权服务，位置服务，客户识别，推送通知，云消息传递，iOS和Android开发工具包等。

Accordingly, CN applications need to natively support mobile applications. This includes the ability to support a range of mobile backend capabilities – ranging from authentication & authorization services for mobile devices, location services, customer identification, push notifications, cloud messaging, toolkits for iOS and Android development etc.

7.14 - 可扩展性(Scalability)

云原生的特征之可扩展性(Scalability)

针对现代分布式系统环境进行了优化，能够扩展到数万个自我修复的节点。

应用程序及其所有服务应在需求增加时进行扩展和上下扩展。这种动态管理的服务可确保有效使用资源。

Each service is elastic: this means that each service can scale-up or scale-down independently of other services. Ideally the scaling is automatic, based on load or other defined triggers. Cloud computing costs are typically based on usage, and being able to dynamically manage scalability in a granular manner enables efficient use of the underlying resources.

每项服务都具有弹性：这意味着每项服务都可以独立于其他服务进行扩展或缩小。理想情况下，基于负载或其他定义的触发器，缩放是自动的。云计算成本通常基于使用，并且能够以细粒度方式动态管理可伸缩性，从而能够有效地使用底层资源。

Scalability: Cloud services enable on-demand capacity and allow organizations to scale up and out more dynamically. For example, you can cater seasonal demand in a cost-effective way.

可扩展性：云服务支持按需容量，允许组织更加动态地扩展和扩展。 例如，您可以以经济有效的方式满足季节性需求。

Elasticity

Applications should be elastic as traffic, demand, and usage increases. Elastic means that an application can scale out (adding more compute resources or additional virtual machines) to handle an increase in workload or utilization. A properly designed cloud-native application should be able to automatically detect high utilization and trigger the necessary steps to start up new VMs or application services to handle peak workloads. Then, when peak utilization diminishes, it should reduce VMs or compute instances.

Legacy applications that were not specifically designed to run in the cloud can often use a VM hypervisor to monitor processor and memory utilization, triggering more VM instances when a manually defined peak- utilization threshold is attained. These elasticity techniques make it possible for the applications to take advantage of the power of the cloud infrastructure to dynamically scale—even if the application wasn’t originally designed as cloud-native; although, a cloud native application is more efficient.

弹性

随着流量，需求和使用量的增加，应用程序应具有弹性。弹性意味着应用程序可以向外扩展（添加更多计算资源或其他虚拟机）以处理工作负载或利用率的增加。正确设计的云原生应用程序应该能够自动检测高利用率并触发启动新VM或应用程序服务以处理峰值工作负载的必要步骤。然后，当峰值利用率减少时，它应该减少VM或计算实例。

未专门设计为在云中运行的传统应用程序通常可以使用VM虚拟机管理程序来监视处理器和内存利用率，在达到手动定义的峰值利用率阈值时触发更多VM实例。这些弹性技术使应用程序可以利用云基础架构的强大功能进行动态扩展 - 即使应用程序最初并非设计为云原生的; 但是，云本机应用程序更有效。

我为什么要迁移到云端？关于BI，分析和云的2016年第四季度TDWI最佳实践报告探讨了这个问题，向组织询问了他们在云中进行分析的三大理由。

这些回应非常具有启发性，并非出乎意料，公司将可扩展性，灵活性和成本列为前三个原因。

CN架构的首要特征是能够动态支持大量用户，大型开发组织和高度分散的运营团队。当人们认为云计算本质上是多租户时，这一要求就更为重要。

在这个区域内，需要考虑典型的问题 -

  1. 能够动态扩展部署足迹（纵向扩展）以及减少占用空间（缩小规模）
  2. 能够优雅地处理跨层的故障，从而破坏应用程序的可用性
  3. 通过确保组件本身提供松散耦合来适应大型开发团队的能力
  4. 能够使用几乎任何类型的基础架构（计算，存储和网络）实施

The first & foremost characteristic of a CN Architecture is the ability to dynamically support massive numbers of users, large development organizations & highly distributed operations teams. This requirement is even more critical when one considers that cloud computing is inherently multi-tenant in nature.

Within this area, the typical concerns need to be accommodated –

  1. the ability to grow the deployment footprint dynamically (Scale-up) as well as to decrease the footprint (Scale-down)
  2. the ability to gracefully handle failures across tiers that can disrupt application availability
  3. the ability to accommodate large development teams by ensuring that components themselves provide loose coupling
  4. the ability to work with virtually any kind of infrastructure (compute, storage and network) implementation

和模块化微服务的关系

通过使用微服务，云原生应用程序可以独立自动扩展服务。这在大多数情况下会自动发生，因此不需要每天管理它们。

参考资料

7.15 - 可用性(Availability)

云原生的特征之可用性(Availability)

可用性(Availability)

High availability: The cloud may enable organizations to achieve availability and business continuity requirements that may not be able to be achieved otherwise or that would be cost- prohibitive.

高可用性：云可以使组织实现可用性和业务连续性要求，否则可能无法实现或成本过高。

7.16 - 成本(Cost)

云原生的特征之成本(Cost)

成本(Cost)

Budgeting: Often, organizations seek cloud services and claim cost advantages, but more likely, they seek the clarity in budget because consumption-based pricing enables IT organizations to perform better budget forecasting. Specifically, adoption of cloud services allows organizations to budget IT on operating expenses instead of capital expenses.

预算编制：通常，组织寻求云服务并声称成本优势，但更有可能的是，他们寻求预算的清晰度，因为基于消费的定价使IT组织能够执行更好的预算预测。 具体而言，云服务的采用允许组织针对运营支出而非资本支出来预算IT。

7.17 - 效率(Efficiency)

云原生的特征之效率(Efficiency)

通过中央编排过程实现了微服务的动态管理和调度，提高了效率和资源利用率，降低了与维护和运营相关的成本。

Defined, policy-driven resource allocation: Finally, cloud-native applications align with the governance model defined through a set of policies. They adhere to policies such as central processing unit (CPU) and storage quotas, and network policies that allocate resources to services. For example, in an enterprise scenario, central IT can define policies to allocate resources for each department. Developers and DevOps teams in each department have complete access and ownership to their share of resources.

定义的，策略驱动的资源分配：最后，云原生应用程序与通过一组策略定义的治理模型保持一致。它们遵循诸如中央处理单元（CPU）和存储配额以及将资源分配给服务的网络策略等策略。例如，在企业方案中，中央IT可以定义策略以为每个部门分配资源。每个部门的开发人员和DevOps团队都拥有对其资源共享的完全访问权和所有权。

7.18 - 敏捷(Agility)

云原生的特征之敏捷(Agility)

敏捷(Agility)

Organizations often benefit from faster time to value with cloud services. IT organizations may be more agile because they can prioritize other tasks. Sometimes a specific line of business benefits because it can spin up capacity faster. This will vary depending on the strategy and what specific cloud services are under investigation. Organizations face deadlines related to infrastructure and software support end of life, regulatory compliance, or seasonal business opportunities that require a rapid application delivery or migration. Note that agility is often conflated with productivity

组织通常可以通过云服务更快地实现价值。 IT组织可能更敏捷，因为他们可以优先考虑其他任务。 有时，特定的业务线会带来好处，因为它可以更快地提高容量。 这取决于策略以及正在调查的具体云服务。 组织面临与基础架构和软件支持生命周期终止，法规遵从性或需要快速应用程序交付或迁移的季节性业务机会相关的最后期限。 请注意，敏捷性通常与生产力相关