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

返回本页常规视图.

云原生特征

云原生的特征

1 - 概述

云原生的特征概述

云原生的特征列表

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

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

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

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

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），此外还可以为注册，发现和请求管理定义良好的行为。

4 - 容器化(Containerized)

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

容器化(Containerized)

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

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

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

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平台使用。

微服务

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

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

参考资料

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 - 可替换性(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

参考资料

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.

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

9 - 可观测性(Observability)

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

可观测性(Observability)

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确保通过验收测试立即部署测试的工件。

和其他的关系

  • 自动化

11 - 可移植性(Portable)

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

可移植性(Portable) No Lock In

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

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

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

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]。

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.

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

和模块化微服务的关系

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

参考资料

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.

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

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。

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团队都拥有对其资源共享的完全访问权和所有权。

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