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当中，以此来传递度量数据。

查看原文：AWS云的设计模式与实践