是什么让互联网公司实现了快速增长？
- Speed of innovation （快速的创新）
- Always-available services （服务高可用）
- Web scale （web高可扩展）
- Mobile-centric user experiences （以移动为中心的体验）
Moving to the cloud is a natural evolution of focusing on software,and cloud-native application architectures are at the center of how
these companies obtained their disruptive character. By cloud, we mean any computing environment in which computing, networking, and storage resources can be provisioned and released elastically in an on-demand, self-service manner.
移动到云计算是专注于软件的自然进化，云原生应用程序架构是其中的核心这些公司获得了颠覆性的特点。通过云计算,我们指任何计算环境，其中的计算，网络和存储资源可以配置和释放弹性按需，自助服务的方式。
Why Cloud-Native Application Architectures?
Speed 高速
传统软件企业提供软件功能的时间过长，制作成本很高。
快速的试错，疯狂的迭代上线，会变成你未来的竞争优势。
The elasticity and self-service nature of cloud-based infrastructurenaturally lends itself to this way of working. Provisioning a new application environment by making a call to a cloud service API is faster than a form-based manual process by several orders of magnitude. Deploying code to that new environment via another API call adds more speed. Adding self-service and hooks to teams’ continuous integration/build server environments adds even more speed.
基于云的基础设施的灵活性和自服务特性自然适合这种工作方式。提供一个新的应用程序环境通过调用云服务API实现比基于表单的手动流程快几个数量级。通过另一个API调用将代码部署到新环境增加了更多的速度。在团队的持续集成/构建服务器环境中添加自助服务和钩子可以提高速度。
The ability to innovate, experiment, and deliver value more quickly than our competitors.
创新、实验和交付价值的能力比我们的竞争对手更快。
Safety 安全
Cloud-nativeapplication architectures balance the need to move rapidly with theneeds of stability, availability, and durability. It’s possible and essen‐tial to have both.
原生云应用程序体系结构平衡了快速移动的需求稳定性、可用性和持久性的需求。这是有可能的两者都有可能。
云原生应用程序架构使我们能够迅速从错误中恢复过来。
Cloud native 安全特点：
1.可视性 Visibility：
Feature-rich metrics, monitoring, alerting, and datavisualization frameworks and tools are at the heart of all cloudnative application architectures.
特性丰富的度量、监视、警报和数据可视化框架和工具是所有cloudnative应用程序架构的核心。
2. Fault isolation故障隔离：
By composing systems from microservices, we can limit the scope of a failure in any one microservice to just thatmicroservice, but only if combined with fault tolerance.
通过从微服务组合系统，我们可以将任何一个微服务中的故障范围限制在那个微服务中，但只有在与容错功能相结合的情况下。
3. Fault tolerance 容错：
It’s not enough to decompose a system into independentlydeployable components; we must also prevent a failure in one ofthose components from causing a cascading failure across itspossibly many transitive dependencies.
仅仅将一个系统分解成独立的部分是不够的可部署的组件;我们还必须防止其中之一的失败这些组件会导致跨其的级联失败可能有很多传递依赖性。
采用熔断机制。
4. Automated recovery自动恢复：
healthy orunhealthy, up or down. Many times we’ll take the same courseof action every time we encounter failures like these. In the caseof the failed health check, we’ll often simply restart or redeploythe service in question. Cloud-native application architecturesdon’t wait for manual intervention in these situations.
健康检测到服务失败时，原生云应用程序架构不要等待人工干预。相反,它们采用自动检测和恢复。
The ability to move rapidly but also maintain stability, availability, and durability
高效迁移的能力，但也要保持稳定性、可用性和持久性
Scale 扩展性
Innovative companies dealt with this problem through two pioneering moves:
• Rather than continuing to buy larger servers, they horizontally scaled application instances across large numbers of cheaper commodity machines. These machines were easier to acquire(or assemble) and deploy quickly.
• Poor utilization of existing large servers was improved by virtualizing several smaller servers in the same footprint and deploying multiple isolated workloads to them.
创新公司通过两个开创性的举措来解决机器利用率低和扩展性问题:
•与其继续购买更大的服务器，不如水平购买跨大量便宜的应用程序实例进行扩展商品的机器。这些机器比较容易获得(或组装)并快速部署。
•通过在相同的内存占用中虚拟化多个较小的服务器，并将多个独立的工作负载部署到这些服务器上，改进了现有大型服务器的低利用率。
The virtualization effort was delegated to the cloud provider, and the consumer focused on horizontal scale of its applications across large numbers of cloud server instances. Recently another shift has happened with the move from virtual servers to containers as the unit of application deployment.
虚拟化工作是委托给云提供商，而使用者关注的是跨大量云服务器的应用程序的水平伸缩实例。最近，另一个转变发生了将虚拟服务器部署到容器作为应用程序部署的单元。
Unfortunately all of these benefits come with a cost. Applications must be architected differently for horizontal rather than vertical scale. The elasticity of the cloud demands ephemerality.
不幸的是，所有这些好处都是有代价的。应用程序必须按照水平而不是垂直的比例进行不同的架构设计。云的弹性要求短暂。
可扩展性要求我们不但可以快速的扩容，还要求我们可以安全的缩容。
Another hallmark of cloud-native application architectures is the externalization of state to in-memory data grids, caches, and persistent object stores, while keeping the application instance itself essentially stateless. Stateless applications can be quickly created and destroyed, as well as attached to and detached from external state managers, enhancing our ability to respond to changes in demand.
云原生应用程序架构的另一个特点是将状态外部化到内存中的数据网格、缓存和持久对象存储，同时保持应用程序实例本身基本上是无状态的。无状态应用程序可以快速创建和销毁，也可以与外部状态管理器连接和分离，从而增强我们响应需求变化的能力。
The ability to elastically respond to changes in demand.
对需求变化作出伸缩反应的能力。
Mobile Applications and Client Diversity 移动应用程序和客户端多样性
移动互联网的兴起带来了更多的流量，同时移动平台的多样性对应用架构也提出了要求。
At any time customers may want to interact with our systems from devices produced by multiple different vendors, running multiple different operating platforms, running multiple versions of the same operating platform, and from devices of different form factors (e.g., phones vs. tablets).Not only does this place various constraints on the mobile application developers, but also on the developers of backend services.
在任何时候，客户都可能希望与我们的系统进行交互，包括来自多个不同供应商生产的设备、运行多个不同操作平台的设备、运行同一操作平台的多个版本的设备，以及来自不同形式因素的设备(例如，手机和平板电脑)。这不仅给移动应用程序开发人员带来了各种限制，也给后端服务的开发人员带来了各种限制。
Mobile applications often have to interact with multiple legacy systems as well as multiple microservices in a cloud-native application architecture.
These services cannot be designed to support the unique needs of each of the diverse mobile platforms used by our customers.
Forcing the burden of integration of these diverse services on the mobile developer increases latency and network trips,leading to slow response times and high battery usage, ultimately leading to users deleting your app.
Cloud-native application architectures also support the notion of mobile-first development through design patterns such as the API Gateway, which transfers the burdenof service aggregation back to the server-side.
移动应用程序通常必须与云原生应用程序体系结构中的多个遗留系统以及多个微服务进行交互。
这些服务不能被设计成支持我们的客户所使用的不同移动平台的独特需求。
将这些不同的服务集成到移动开发人员身上的负担会增加延迟和网络访问，导致响应时间变慢和电池使用量增加，最终导致用户删除您的应用程序。
云原生应用程序架构还通过API网关等设计模式支持移动优先开发的概念，这些设计模式将服务聚合的负担转移回服务器端。
The ability for our customers to interact with us seamlessly from any location, on any device, and at any time.
客户可以在任何地点、任何设备、任何时间与我们进行无缝交互。
Defining Cloud-Native Architectures 设计云原生架构
Cloud-Native Architectures特征
Twelve-Factor Applications 十二因子
Twelve-Factor Applications describe an application archetype that optimizes for the “why” of cloud-native application architectures. They focus on speed, safety, and scale by emphasizing declarative configuration,stateless/shared-nothing processes that horizontally scale, and an overall loose coupling to the deployment environment.
十二因子描述了一个应用程序原型，该原型针对云原生应用程序架构的“为什么”进行了优化。它们通过强调声明性配置、无状态/无共享的水平扩展流程和与部署环境的整体松散耦合，关注速度、安全性和可伸缩性。
In the context of twelve-factor, application (or app) refers to a single
deployable unit. Organizations will often refer to multiple collaborating deployables as an application. In this context, however, we will refer to these multiple collaborating deployables as a distributed system.
在12因子的上下文中，application(或app)指单个因子
部署单元。组织通常将多个协作部署项称为一个应用程序。然而，在此上下文中，我们将这些多协作部署称为分布式系统
十二因子的作用：
- 符合十二因子的特性非常适合快速部署应用程序，因为应用程序很少甚至不需要关注部署它们环境的差异。
- 符合十二因子的特性很好地支持了“短暂性”的概念，即我们可以以极低的成本“抛弃”的应用程序。
- 可处置性让底层平台能够非常快速地将应用程序从故障中自动恢复
- 日志作为事件流处理，极大地支持在运行时查看应用程序的底层行为
- 环境之间强制的一致性、配置机制的一致性和支持服务管理使云平台能够对应用程序运行时结构的所有方面提供丰富的可见性和安全性。
The application environment itself is 100% disposable, as any application state, be it in-memory or persistent, is extracted to some backing service.
This allows the application to be scaled up and down in a very simple and elastic manner that is easily automated.
应用程序环境本身是100%可丢弃的，因为任何应用程序状态，无论是内存中的还是持久的，都被提取到某个支持服务中。
这允许应用程序以一种非常简单和灵活的方式伸缩，并且很容易实现自动化。
In most cases, the underlying platform simply copies the existing environment the desired number of times and starts the processes.
大多数情况下，底层平台只需要根据业务环境需要的应用个数进行复制并启动应用即可。
Scaling down is accomplished by halting the running processes and deleting the environments, with no effort expended backing up or otherwise preserving the state of those environments. In this way, the twelve-factor application patterns enable us to optimize for scale.
通过停止正在运行的进程并删除环境来实现缩容，不需要做任何备份工作或以其他方式保存这些环境的状态。通过这种方式，12个因素的应用程序模式使我们能够针对规模进行优化。
A set of patterns that optimize application design for speed, safety, and scale.
十二因子是针对速度、安全性和规模优化应用程序设计的一组模式。
Microservices 微服务
Microservices represent the decomposition of monolithic business systems into independently deployable services that do “one thing well.” That one thing usually represents a business capability, or the smallest, “atomic” unit of service that delivers business value.
微服务表示将单个业务系统分解为独立部署的服务，这些服务只做“一件事”。服务通常代表业务能力，或者最小的、交付业务价值的“原子”服务单元。
微服务架构以多种方式支持速度、安全性和可伸缩性：
- As we decouple the business domain into independently deployable bounded contexts of capabilities, we also decouple the associated change cycles. As long as the changes are restricted to a single bounded context, and the service continues to fulfill its existing contracts, those changes can be made and deployed independent of any coordination with the rest of the business. The result is enablement of more frequent and rapid deployments, allowing for a continuous flow of value.
当我们将业务域解耦为可独立部署的有界功能上下文时，我们还解耦了相关的更改周期。只要更改仅限于单个有界上下文，并且服务继续履行其现有契约，就可以独立于与业务其余部分的任何协调进行和部署这些更改。其结果是支持更频繁和快速的部署，允许持续的价值流。
- Development can be accelerated by scaling the development organization itself. It’s very difficult to build software faster by adding more people due to the overhead of communication and coordination. Fred Brooks taught us years ago that adding more people to a late software project makes it later. However, rather than placing all of the developers in a single sandbox, we can create parallel work streams by building more sandboxes through bounded contexts.
可以通过扩展开发组织本身来加速开发。由于通信和协调的开销，通过增加人员来更快地构建软件是非常困难的。Fred Brooks多年前就告诉我们，向一个延迟的软件项目中添加更多的人员会使其延迟。然而，与其将所有开发人员都放在一个团队中，我们还不如通过有界上下文构建更多的团队来创建并行开发。
- The new developers that we add to each sandbox can ramp up and become productive more rapidly due to the reduced cognitive load of learning the business domain and the existing code,and building relationships within a smaller team.
我们增加到每个团队中的新开发人员可以提高工作效率，并且由于学习业务领域和现有代码以及在较小的团队中构建关系的认知成本降低，他们的工作效率会提高得更快。
- Adoption of new technology can be accelerated.更快的使用新技术。
- Microservices offer independent, efficient scaling of services.
Monolithic architectures can scale, but require us to scale all components, not simply those that are under heavy load. Microservices can be scaled if and only if their associated load requires it.
微服务提供独立的、高效的服务扩展。
单体架构也可以扩展，但是需要扩展所有组件，而不仅仅是那些负载很重的组件。微服务可以对单个服务进行伸缩。
An architecture pattern that helps us align our units of deployment with business capabilities, allowing each capability to move independently and autonomously, and in turn faster and safer.
微服务帮助我们将部署单元与业务功能对齐的体系结构模式，允许每个功能独立自主地移动，从而更快更安全。
Self-Service Agile Infrastructure 自助服务敏捷的基础设施
Successful adopters of cloud-native applications have empowered teams with self-service platforms.
优秀的云原生架构使用者为团队提供自助服务平台。
The best of these platforms raise the primary abstraction layer for their consumers. With infrastructure as a service (IAAS) we asked the API to create virtual server instances, networks, and storage, and then applied various forms of configuration management and automation to enable our applications and supporting services to run.Platforms are now emerging that allow us to think in terms of applications and backing services.
一个优秀的自助服务平台为使用者提供接口。使用基础设施即服务(IAAS)，我们要求API创建虚拟服务器实例、网络和存储，然后应用各种形式的配置管理和自动化来支持应用程序和支持服务的运行。自助服务平台的出现允许我们从应用程序和支持服务的角度进行思考。
Application code is simply “pushed” in the form of pre-built artifacts (perhaps those produced as part of a continuous delivery pipeline) or raw source code to a Git remote. The platform then builds the application artifact, constructs an application environment, deploys the application, and starts the necessary processes. Teams do not have to think about where their code is running or how it got there, as the platform takes care of these types of concerns transparently.
应用程序代码只是以预构建构件(可能是作为连续交付管道的一部分生成的构件)或原始源代码的形式“推送”到Git远程服务器。然后，平台构建应用程序工件，构建应用程序环境，部署应用程序，并启动必要的流程。团队不必考虑他们的代码在哪里运行，或者代码是如何到达那里的，因为平台透明地处理这些类型的问题。
The same model is supported for backing services.
支持服务的模型也是相同的。
Simply ask the platform to provision one that fits your needs. Platforms now support a wide range of SQL/NoSQL data stores, message queues, search engines, caches, and other important backing services. These service instances can then be “bound” to your application, with necessary credentials automatically injected into your application’s environment for it to consume. A great deal of messy and error-prone bespoke automation is thereby eliminated.
只需要求自助服务平台提供一个满足需求的平台。平台支持常用的SQL/NoSQL数据存储、消息队列、搜索引擎、缓存和其他重要的支持服务。然后将这些服务实例“绑定”到应用程序，并将必要的认证自动注入应用程序的环境中供其使用。因此，大量混乱且容易出错的定制自动化被消除。
自助服务平台通常还提供大量额外的操作功能:
- Automated and on-demand scaling of application instances 应用程序实例的自动化和按需扩展
- Application health management 应用健康管理
- Dynamic routing and load balancing of requests to and across application instances 请求的动态路由和跨应用程序实例的负载平衡
- Aggregation of logs and metrics 日志和监控指标的聚合
Cloud platforms that enable development teams to operate at an application and service abstraction level, providing infrastructure-level speed, safety, and scale.
云平台使开发团队能够在应用程序和服务抽象级别上进行操作，提供基础设施级别的速度、安全性和可伸缩性
API-Based Collaboration 基于api的协作
The sole mode of interaction between services in a cloud-native application architecture is via published and versioned APIs.
云原生应用程序架构中服务之间交互的唯一模式是通过发布和版本化的api。
Teams are able to deploy new functionality whenever there is a need,without synchronizing with other teams, provided that they do not break any existing API contracts. The primary interaction model for the self-service infrastructure platform is also an API, just as it is with the business services. Rather than submitting tickets to provision, scale, and maintain application infrastructure, those same requests are submitted to an API that automatically services the requests.
只要不违反任何现有的API规范，团队可以在需要的时候部署新功能，而无需与其他团队同步。自助基础设施平台的主要交互模型也是一个API，就像它与业务服务的交互模型一样。这些相同的请求将提交给自动为请求提供服务的API，而不是提交票据以提供、扩展和维护应用程序基础结构。
Contract compliance can be verified on both sides of a service-toservice interaction via consumer-driven contracts. Service consumers are not allowed to gain access to private implementation details of their dependencies or directly access their dependencies’ data stores. In fact, only one service is ever allowed to gain direct access to any data store. This forced decoupling directly supports the cloud-native goal of speed.
通过消费者驱动的规范，可以在服务到服务交互的双方遵循规范。服务使用者不允许访问其依赖项的私有实现细节，也不允许直接访问其依赖项的数据存储。实际上，只允许一个服务直接访问任何数据存储。这种强制解耦直接支持云原生的速度目标。
An architecture pattern that defines service-to-service interaction as automatically verifiable contracts, enabling speed and safety through simplified integration work.
将服务到服务的交互定义为自动可验证的规范约定的体系结构模式，通过简化的集成工作支持速度和安全性。
Antifragility 抗脆弱性
By explicitly seeking out weaknesses in the application architecture, injecting failures, and forcing their remediation, the architecture naturally converges on a greater degree of safety over time.
通过明确地找出应用程序体系结构中的弱点、注入故障并强制进行修复，随着时间的推移，体系结构自然会在更大程度上集中于安全性。