上云的优势
通过云，能够按需、自助弹性提供和释放计算、网络和存储资源的计算环境。
为什么要使用云原生应用架构
速度
在传统企业中，为应用提供环境和部署环境花费的时间通常以天、周月来计算，这种速度严重限制了每个发行版可承担的风险。互联网公司经常会每天几百次的发布。为什么频繁发布如此重要？如果你每天几百次发布，意味着你可以做更多的试验-这些试验结果可能是你接下来的竞争优势
基于云基础设置的弹性和自服务的特性天生就是适应于这种工作方式。通过调用云服务API来提供新的应用程序环境比基于表单的手动过程快几个数量级。然后通过另一个API调用将代码部署到新的环境中。将自服务和HOOK添加到团队的CI/CD服务器环境中进一步加快了速度。现在我们可以回答大师Mary Poppendick提出的问题了— “如果只是改变了应用的一行代码，您的组织需要多长时间才能把应用部署到线上？” 答案是几分钟或几秒钟
安全
可视化
我们的架构必须为我们提供必要的工具，以便可以在发生故障时看到它。我们需要观察一切的能力，建立一个“哪些是正常”的概况，检查与标准情况的偏差(包括绝对值和变化率)，并确定那些组件导致了这些偏差。功能丰富的指标、监控、报警、数据可视化框架和工具是所有云原生应用程序结构体系的核心
故障隔离
为了降低故障带来的风险，我们需要限制可能受故障影响的组件和功能的范围，云原生应用程序架构通常使用微服务，通过将系统拆解为微服务，我们可以将任何一个微服务的故障范围限制在这个微服务上。
容错
仅仅将系统拆解为可独立部署的微服务还是不够的，还需要防止出现错误的组件将错误传递至其他组件从而造成级联故障。Mike Nygard在《Release It! - Pragmatic Programmers》一书中描述了一些容错模型，最受欢迎的是熔断器。熔断器工作原理类似保险丝，可以断开受保护组件与故障系统之间的回路以防止级联故障，它还可以提供一个优雅的兜底行为，比如回路断开时提供一组默认的产品推荐。
自动恢复
凭借可视化，故障隔离和容错能力，我们拥有确定故障所需的工具，从故障中恢复，并在进行错误检测和故障恢复过程中为客户提供合理的服务水平。一些故障很容易识别，他们在发生时呈现出易于检测的模式，以服务健康检查为例，结果只有两个: 健康或不健康。很多时候我们碰到这样的故障时，我们会才去相同的行动。在健康检查失败的情况下，我们只需重新启动或重新部署相关服务。云与安生应用架构在这些情况下无需手动干预，相反，他们会自动检测和恢复。换句话说，他们给电脑装上了寻呼机而不是人
弹性扩展
随着需求的增加，我们必须扩大服务能力。过去我们通常垂直扩展来处理更多的需求: 购买更强悍的服务器。但是步伐太慢，并且产生了更多的花销。另一个问题我们的判断并非每次都是正确的，例如微博明星热点爆发打破我们的可用容量规划。如果我们要常态容量满足热点时系统需求，面临的另一个问题是平日里 大多数服务器是空闲的，这在成本控制上是不允许的。
创新型的公司通过以下两个举措来解决上述问题:
- 他们用大量更便宜机器水平扩展应用实例来替代购买更大型的服务器。这样的机器更通用容易获得，并且能够快速部署
- 通过将大型服务器虚拟化成几个较小的服务器，并向其部署多个隔离的工作负载来改善现有大型服务器的资源利用率
随着阿里云等这样的公有云基础设施的出现，这两个举措融合了起来。虚拟化工作被委托给云提供商，消费者只需要关注在大量的云服务器实例上扩展它们的应用程序实例。最近作为应用程序部署的单元发生了另一个改变，从虚拟机转移到了容器。
这样带来的二级果是，降低了资本投入并加快了环境部署的速度，最大限度地提高了我们应对需求变化的速度。
不幸的是，相较于垂直扩展的应用，支持水平扩展的应用程序的架构必须不同。云的弹性要求应用程序的状态短暂性。我们不仅可以快速穿件新的应用实例；我们也必须能够给快速、安全地处置他们。这种需求是状态管理的问题：一次性与持久性如何互相影响？
云原生应用程序架构的另一个标志是将状态外化到内存数据网格，缓存和持久对象存储，同时保持应用实例本身基本上是无状态的。无状态应用程序可以快速创建和销毁，以及附加到外部状态管理器和脱离外部状态管理器，增强我们响应需求变化的能力。
移动应用和客户端多样性
云原生架构定义
12因素应用
12因素应用是一系列云与安生应用架构的模式集合。这些模式可以用来说明什么样的应用才是云原生应用。它们关注速度、安全、通过声明式配置扩展、可横向扩展的无状态/无共享进程以及部署环境的整体松耦合。
在12因素下，应用指的是独立可部署的单元。
12因素应用遵循以下模式:
代码库
每个可部署app在版本控制系统中都有一个独立的代码库，可在不同环境中部署多个实例
依赖
App应该使用适当的工具来对依赖进行显示的声明，而不该在部署环境中隐式的实现依赖
配置
配置或其他随发布环境而变动的部分应当作为操作系统级的环境变量注入
后端服务
后端服务，例如数据库、消息代理应视为附加资源，并在所有环境中同等看待
编译、发布、运行
构建一个可部署的app组件并将它与配置绑定，根据这个组件/配置的组合来启动一个或多个进程，这两个阶段是严格分离的
进程
该app执行一个或多个无状态进程(例如master/worker),它们之间不需要共享任何东西。任何需要的状态都后置于后端你服务(例如cache、对象存储等)
端口绑定
应用程序是独立的，并通过端口绑定导出服务
并发
并发通常通过水平扩展应用程序来实现
可任意处置性
通过快速启动和优雅的终止进程，可以最大程度上的实现鲁棒性。这些方面允许快速弹性缩放、部署更改和从崩溃中恢复
开发/生产平等
通过保持开发、staging和生产环境尽可能的相同来实现持续交付和部署
日志
不管理日志文件，将日志视为事件流，允许执行环境通过集中式服务手机、聚合、索引和分析时间。
管理进程
行政或管理类任务(如数据库迁移)，应该在于app长期运行的相同的环境中一次性完成
这些特性很适合快速部署应用程序，因为它们不需要对将要部署的环境做任何假定。
这些特性也很好的适用于突发需求，或者降低成本地“丢弃”应用程序。应用程序环境本身是100%一次性的。因为任何应用程序状态，无论是内存还是吃机型，都被提取到后端服务。这允许应用程序已抑郁自动化的非常简单和弹性的方式进行伸缩。大多数情况下，底层平台只需将现有环境复制到所需的数目并启动进程。锁绒是通过暂停正在运行的进程和删除环境来完成，无需设法地实现备份或以其他方式保存这些环境的状态。就这样，12因素应用模式帮助我们实现规模优化
应用程序的可处理性使得底层平台能够非常快速的 从故障事件中恢复。
此外，将日志作为事件流处理能够极大程度上的增强应用程序运行时底层行为的可见性。
强制环境等同、配置机制的一致性和后端服务管理使云平台能够给为应用程序运行时架构的各个方面提供丰富的可见性。以这种方式，12因素应用欧式能够给优化安全性。
微服务
微服务将单体业务系统分解为多个”仅做好一件事”的可独立部署的服务。这件事通常代表某项业务能力，或者最小可提供业务价值的原子服务单元。
微服务加过通过以下几种方式为速度、安全、可扩展性赋能:
当我们将业务领域分解为可独立部署的有限能力的环境的同时，也将相关的变更周期结构。只要变更限于单一有限的环境，并且服务继续履行现有合约，那么这些更改可以独立于其他业务来进行开展和部署。结果是实现了更频繁和快速的部署，从而实现了持续的价值流动
通过扩展部署组织本身可以加快部署。由于沟通和协调的开销，添加更多的人，旺旺会使然健的构建变得更加苦难。弗雷德.布鲁克斯很多年前就教导我们，在软件项目后期增加更多人力将会使软件项目更加延期。然而，我们可以通过在优先的环境中构建更多的沙箱，而不是将所有开发者都方咋子同一个沙箱
由于学习业务内容和理解现有代码的负担减少，以及建立较小团队的关系，我们添加到每个沙箱的新开发人员可以更快速的提高并更加高效
可以加快采用新技术的步伐，大型单体应