AWS 云的设计模式与实践

本报道根据欧特克中国研究院（ACRD）高级软件工程师丁建在 2014 年 6 月 7 日的 QClub 活动分享内容整理而成。

过去一些年来，云计算逐渐发展起来，有人开始为云计算的设计总结可复用的模式，目前形成了不同的流派。

所有流派基本都遵循六条原则：

1. 无状态，包括无状态的镜像和无状态的实例。云上的实例是虚拟化的，很容易被搞坏，所以把需要持久化的数据和实例分离，无论是故障迁移、应用扩展还是升级都很容易。
2. 松耦合，包括地缘、平台、时间、数据格式方面的解耦
3. 弹性。层、服务和组件都应该是有弹性的
4. 自动化。一方面可适应频繁的扩展，另一方面也是避免人工失误导致的问题
5. 全面的监控 / 日志。线上做 debug 很困难，需要全面依赖详细的日志
6. Design for failure。容忍错误，快速恢复，将 failure 当做普通事件处理

设计模式这一概念源自于建筑架构师Christopher Alexander，其目的是通过为特定专业领域的设计问题的解决方案形成文档，以形成某一类问题的通用解决方案。这一概念被引入计算机领域后，就有了软件设计模式这一概念，即针对软件设计的常见问题提供通用的、可复用的解决方案。

云计算设计模式，即为云计算系统设计领域归纳出一套通用的、可复用的解决方案。目前流传较为广泛的云计算设计模式有四个流派，分别来自微软高级总监Simon Guest，cloudpatterns.org 在线社区，德国斯图加特大学的Frank Leymann 教授等人所写的Cloud Computing Patterns 一书，以及AWS 的三位日本同仁Ninja of Three。

Simon Guest 是 2010 年微软关键技术人才之一，他所描述的设计模式强调五个方面：可伸缩、多租户、计算、存储、通信（网络）。其他方面大家比较熟悉，这里提到的多租户主要是指一个应用实例服务多个用户的场景，每个用户被授权对应用做一些定制，如界面或业务流程，但不能动应用代码。Salesforce 就是典型的多租户模式。

CloudPatterns.org 提出的模式是一种通过提问来进展的模式，问题涉及到基础架构、可扩展的资源池、可靠性与灾难恢复、安全、监控等多个方面。一个典型的问答流程为：

共享资源的场景

疑问：如何将物理资源的使用率最大化？

问题：将每台 IT 资源分配给一个独立用户会造成 IT 资源的浪费。

解决方案：将物理 IT 资源虚拟化，拆分成更小的 IT 资源分配给多个用户使用。

应用：在物理机上创建虚拟机实例，将每一个虚拟机实例指定给用户，而底层的物理 IT 资源是多用户共享的。

涉及的机制：审计监控、云存储设备、云资源使用监控、虚拟机系统、逻辑网络设备、资源复制、虚拟服务器

复合模式：Burst In，Burst Out 至私有云 / 公共云，弹性环境，IaaS，多租户环境，PaaS，私有云，公共云，弹性环境，SaaS

Frank Leymann 教授提出的模式跟上述模式类似，也是以问题作为起点，然后描述背景，最后提出解决方案。比如对于松耦合，提出的问题是：

如何降低分布式应用之间的依赖性以及应用的各个组件之间的依赖性？

背景描述大意是降低依赖性的好处，即可伸缩性、故障处理与升级管理的简化。解决方案是引入 broker 作为交互的中转。

Ninja of Three（简称 NoT）在 2012 年提出的 AWS 云系统设计模式列出了九大类 48 个模式，九大类分别是基本模式、静态内容、批处理、高可用、动态内容、数据上传、关系数据库、运维、网络。

AutoDesk 主要使用 AWS，因此本次分享主要会介绍 NoT 的设计模式。目前 AutoCAD 360、在线渲染、以及 Autodesk 360 都在 AWS 上运行。AutoDesk 使用 AWS 的方式是所有的开发在内部域网络中进行，源代码不出域网络；所有的 server 都是 EC2 实例，包括负载均衡、度量、授权验证都是通过 EC2 实例完成；监控采用 CloudWatch；SNS 用于做状态异常邮件的推送；SQS 在进行 Scaling 的时候启用；EBS 用来存储 Server 依赖库与中间数据，比如激光扫描文件，每一个文件都有几十个 G；数据库采用 SDB 而不是 DynamoDB，因为用户数量不多，主要是单用户资源量很大；S3 用来做各种各样的事情，比如客户端安装包、补丁、配置文件、日志信息都存在上面，因为它很便宜、带宽很稳定、对并发访问的支持很好，这个要好好利用；IAM 用于管理资源的可访问权限，以保证安全性。

VPC 目前还没有使用，因为 Autodesk 开始用 AWS 的时候还没有这个服务（2011 年之前），而从非 VPC 环境迁移到 VPC 环境需要花很多功夫。不过 VPC 的好处很多，提供了一个简化、可靠的安全性，所以终归考虑要上的。

回到 NoT 的云系统设计模式。首先是基本模式，其中覆盖了纵向扩展（Scale Up）、横向扩展（Scale Out）、计划的横向扩展、按需扩容、Snapshot 和 Stamp 这几种。对于每一种模式，NoT 列出了该模式的优点及相关注意事项。

纵向扩展，即将 small 的实例换成 large（增大）或 micro（减少），优点是容易操作，缺点是扩展上限受限于该平台最大能提供的实例资源，而且调整时间在 30 秒到数分钟不等。目前对于应用而言，Scale Up 已经不是主流的扩展模式，主要是关系数据库由于难以多机并行访问而不得不主要从该模式下手。不过有时候，我们可以通过 Scale Up 获得更好的经济性，比如 1 个 large + 1 个 x-large 的组合就要比 3 个 large 便宜，效果却差不多。

横向扩展，即增加服务节点数，好处是无需中断服务即可完成扩展，而且可以扩展的上限高于 Scale Up 方案。理想的情况下，CloudWatch 可以实现 autoscaling，但事实是启动新的实例是有延时的，这导致该模式对突发增长起不到什么作用。

相比之下，计划的横向扩展更加适合容易预测的服务。比如我们做推广活动，到了那个时间之前就可以提前把机器都起来 warm up，活动开始的时候实例就已经在线上 ready 了。

我们之所以要把负载均衡放在 EC2 上自己跑，就是因为我们使用了多种 scaling 模式：Scale Out、Scale Up 和 Scheduled Scale，用自己的负载均衡就可以支持多种 AMI 类型，还可以精准的控制扩展开始和结束的时间——因为 AWS 是按小时收费的，如果 autoscale，结果可能是用了 2 小时 1 分钟，我们不得不花 3 小时的钱，而如果采用计划模式就可以避免花这种冤枉钱。另外我们会时不时的把运行了太久的实例踢出去，因为实例运行时间长了之后稳定性会变差。

对于静态文件模式，NoT 列出了 Web Storage、Direct Hosting、Private Distribution、Cache Distribution 和 Rename Distribution 等五种模式。我们首先用到 Direct hosting，正如上面所说，我们的客户端安装文件和补丁文件、用户配置文件、新版本说明、大文件都是存储在 S3 上的。不过除此之外，我们还有一些特别的用法，就是用 S3 来生成日志数据：我们将参数放在 URL 当中，以此来传递度量数据。

由于时间所限，本次分享就到这里。谢谢大家！

相关活动

6 月 25 日成都 AWSome Day

6 月 26 日成都 亚马逊 AWS 游戏行业研讨会