（接前文）

云架构的定义

十二因子应用

“十二因子应用”是一些云架构模式。它们专注于速度、稳定、伸缩，主要包括强调声明性配置、无状态和无共享的横向伸缩进程、全面与部署环境解耦合等方面。当前大量的云平台都为部署十二因子应用优化。

在“十二因子应用”的说法中，“应用”指的是单个部署单元。

十二因子应用表述为：
（省略，可参见官方中文版：十二因子应用）

十二因子让应用可以快速部署，因为对环境没有多少要求。对环境没有要求也让云平台可以采用简单一致的机制来自动化地提供新的环境。这是十二因子应用在速度方面的意义。

十二因子也使得应用满足“生命短促”的要求，换句话说我们可以以很小的成本丢弃这些应用。首先应用环境本身完全是可丢弃的，同时应用的状态，不管内存中的还是持久化的，都外化到支持服务中。这就使得应用可以简单地自动化地伸缩。在大多数情况下，平台只要按想要的数量简单拷贝现有的环境然后启动进程就可以了。当需要缩减的时候，只要关闭运行中的进程，然后删除相应地环境就可以了，完全不用备份或者保护这些环境。这是十二因子应用在伸缩方面的意义。

最后，应用的可丢弃性使得平台自动错误恢复非常容易快速。同时，将日志作为事件流大大地帮助了应用状态的可视化。环境的等同、一致的配置机制以及支持服务机制则使得平台能为应用运行的各个方面提供更强大的可视化能力。这是十二因子应用在稳定方面的意义。

微服务

微服务代表了将单体架构¹业务系统解构为独立可部署的服务。每个服务代表一个业务能力，或者说是产生业务价值的最小原子服务。

• 我们将业务领域解耦为独立可部署的上下文的同时，我们就解耦了相关的变化迭代。当变化被局限在单个的上下文，这些变化可以独立于业务的其他方面。结果就是可以更频繁迅速地落实，从而持续不断地产生价值。
• 便于加速开发。包括可以投入更多地开发人员。可以将开发人员分开，让他们平行工作，不用过多的交流协作。
• 新加入的开发人员上手更快，因为他们需要学习的东西更少，需要打交道的团队也更小。
• 应用新技术可以更容易。在单体架构应用中应用新技术风险较大，一旦犯错可能拖累整个企业架构。
• 微服务带来独立有效的伸缩。巨大架构应用也可以伸缩，但要求所有部件一起伸缩，不光是哪些负载重的部件。

敏捷的自助基础设施

云架构应用的部署与维护往往由开发团队负责。支持自助的平台往往有帮助。

好的平台能为用户建立一个抽象层。在IAAS中，我们通过调用API来建立虚拟服务器、网络、存储，然后应用不同形式的配置和自动化来运行我们的应用和支持服务。平台现在鼓励我们以应用和支持服务的角度思考。

应用代码只是简单地被push到git仓库，平台就开始自动编译打包、建立应用环境、部署应用、启动必要地进程。团队不需要知道代码在哪里运行，也不用知道代码是怎么到那里去的。

支持服务也采用类似的机制。不论需要数据库、消息队列还是邮件服务器，只需要告诉平台你的需求。现在的平台大多提供SQL/NoSQL数据库、消息队列、搜索引擎、缓存等各种重要的支持服务。这些服务的实例可以被绑定到我们应用，必要地使用许可被自动注入到应用中。完全不需要繁琐和容易出错的各种定制。

这些平台还提供各种其他能力：

• 应用实例自动化和按需的伸缩。
• 应用健康管理。
• 动态路由和负载均衡。
• 日志和测量数据的汇总。

这一系列的工具保障了团队可以敏捷地开发和运营他们的服务，并且做到快速、稳定、可伸缩。

基于API的协作

云架构中，服务之间唯一的交互方式是API，公开发布和有版本的API。通常采用HTTP上的REST风格并使用JSON序列化，但其他协议和序列化方式也完全可以。

团队可以在需要的时候部署新的功能。只要他们不破坏任何既有的API合同，就不用跟其他团队协调同步。跟自助基础设施交互的主要方式也是API，不论新建、伸缩还是维护应用基础设施，都通过API的调用进行。

通过客户驱动合同，交互双方校验合同。服务的消费者不允许访问依赖的实现细节，也不能直接访问它的数据存储。事实上，只有一个服务可以访问它自己的数据存储。这种强制解耦合有利于云架构的速度。

“反脆弱”

“反脆弱”并不是指的鲁棒性或弹性。而是指系统在压力下变得更强的特性。什么系统可以做到这个？比如人的免疫系统，暴露的时候变得更强而隔离的时候变得更弱。比如，Netflix Simian Army项目有个Chaos Monkey子模块，通过向生产部件中随机注入错误来寻找架构中的弱点。通过显式地寻找弱点、注入错误、强制修复，架构自然随时间逐渐变强。

总结

以下为译者自己总结的 :-)

1. 提出创新时代的四个问题：速度、稳定、伸缩、移动
2. 云架构在这四个问题上大致有何思路。
3. 针对四个问题，云架构有五个措施：十二因子、微服务、自助基础设施、基于API协作、反脆弱

（后文继续，需要转变）