原文：Migrating to Cloud-Native Application Architectures
本文为“节选译”，不是逐句逐段翻译，是意译和无废话译。
云架构的兴起
创新型公司遇到的问题是：
- 创新的速度
- 总是可用的服务
- Web的伸缩
- 移动为中心的用户体验
迁移到云是一个自然地选择，”云架构“是这些公司获得搅局能力的关键。
“云”指的是：任何计算环境，其中的资源（比如计算、网络、存储等）可以随时按需、自助地提供和释放。
为什么需要“云架构”？
速度
互联网公司声称每天部署几百次，为何需要频繁部署？如果你可以每天部署几百次，那么你可以几乎实时纠正错误；如果你可以实时纠正错误，那你可以进行更多的试错；如果你可以更多的试错，那你可以进行更广泛地实验。这很可能带来下一个竞争优势。
云基础设施灵活和自助的特性正好满足要求。就提供一个新的应用环境来说，调用一个云服务的API当然比传统流程快得多。再加上可以在持续集成\构建环境中加入钩子和其他联动，可以进一步加快速度。
稳定
云架构平衡了快速和稳定、可用、持久。
前面已经提到，云架构提供了迅速纠正错误的能力。注意，这里不是指防止错误。
那么我们如何即快速又稳定呢？
可视化
我们的架构必须提供工具来及时发现失败。我们需要监测整个系统：定义一个”正常状态“，及时发现偏差，并能找到导致偏差的部件。功能丰富的测量、监控、报警、数据可视化框架和工具是云架构的重要组成部分。缺陷隔离
为了控制失败带来的风险，我们需要限制被失败影响的部件或者特性。如果仅仅因为推荐引擎失效就导致所有人不能买东西，那肯定是灾难性的。单体架构的系统往往是这种情形。云架构系统经常采用”微服务“1，通过采用微服务构建系统，我们可以把失败限制在单个微服务中。当然，需要”缺陷容忍“特征的配合。缺陷容忍
将系统解构为独立部署的部件还不够。我们还必须防止一个部件中的失败在部件的依赖者中变成一个连环失败。Mike Nygrad描述了2几种缺陷容忍的模式，其中最常用的是”断流器“。软件断流器跟电路断流器非常相似：通过断开部件之间的连接来阻止连环失败的产生发展。断流器往往还能在断开的时候提供合适的默认行为。后续会进一步讨论。3- 自动恢复
如果发现某些地方有问题，那我们一般简单重启或者重新部署相关的服务。云架构一般不需要人工干预，我们采用自动发现和恢复。4
伸缩
当需求增长，我们需要伸展我们的容量来服务需求。以前我们更多地采用纵向伸展：买更强大的服务器。
创新公司使用两个创新性的办法来解决问题：
- 不买强大的服务器，而是把应用实例横向伸展到大量的便宜机器上去。这些机器容易得到而且到位很快。
- 将没有充分利用的强大服务器虚拟化成多个小服务器，在上面部署独立的负载。
当公用云出现，这两个办法得到了发展：虚拟化方面由云供应商来处理，用户专心处理横向伸缩。最近另一个趋势出现：作为应用部署的单元，虚拟服务器正在往“容器”转变。后续进一步讨论。5
这种转变进一股降低了创新门槛。部署和维护软件的成本都降低了。迎合需求改变软件的速度也非常快。
这些收益的代价就是，我们必须面向横向伸缩来架构我们的应用。云的灵活性要求“生命短促”，不仅要能快速建立应用实例，还必须能快速安全地销毁实例。这是一个“状态管理”的问题，可销毁和可持续性的关系如何？传统的方法比如“集群会话”和“共享文件系统”都不能很好地伸缩。
所以云架构的另一个特点是状态外化，将状态交给外部状态管理服务（比如数据网格、缓存、对象存储等），同时保持应用实例本身是“无状态”的。无状态的应用实例可以快速地创建和销毁，跟外部状态管理服务也可以快速连接和分开，这样就可以快速响应需求的变化。当然这也要求外部状态管理服务本身是可以伸缩的。多数的云服务商已经意识到这一点，提供了很健壮的类似服务。
移动应用和客户端多样性
应用需要”随时随地“满足需求。访问成几何级数增长。云架构予以支持。
移动平台是多样化的，移动应用经常需要跟遗留服务或者云中的微服务打交道。这些服务不可能满足各种移动平台的用户的不同需求。将整合多样性的任务交给移动开发会增加网络延迟和流量，带来响应慢和电池消耗。云架构可以将整合任务放到服务器端，比如通过模式”API网关"。后续进一步讨论。6