附录A：术语表
略。见原文！
附录B：云计算反模式
云计算的反模式指一组应该被避免的在云上不好的设计实践。下面列出的反模式限制了应用程序很好的发挥云计算的优势：
- 复杂配置。避免不必要的复杂繁琐的配合设置。如果不需要热插拔或者动态配置文件，就依靠持久配置。如果应用程序靠持久配置就可以，那么可以在持续集成环境将配置在应用程序编译构建阶段注入。这样就避免了建立配置服务器的麻烦。不会出现所有的服务都去请求配置服务器造成配置服务器陷入拒绝服务状态。
- 复杂的依赖。避免应用程序依赖不必要的库。这种依赖会导致应用程序过大从而使得链接、加载等过程变长。为了减少依赖，使用工具生成现有的依赖关系，只包括那些在应用程序部署到云中的所必须的依赖。
- 管理共享状态。避免在启动时检索应用程序的状态，这会导致延迟从而让应用程序不能快速地处理传入的请求。
附录C：安全访问控制
访问控制技术提供了一组限制系统访问权限的配置机制。基于角色的控制（RBAC）和基于特性的控制（ABAC）属于云平台上针对组件进行访问控制的设计模式。
RBAC也称为基于角色的安全。RBAC针对角色定制不同层级的权限。每个角色赋予一个和角色安全水平相关的访问授权。反过来，角色和权限被分配给一个或者多个主题，一个主题可以是一个人或者自治的代理（例如一个自动提供创建和部署计算资源的服务）。
ABAC也称为基于特性的安全。ABAC模型相对较新，结合了主题、策略以及属性来定义一个逻辑访问控制。这个逻辑定义允许用户更容易地定义复杂的访问控制策略。相反，RBAC则基于主题的当前状态以及对应的角色，需要手动的更新策略。
附录D：自动伸缩
自动伸缩控制计算资源的动态增加或者减少以匹配当前的负载。伸缩机制依赖于对负载的监控。监控使用高低门限（例如CPU利用率或者消息队列长度）。当门限过高或者过低超过预定义的门限，则会引起告警以触发弹性伸缩。
许多的商业和开源软件提供了IaaS和PaaS层的自动弹性伸缩解决方案。每种解决方案的集成和自动化都不太一样。以下是一些自动弹性伸缩的解决方案示例：
- Amazon Auto Scaling
- Azure Management Portal Scaler
- Rackspace Auto Scale
- Scalr
- Eucalyptus Auto Scaling
- RightScale Auto Scaling
附录E：CAP理论
CAP理论由Eric Brewer提出，它说明一个分布式系统不可能同时满足以下三个特性：
- 一致性。通过任何节点的读取都看到相同的数据（针对之前完成的写入）。
- 可用性。任何时候都可以成功读写（应答都有反应）。
- 分区容错性。随意的消息丢失或者组件故障，系统都可以继续运行（容错性）。
当在云上实现一个数据存储的时候，需要在可扩展性、性能和可靠性之间权衡。Brewer描述的这三个特性只能同时满足两个：CP、AP或者CA。
附录F：数据库分片
数据库分片（Data sharding）是一种将数据库中表按照行进行水平分区的设计原则。每个分片定义为一个shard。整个数据库跨越多个分布的服务器，服务器之间没有任何共享。数据库分片可以提高数据库的性能以及提高可扩展性。数据分片也提高了吞吐量以及数据库的存储容量。
“Sharding”这个词产生于Google关于Bigtable的研究报告，“Bigtable: A Distributed Storage System for Structured Data”。
云计算应用程序因为依赖大规模的数据所以天然适合做sharding。数据分片减少了整体的客户端延迟，提高扩展性和吞吐量。
附录G：数据复制
数据复制指为数据存储创建多个冗余版本。复制的数据需要在冗余资源之间保持一致性。数据复制提高了系统的可靠性，容错性以及在数据源故障或者不可访问时的数据可用性。如果数据源故障了，云应用可以平滑的切换到备份的数据源，保证了数据的一致性和可用性。
多份冗余的数据模型可以提供不一样的持久化机制（例如：数据库，磁盘存储，或者文件存储）。
附录H：静态内容托管
Web应用程序在处理动态页面请求的时候会包含很多静态内容。客户端下载静态内容会产生较多的负载。云应用应该将静态内容和动态内容分离，将静态内容分开存储。
CDN（content delivery network，内容分发网络）为静态内容提供了地理上分布的存储服务能力。客户可以从离自己近的CDN上获取静态内容，而云中只需要为客户计算和发送动态内容。这样可以提高整系统的吞吐量。