【云原生生态圈】什么是云原生?

本专栏将从基础开始，循序渐进，由浅入深讲解云原生相关知识，希望大家都能够从中有所收获，也请大家多多支持。
专栏地址:云原生专栏
如果文章知识点有错误的地方，请指正！大家一起学习，一起进步。

云原生定义

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

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

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

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

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.

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

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

云原生的目标

云原生的目标

关键目标

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

• 规模：

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

• 可用：

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

• 敏捷

  快速响应市场需求

• 成本

  充分有效的利用资源

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

解决各目标之间的冲突

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

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

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

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

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

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

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

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

云原生的飞轮效应概述

云原生的飞轮效应概述

在云原生之前

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

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

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

云原生时代的新挑战

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

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

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

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

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

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

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

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

云原生的特征

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

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

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

隔离性(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

可组合(Composable)

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

容器化(Containerized)

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

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

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

模块化(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平台使用。

微服务

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

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

弹性(Resiliency)

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

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

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

不是为云设计的传统应用程序可以使用虚拟机管理程序或云基础架构中的工具，例如流量负载平衡，群集和服务器/ VM故障转移，但这些应用程序对于最终用户而言并不像云原生应用程序那样有效和透明。

可替换性(Replaceability)

可替换性的由来

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

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

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

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

自动化(Automation)

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

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

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

可测试性(Testability)

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

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

可移植性(Portable)

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

安全(Security)

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

移动性(Mobility)

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

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

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

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

可扩展性(Scalability)

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

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

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

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

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

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

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

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

可用性(Availability)

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