基于AWS的云服务架构最佳实践
ZZ from:
http://blog.csdn.net/wireless_com/article/details/43305701
近年来，对于打造高度可扩展的应用程序，软件架构师们挖掘了若干相关理念，并以最佳实践的方式加以实施。在今天的“信息时代”，这些理念更加适用于不断增长的数据集，不可预知的流量模式，以及快速响应时间的需求。本文将强调并重申其中的一些传统观念，并讨论他们如何在融合云计算的发展，还将讨论由于云计算的动态性而产生的一些前所未有的概念（如弹性）。
本文的目标是面向云架构师，如何将移动企业级应用从一个固定的物理环境迁移到虚拟化云环境。本文的重点是如何构建一个新的云应用或现有应用程序迁移到云环境所涉及的概念，原则和最佳实践。
背景介绍
作为云架构师，理解云计算的优势非常重要。在本节中，我们将探讨一些云计算的技术优势
和商业优势以及各种各样的AWS服务。
云计算的商业优势
在云中构建应用程序有一些明显的商业优势，这里列出机构主要特点：
前期基础设施投资几乎为零：如果你要建立一个大型的系统，它可能需要大量投资用于于机房，物理安全，硬件（机架，服务器，路由器，备用电源），硬件管理（电源管理，散热），和运维人员。由于高昂的前期成本，该项目通常甚至开始之前需要多轮的管理审批和论证。现在，采用公有云环境，几乎没有固定成本或启动成本。
基础设施即时性：在过去，如果你的应用程序开始大规模上量，而你的系统或基础设施没有在规模上跟上来，将会极大影响应用的成功。相反，如果前期投入了大量资金，而应用没有得到普及，你的系统或基础设施又将成为失败的牺牲品。通过在云环境自适应部署应用程序，就可以不必担心是否要预先采购大型的系统。这增加了灵活性，降低了风险和运营成本，因为你可以根据用于成长的规模而按需支付费用。
更有效地利用资源：系统管理员通常会担心新硬件的采购（资源耗尽的情况）和更高的基础设施利用率（资源冗余余或闲置的情况）。在云环境中，我们可以根据该应用程序请求量更高效地管理资源以及有效地按需释放资源。
根据使用计算成本：用工具式的定价，可以只对已使用的基础设施付费而不必支付那些分配了但未使用的基础设施。这增加了一个节省成本的新维度。当部署了优化补丁来更新云应用时，你可以立竿见影地看到成本节约（有时会提前出现在下个月的账单里）。例如，如果一个缓存层可以减少70％的数据请求，你马上就可以在下一个账单里看到回报。此外，如果您正在云上构建一个平台，同样可以把这个灵活可变的基于使用的成本结构传递给自己的客户。
缩短产品上市时间：并行化是加快处理速度的重要方式。如果一个计算密集型或数据密集型任务在一台机器上并行处理需要运行500小时，通过云架构，能够复制并运行500个实例来处理相同的任务，并在1小时内完成。具有弹性的基础设施提供了利用并行化的成本效益来缩短产品上市时间的能力。
云计算的技术优势：
云计算的技术优势如下：
自动化 - “脚本化的基础设施”：可以通过充分利用可编程（API驱动的）基础设施，可重用构建和部署系统。
自动扩展：无需任何人工干预，就可以根据需求对应用进行双向扩展。自动缩放提高了自动化程度从而更加高效。
主动扩展：，基于需求预期和流量模式的合理规划，可以对应用进行双向扩展让从而保持低成本运营。
更有效的开发周期：可以很容易地克隆开发和测试环境到生产系统。不同阶段的环境可以很容易地推广到生产系统。
改进的可测性：不需要进行硬件耗尽的测试。注入和自动化测试能够持续在开发过程的每一个阶段。我们可以建立一个预配置环境——“即时测试实验室”，仅用于一段时间的测试。
灾难恢复和业务连续性：云服务为维护一系列DR服务器和数据存储提高了低成本选择。使用云服务，你可以在几分钟内完成将某一地点的环境复制到其他地域的云环境中。
流量溢出到云环境：通过几次点击和有效的负载均衡策略，可以创建路由将超出的访问流量转移到云环境中的一个完整的防溢应用程序。
AWS 云服务
AWS云服务以最小的支持和管理成本，通过高度可靠和可扩展的基础设施，提供了Web应用部署的解决方案，其灵活性远高于自建的基础设施，无论这些设施是企业内部的部署环境还是在数据中心设施。
如今，AWS提供了各种基础设施服务。下图将为您介绍了AWS的术语，并帮助您了解应用程序可以用不同的AWS服务以及不同的服务间是如何交互。
AmazonEC2是一个Web服务，提供容量可调整的云计算能力。你可以将操作系统，应用软件和相关配置捆绑在一起，然后设置成亚马逊机器映像（AMI）。然后，您可以使用这些AMI生成多个虚拟化实例，以及使用简单的Web服务调用，快速双向扩展容量，也可以根据容量需求的变化而去除他们。您可以购买点播实例以小时付费或按次付款并保留实例，在使用率较低时，可以申办未使用的容量，并进一步降低成本。实例可以在一个或多个地域运行。每个地域都有多个可用区。可用区是被设计成与其他可用区的故障隔离，并提供了与同一地域其他可用区不同廉价低延迟的连接网络。
弹性IP地址允许您通过编程的方式将一个静态的IP地址分配给一个实例。您可以使用Amazon CloudWatch监控一个Amazon EC2实例的可见性资源利用率，运行性能和全部要求模（包括指标，如CPU利用率，磁盘读取和写入，以及网络流量）。根据CloudWatch收集一定的条件指标，您可以创建Auto-scaling Group来使用自扩展特性来实现自动缩放。您也可以通过使用弹性负载均衡ELB服务创建一个弹性负载平衡器分发请求流量。弹性块存储（EBS）将持久性存储通过网络方式关联到Amazon EC2实例中。对于EBS的一致性的卷快照，可以创建并存储在亚马逊简单存储服务Amazon S3中。
Amazon S3是高度耐用和分布式数据存储。用一个简单的Web服务接口，在任何时间，在网络上的任何地方都可以使用标准的HTTP命令存储和检索大量在数据箱中的对象。作为Web服务的传输内容，对象的副本（静态或流媒体内容）都可以通过创建并使用Amazon CloudFront的缓存服务来分布在世界各地的14个地域-。亚马逊SimpleDB也是一个Web服务，它提供了一个数据库的核心功能，无需复杂操作，就可以完成实时查询和结构化数据的简单查询。域是由键值对所描述的条目集合，我们可以组织数据集到域，并对该特定域中的数据进行查询（NoSql服务）。
Amazon RDS 提供了在云环境中建立，操作和扩展关系型数据库的简单方法。你可以发布一个DB Instance 就可以访问 MySQL数据库的全部特性，而不必担心通用的数据库管理任务例如 备份，补丁管理等。
Amazon SQS 是一个高可靠，高扩展的分布式消息队列，通过消息队列可以完成不同主机以及应用组件间的消息传递。
Amazon SNS 使用发布-订阅协议并创建相关主题，提供了从云端通知应用或用户的简单方法。
Amazon EMR 提供了以EC2 和S3为基础设施的 Hadoop 框架，可以创建自定义的作业流. 作业流就是 MapReduce 过程序列.
Amazon VPC allows能够在AWS内部将企业网扩展为私有云。Amazon VPC 使用IPSec 管道模式在你的数据中心网关和AWS网关之间建立一个安全连接。
Amazon Route53 是一个高可扩展的 DNS 服务，你可以在每一个域创建一个HostedZone来管理所有的DNS记录。
AWS IAM 在AWS账户内部通过唯一的安全准则可以创建多个用户，并具有不同地权限。 IAM与AWS 云服务以原生方式集成在一起. 在使用IAM时，不需要退出应用和先关工具，就可以保持AWS的服务持续运行。
AWS 通过支付的基础设施提供了各种各样的支付方式和计费服务。
所有AWS 云服务都提供了按使用计费的方式，而不需要长期承诺或合同。 例如, 按小时支付 Amazon EC2 实例的使用，按照存储量和传输量对Amazon S3付费. 更多信息可以关注AWS的网站。
注意，使用AWS云计算并不需要牺牲灵活性和也不改变你的使用习惯：
l 你可以随意使用你选择的编程模型，语言，或者操作系统(Windows, OpenSolaris or any flavor of Linux)
l 你可以随意使用任何一个AWS服务或者任何服务的组合，只要最大限度地满足你的需求就可以了。
l 由于 AWS提供了可以调整的资源 (存储, 带宽和技术能力),你可以自由地增减资源并安装真正的使用付费。
l 可以继续使用原来的系统管理工具，将你的数据中心扩展到云端。
云计算中的基本理念
云计算强化了构建高度可扩展互联网架构的一些基本理念，同时引入了一些新的概念完全该变量应用的构建和部署方式。因此，当你在从概念设计到实施的过程中，你可能会感到“什么都变了，却又没什么不同”。云计算改变了处理方式，模式，实践方式，甚至哲学理念，同时强化了传统的SOA原则，这些原则比以前更加重要。在本节，你将看到云计算中的新概念以及对SOA原理的重申。
构建传统应用时，权衡体系结构和经济性之间的关系需要大量的开发经验. 云计算带来了新的理念，现探讨如下:
构建可扩展架构：
为了获得一个可扩展基础设施的好处，构建一个可扩展的架构非常关键。
云计算在设计上提供了概念上的无限可扩展。但是，如果你的架构部署可扩展的，也无法使用到云计算的可扩展性带来的优势。
你必须确定架构中的瓶颈和单点组件，确定架构中哪些是不能按需部署的部分，然后重构应用来调整为可扩展的架构，从获得云计算的益处。
一个真正可扩展应用的特点:
增加资源就可以按比例增加性能
一个可扩展的服务可以处理异构的兼容性
一个可扩展的服务可以有效的运营
一个可扩展的服务是弹性的
一个可扩展的服务能够在业务增长时成本更低(单位成本随着单元的增加而递减)
这些特性应该是应用中的固有部分，在架构设计时要铭记于心，基础设施和应用架构要协同工作完成可扩展性。
对弹性的理解
下图解释了一个云应用架构中按需扩展的不同方法。
放大扩展的途径: 使用可扩展的应用架构不用担心为了满足需求而大规模投资以及购买更强大的服务器（垂直扩展）这种方法通常工作到一个点，但是在新设备部署前就可以降低成本 (见图中的“Huge capital expenditure” )或者满足业务增长的需要 (见图中“You just lostyour customers”).
传统向外扩展的途径： 创建水平扩展的架构和投资小块的基础设施。大多数业务或大规模web应用都采用如下的模式，分布式应用组件，联合数据集和SOA的设计。 这种方法通常比放大扩展更有效。然而，这需要准确的业务预期才能实现满足需求的部署。经常会导致容量过剩(“烧钱”) 和持续人工监测 (“浪费人力成本”).此外，如果遇到业务的爆发式增长，系统将无法正常工作。
注意：这两种方法具有初始启动成本，而且在本质上是被动的。
传统结构一般要预测几年内系统所需资源的数量，如果预计不足，应用将没有马力处理预期外的流量，从而导致客户的不满。如果预计过高，又造成资源浪费。
按需部署和弹性是云计算的天然方式（自动弹性），使基础设施与真实需求尽量匹配，因而可以提供资源利用率及压缩成本。
弹性是云计算的一个基础属性。弹性通过微量的调整即可实现计算资源的可扩展性增减。弹性给云计算带来绝对的优势，这非常重要。 作为云计算架构，要牢记这一概念，并应用到系统架构中，才能获得云计算的最大利益。
传统上，以一个固定的预部署的刚性基础设施来构建应用，公司不需要每天都要进行安装部署。结果使大多数软件架构不适用快速部署和硬件缩减。既然获取新资源需要较高的实施时间和追加投资，软件架构也不会在硬件利用率的优化是投入时间和资源，应用在低使用率的硬件上运行时可以接受的。在分钟级获得新资源是不可能的，所以一个架构的弹性也是被忽略的。
在云计算中，这是观念的改变。云计算以流水线处理的方式获取所需资源，不再需要预先采购设备和保留闲置的硬件。云架构可以在几分钟内完成资源采购或者自动化采购，从而拥有了大量扩展和响应时间的优势，同样，也可以释放掉那些闲置的或低利用率的资源。如果在你的系统架构中不能拥抱这样的变化，就不能分享云计算的全部好处。
作为一个云应用架构师，你需要创造性地思考在应用系统中实现弹性。 例如,基础设施被用来白天运行，晚上构建，在凌晨2点执行回归和单元测试两个小时 ，其他时间都是空闲的。现在，基础设施有了弹性, 可以只支付晚上两个小时的计算时间。类似的，内部故障经常出现在容量的峰值(例如5 服务器 24x7x365)，现在可以按照流量模式来按需配置(如5 服务器从9AM 到 5 PM 运行，而只用2个服务器在5 PM 到 9 AM运行)。
云架构的智能弹性设计使基础设施能够按需运行，这本身就是一门艺术。弹性应该是一种架构设计的需求或者系统属性。你可能会问：系统架构中的哪些组件或者层次可以成为弹性的？用什么技术可以使这些组件变得有弹性？ 实现弹性对系统架构的整体有何影响？
在下一章，将会展示在应用中实现弹性的相关技术。有效地利用云计算的弹性优势，是架构中非常重要的观念。
无惧约束
当你决定架构应用向云计算迁移的时候，或者将自己的系统规范映射成云服务时，要注意到云计算中没有原来所需的准确资源定义。例如，云计算中一个服务器没有RAM的数量，或者一个数据库实例需要更多的IOPS。
要理解云计算提供的是抽象资源，这才使按需实施模式变得强大。当使用云资源时不用担心不够用，你的硬件没有真正确切地复制在云环境中，这非常重要，你能够获得任何你所需要的资源。
例如，云计算没有告诉你一个服务器中确切的内存数量，使用了向memcached的分布式缓存，或者将数据在多个服务器上做了分区。如果你的数据库需要更多的IOPS，且不能映射到云中的服务，可以根据使用用例和数据类型选择其他的云计算方案。如果是一个重度读应用，你可以将这些读请求分布到一组同步的从服务中。另一种方法是，采用分片算法来路由数据，或者采用各种数据库集群解决方案。
回顾一下, 当你将灵活性和按需实施能力结合在一起的时候，就已经意识到资源约束的解除显然提高了可扩展性，改善了系统的整体性能。
虚拟化管理
云计算的到来将系统管理员的角色变成了“虚拟系统管理员”。这意味着这些管理员们更关注应用本身那些有趣的事情，以及从整体上决定哪些对业务是最佳的。系统管理员不再需要部署服务器，安装软件以及连接网络设备，所有这繁复的工作都可以通过几下点击和几个命令行调用就完成了。基础设施的可编程化使云计算自动化程度更高。系统管理员需要升级自己的技术结构来学习如何使用脚本管理抽象的云资源。
类似地，DBA的角色也变成了“虚拟DBA”，通过基于web的终端管理资源，执行脚本在容量用光时增加新的数据库容量，以及每天的自动化处理。
虚拟DBA必须学习新的部署方法（通过虚拟机镜像），拥抱新的模型 (并行查询，远程灾备和异步复制),反思数据的架构方法 (分片,水平分区,联盟) 以及针对不同数据集采用不同的云存储服务。
在传统企业中，应用开发者没有和网络管理员在一起紧密的工作，网络管理员也没有关于应用的胶水。结果是，网络层和应用架构层优化经常被忽略。 通过云计算，二者被凝聚在一起，在将来做应用架构的时候，公司将形成更多的跨团队融合。
云架构最佳实践
在本节,我们将学习到在云端构建应用的最佳实践。
容错性设计和零故障
大拇指原则：在云端进行架构设计时要保持悲观，假设所有事物都会发生故障。换句话来说，要面向故障的自动化恢复来设计，实施和部署。
特别地，假设硬件会发生故障，断电了，这些灾难使应用不能工作了，某些天的每秒请求超出的限制，不得不停止服务， 软件也发生了故障等。作为一个悲观主义者，在设计时就要思考恢复策略，将使整个系统变得更好。
如果意识到了故障切换并且作为架构的一部分，通过可扩展的基础设施来构建故障处理的机制，你将不再建一个容错的架构，而是由云环境完成了。
你会问：系统中一个节点故障时发生了什么？如何识别故障？如何更换这个节点？我要规划怎样的场景？什么是我的单点故障？如果在一组服务器之前使用了负载均衡，那么均衡器挂了怎么办？ 如果架构中采用了主从结构，主节点挂了怎么办？如何故障切换？一个与主服务器同步的新从设备如何被实例化？
和硬件故障设计一样，必须进行软件的故障设计。
你会问:如果一个依赖服务的接口变了，我的应用怎么办？如果下行服务超时或者返回异常怎么办？如果缓存的键值数量超出了一个实例的内存限制怎么办？
建立处理故障的机制. 例如, 下面的策略可以为故障处理提供帮助:
1. 数据的连贯备份和恢复以及自动执行
2. 构建重启的进程
3. 从队列中重载消息来完成系统状态的重新同步
4. 保留已经配置和优化好的虚拟镜像来支持步骤2和3
5. 避免内存中的会话或者状态化的上下文，把它们移到数据存储中。
好的云架构可以减少重新加载或者重新启动。例如使用 Amazon SQS 和Amazon SimpleDB的组合, 这个控制器的架构对这些故障非常有弹性。对实例而言，如果控制器上的实例线程假死，它可以恢复到以前的状态就像什么都没发生过似的。这是通过创建一个预先配置好的AMI完成的，它重启动的时候从Amazon SQS队列中读取所有消息，并从SimpleDB读取它们的所有状态。
针对底层硬件故障的可能情况进行设计，可以做到有备无患。
这一设计原则能够实现运营友好的应用[11]。如果你通过主动测量和动态负载均衡来扩展这一原理，由于云环境的多租户特性，你可以实现各种各样的网络和硬盘性能。
AWS提供了特殊的策略来实施这一最佳实践:
1.使用弹性IP来优雅地实现故障切换: 弹性IP是将一个静态的IP动态地重新映射。你可以通过重新映射将故障切换到另外的一组服务器上，流量也将路由到新的服务器。这对应硬件故障或者应用升级都非常有效。
2.使用多可用区: 可用区是概念上的逻辑数据中心。在多可用区上部署你的系统架构，可以保证高可用性。使用 Amazon RDS Multi-AZ [21] 的部署功能可以在多可用区上自动复制数据库。
3.维护一个AMI能够在不同的可用区上轻松地克隆和恢复环境;在可用区间维护多个从数据库从而实现热备份。
4. 使用 Amazon CloudWatch(或各种实时的开源监测工具) 以可视化的方式对硬件故障或者性能下降采用合适的措施。建立一个自动可扩展组以便用新的实例替换那些不健康的 Amazon EC2实例。
5. 使用Amazon EBS，建立 cron jobs来实现将增量快照自动地上传到AmazonS3，使数据与实例独立开来。
6. 使用Amazon RDS ，设置为备份的保留期限，以便它可以执行自动备份。
组件解耦合
云计算强化了SOA的设计原理，系统组件的耦合越松，扩展起来越方便越好。
构建组件的关键是减少之间的依赖，如果一个组件死掉了，没有响应，或者响应时间过长，系统中的其他组件应该可以继续正常工作。 显然，松耦合使组件间以及层次间相互独立，这样每个组件可以将其他组件作为黑盒子完成异步交互。例如
一个web应用架构的情况,将应用服务器，web服务器和数据分离开来，该应用程序服务器不知道你的Web服务器，反之亦然，这些层之间的解耦合，不存在代码依赖或功能交叉。在批处理的系统架构中，可以创建相互独立的异步组件。
你可能会问:哪些业务组件或特性可以从当前的单点应用中隔离出来，可以独立运行么？那么，在不破坏当前系统的前提下能够为这个组件增加更多的实例么，以及同时服务更多的用户? 付出多大的努力才能封装这些组件并使其异步通信呢？
组件解耦合，异步系统和水平扩展在云计算中是非常重要的。你不仅可以为同一组件增加多个实例实现扩展，而且允许你设计创新的混合模式，其中一些成分继续私有部署运行，而其他组件可以利用云计算可扩展的优势，使用云计算的计算能力和带宽。这样，以最小的代价，你可以通过实施智能负载均衡策略将在“溢出”多余的流量移动到云上。
建立松耦合系统的另一方式是使用消息队列。如果两个组件间通过队列或者缓冲区连接的话，可以支持高并发，高可用和负载削峰。其结果是，即使元件部分功能暂时不可用，整个系统仍然继续执行。如果一个组件死亡或暂时不可用时，系统将消息缓存起来，在组件恢复时再处理他们。
在GrepTheWeb的架构这篇文章中可以看到消息队列的充分使用[6]。在 GrepTheWeb中,
如果忽然间有大量的请求到达服务器（互联网引发的过载情况)或者正则表达式的处理花费了大量的时间（一个组件响应迟钝）， Amazon SQS 将在一段时间内缓存这些请求，使这些延迟不会影响其他组件。
AWS提供了特殊的策略来实施这一最佳实践:
1. 使用Amazon SQS来隔离组件[18]
2. 使用Amazon SQS作为组件间的缓冲区 [18]
3. 设计的每个组件暴露其服务接口，负责其自己的可扩展性，并与其他组件异步交互
4. 绑定组件的逻辑结构并制成AMI，以便可以时常部署
5. 使应用尽可能无状态化，将会话的状态存储在组件的外部（例如SimpleDB）
实现弹性
云计算为你的应用带来了弹性的概念。有三种方法实现弹性：:
1. 周期性主动扩展: 固定时间将的周期性扩展(按天, 周, 月, 季度)
2. 基于事件的主动扩展:根据安排好的商务活动（新品发布，市场宣传活动）所期望的请求流量爆发而做的扩展
3. 按需自动扩展 ：通过监控服务的使用，系统可以根据相关指标触发适当的动作来扩容或减负 (例如一个实例的服务器或者网络IO的使用情况)
为了实现弹性,首先要做到自动化部署，流水线配置和构建流程，这样可以保证在没有人工参与的情况下自动地实现系统的可扩展。这能导致即时节约成本，保证资源与需求高度匹配，而不需为了潜在需求运行的服务器在低利用率运行。
基础设施自动化
使用云环境最重要的优势之一是能够使用API完成自动化部署。在迁移的早期花时间考虑自动化部署是非常值得的。创建一个自动化和可重复的部署流程能够减少错误，有效地扩展和升级。
自动化部署:
建一个库：频繁使用的小脚本(用于安装和配置)
使用AMI内绑定的代理来管理配置和部署流程
实例自举
实例自举
让你的实例在启动的时候问你个问题 “我是谁，我的角色是什么?” 每个实例都应该在环境中扮演一个角色(“DB server”, “app server”, “slave server” 等) 。 这个角色可能是传递给启动过程的参数，用来指示AMI实例化社的步骤。再启动时,基于角色和所关联集群的功能，实例可以获取所需的资源 (代码, 脚本, 配置)。
实例自举的好处:
1. 少量操作即可完成环境重建(开发, 测试, 生成)
2. 实现对抽象云资源的更多控制
3. 减少人为部署的错误
4. 创建了一个自愈环境对硬件故障而言更有弹性
AWS 提供了基础设施自动化的相关策略：
1. 使用Amazon EC2中的Auto-scalingfeature 为不同的集群定义Auto-scaling groups
2. 使用Amazon CloudWatch 来监控系统指标(CPU, Memory, Disk I/O, Network I/O) ，然后采取合适的操作（使用Auto-scalingservice动态启用新的AMI）或者发通知 。
3. 动态存储和恢复配置信息: 利用Amazon SimpleDB 在实例启动时获得配置数据。SimpleDB也可以用来存储实例的信息如 IP 地址,机器名和角色.
4. 设计一个构建流程将最新版本存入AmazonS3; 从而在系统启动的时候加载最新的版本
5. 构建资源管理工具(自动化脚本,配置好的镜像 )或者使用开源的配置管理工具如 Chef18, Puppet19, CFEngine 20或Genome21.
6. 将裁减的操作系统和软件依赖绑定并放入AMI中，这样便于管理和维护。在启动时传递配置文件和参数，启动后获得用户和实例的相关数据.
7. 将一个实例管理一个或多个EBS卷可以减少绑定和启动的时间。创建通用卷快照，可以在合适的时候共享这些快照。
8. 假定应用组件处于不良状态。例如，动态绑定一个新节点的IP到集群中，自动故障切换以及故障发生时启动一个新的克隆。
并行化思考
云计算能轻松实现并行化。无论是从云中请求数据，将数据存储到云中，在云中处理数据（或执行的作业），作为一个云服务架构师，在架构设计时一定要将并行化秉记于心。
由于云计算可以非常容易地创建可重复流程，所以不但要尽可能地实现并行化，而且使之自动化执行。
当数据访问的时候,云环境可以处理大量的并行操作。为了得到最大的性能和吞吐量， 需要充分利用并行化请求。多线程并发处理要比顺序化请求处理快得多。因此，尽可能地使用非共享原则来充分利用多线程来设计线程安全的云应用。
在云端处理请求的时候，并行处理就越发重要了。在web应用中，一个通常的最佳实践是使用负载均衡将请求分布到多个异步的web服务器中。在批处理应用中，可以使用多个从服务节点来处理并行化任务。
当并行化和弹性相结合体现了云计算之美。云应用使用少量的API在几分钟内就可完成计算集群的部署，并行地处理任务、保存结果和终止实例。
AWS 面向并行化的相关策略:
1.对 Amazon S3 多线程化
2. 对 SimpleDB 的GET 和 BATCHPUT 请求多线程化 [3][4] [5]
3. 对每日的批处理任务（索引，日志分析等），使用AmazonEMR 创建作业任务，能够并行处理并节约时间。.
4. 使用弹性负载。
动静分离：动态数据靠近计算，静态数据贴近用户
一般来说，让数据尽可能靠近你的计算或处理单元，以减少延迟是一个很好的做法。在云计算中，由于必须经常处理互联网延迟，这一实践更加重要。此外，在云环境中，我们必须要为数据传输的千兆字节带宽付费，成本开销很大。
如果大量数据需要在云计算之外处理，先传输再计算可能比较便宜。例如，对于一个数据仓库的应用而言，最好是数据集先移到云，然后执行并行数据查询。对于一个从关系型数据库存取数据的web应用，最好也是将数据库和应用服务器一并移到云环境中。如果数据是在云端产生的，则消耗该数据的应用程序也应该部署在云中，以便它们可以享受在云环境内部的免费数据传输和低时延。例如，在一个电商的应用记录点击数据并生成日志的情况，最好在云中运行日志分析和报表引擎。
相反地，如果数据是静态的，不经常改变（例如，图像，视频，音频，PDF文件，JS，CSS文件），最好是利用CDN服务的优点，内容分发服务提供更快的对象访问，使得静态数据被高速缓存在靠近最终用户（请求者）的网络位置，从而降低了访问时延。
AWS针对这一最佳实践的相关策略：
1. 使用 Import/Export 服务27.将数据盘迁移到云环境中，用 sneakernet28 tha比互联网上
传更快捷而且便宜。.
2. 使用相同的可用区来发布集群
3. 创建一个Amazon S3数据发布版本， 充分利用 AmazonCloudFront 在全球14个地区的
CDN服务
关于安全的最佳实践
在多租户环境中，云计算架构师经常考虑的就是安全性。安全应在云应用体系结构的每
一层中都有体现实现。物理安全性通常是由服务提供商来处理（安全白皮书[7]），这是使用云的一个额外好处。网络和应用级的安全是你的责任，应该适用业务实施最佳实践。在本节中，您将了解如何保护云应用程序在AWS环境中的那些特定的工具，功能和准则。建议利用这些工具，实现基本安全功能，然后使用适当的标准方法，或其他认为合适的安全性最佳实践。
保护在途数据
如果需要在服务器和浏览器中交互敏感或机密信息，最好在服务器实例中配置SSL，需要使用像VeriSign29 或Entrust30这样的授权证书。 证书中的公钥来验证服务器和浏览器请求，并作为双向会话数据加密的基础。
通过少量的命令行调用就可以创建虚拟私有云 (using Amazon VPC)。 这样可以在云环境内实现资源的逻辑隔离，然后使用业界标准的IPSec VPN 连接来直接访问资源，也可以在Amazon EC2上建立一个OpenVPN服务器，然后在所有用户PC上安装OpenVPN的客户端。
保护数据的存储
如果关心云环境中存储的敏感和机密数据，需要在在上传文件是进行加密。例如，使用任何开源工具加密数据或者使用商用的PGP 工具在存储到Amazon S3前进行加密，在下载后进行解密。在构建HIPAA兼容的应用程序时需要保存PHI,这通常是一个好的实现。
在AmazonEC2上,文件加密依赖于操作系统 。运行在Windows 上的Amazon EC2 实例可以使用内置 EFS 特性 [16]. 该特性可以对文件或目录自动加解密，对用户而言是透明的[19]。此外，和名称不符的是， EFS 不能加密整个文件系统而只加密单个文件。如果对这个文件系统加密，需要考虑开源的TrueCrypt33 产品; 它与NTFS格式 EBS卷集成的很好。运行在Linux上的Amazon EC2实例可以使用各种方式加密文件系统来挂载EBS卷 (EncFS34,Loop-AES35, dm-crypt36,TrueCrypt37). 类似的, 运行在OpenSolaris 上的Amazon EC2 实例可以试试 ZFS38 加密支持 [20].无论选择的是什么，在Amazon EC2 上加密的文件和卷都可以保护文件和日志数据，从而只有用户和服务器上进程可以看到明文，其他都只能看到密文。
不论你选择了什么样的技术或操作系统，加密数据都意味着一种挑战: 管理用来加密的密钥。. 如果密钥丢失，将永远失去你的数据，如果密钥泄露，数据同样存在风险. 因此，要认真研究所选产品的密钥管理能力，最小化地减少密钥丢失的风险。
除了保护数据不被窃听，也要考虑如何保护其免受灾难。对EBS卷定期快照，以确保它是高度耐用和可用性。快照是渐进性的，存储在Amazon S3（独立的地理位置）上，并可以几次点击或命令行调用完成恢复。
保护AWS 凭据
AWS 提供了两种类型的安全凭据： AWS 访问密钥和 X.509 证书。AWS访问密钥有两部分: 密钥 ID和安全密钥 。当使用 REST 或 Query API时,必须使用安全密钥在请求验证中计算签名。为了防止在传输中被篡改，所有的请求应通过HTTPS发送。
如果AMI需要与其他的AWS 云服务通信 (例如轮询 Amazon SQS 或者从 Amazon S3中读取数据), 一个典型错误是将AWS 凭据嵌入到AMI中，正确方法应该是在发送前传递参数[17].
如果安全密钥被破坏,应该通过新的密钥ID获得新的安全密钥。作为一个好的方式，建议在应用程序架构中采用密钥轮换机制，让可以定期使用它，或者偶尔（当心怀不满的雇员离开公司），以确保受损密钥不能持续工作。
另一种方式是采用 X.509 证书来研制特定的AWS服务。证书文件在base64-encoded DER证书主体中包含了公钥，另一个文件包含了base64-encodedPKCS#8 私钥。在aws.amazon.com 和 AWS Management Console 中，AWS支持多因素验证。
在 IAM 中管理用户权限
AWS IAM42 能够AWS账号内管理多个用户的权限。 一个用户(在AWS账号内)是访问AWS云服务的唯一安全身份。IAM 消除了密码和访问密钥的共享，可以方便的开通或禁止用户访问。
IAM是实现安全性的一个最佳实践, 例如通过授权实现最低访问权限，只有通过授权的用户才能访问AWS服务和资源。IAM 是默认安全的，新用户没有被准确授权的话无法访问AWS服务。
IAM 原生集成了大多数的AWS 云服务。IAM的API不会变化，应用和工具在权限变化时可以进行运行。应用只需要在开始时为新用户生成访问密钥。当与其他AWS服务交互的时候，应该最小化地使用 AWS的账号凭据，这样才能分享IAM带来的好处。
应用安全
安全组是网络流量入口规则的集合，需要指定TCP 和 UDP 端口, ICMP 类型和代码,以及源地址等,每个Amazon EC2实例都被一个或多个安全组所保护。安全组为运行实例提供基本的类似防火墙保护。例如，隶属应用的实例有如下的安全组设置:
限制呼入流量的另一种方式是配置实例的软件防火墙。Windows 实例有内置的防火墙， Linux 实例使用 netfilter45 和 iptables.
随着时间的推移，如果在软件中发现错误，需要打补丁来修复，应该保障下面的措施是应用的安全最大化：
定期下载补丁从供应商的网站并更新到AMI 中；
从重新部署新AMI实例和测试应用程序，以确保补丁不破坏任何东西，同时确保最新的AMI部署到所有实例；
开发测试脚本定期地进行自动化安全检查；
确保第三方软件配置为最安全设置
除非绝对必要，否则永远不要以root或管理员身份运行的进程
所有在云时代之前的标准安全实践依然适用，例如采用良好的编码习惯，隔离敏感数据等。
现在回想起来，云技术简化了物理安全的复杂性，通过工具控制和相关特性可以确保应用程序安全。
未来的研究方向
应用不用关心物理硬件的时代并不遥远。作为一个架构师，只需要管理抽象的计算，存储和网络资源，而不是物理服务器。即使底层物理硬件发生故障或被拆除或更换，应用程序都将继续运行。应用程序将适应不断变化的需求模式且瞬间自动调配资源，从而在所有时间达到最高的利用率水平。扩展性，安全性，高可用性，容错性，可测性和弹性都是应用架构的配置属性，而且在平台构建时自动内置了。
但是，我们还没有到那样的程度。现在，可以通过文中的最佳实践来建立在云计算中应用来具备这些特质。基于云计算架构的最佳实践还在继续发展，并作为研究人员，我们应该不仅着眼于增强云计算的知识而且要关注工具构建，技术和流程，这将更容易让开发人员和架构师把应用程序迁移到云计算环境中。
结论
本文为云计算架构师提供了设计高效云应用程序的规范性指导。
通过专注于概念和最佳实践，例如设计失败，应用程序组件解耦合，理解和实现弹性，弹性与并行结合，并在应用程序架构的各个层面整合安全，云计算架构师可以了解到构建高可扩展的云应用程序时必要的设计要素。
AWS云服务提供了高度可靠的按需付费的基础设施。在AWS具体策略中突出可如何使用这些服务来设计云应用。作为一名研究者，最好充分发挥这些商业服务的作用，站在巨人的肩膀上，进一步增强基于云计算的创造。
|
参考资料 1. Amazon S3 Team, Best Practices for using Amazon S3, http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1904, 2008-11-26 2. Amazon S3 Team, Amazon S3 Error Best Practices, http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ErrorBestPractices.html, 2006-03-01 3. Amazon SimpleDB Team, Query 201: Tips and Tricks for Amazon SimpleDB Query,http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1232&categoryID=176, 2008-02-07 4. Amazon SimpleDB Team, Building for Performance and Reliability with Amazon SimpleDB,http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1394&categoryID=176, 2008-04-11 5. Amazon SimpleDB Team, Query 101: Building Amazon SimpleDB Queries,http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1231&categoryID=176, 2008-02-07 6. J. Varia, Cloud Architectures, http://jineshvaria.s3.amazonaws.com/public/cloudarchitectures-varia.pdf, 2007-07-01 7. Amazon Security Team, Overview of Security Processes,http://awsmedia.s3.amazonaws.com/pdf/AWS_Security_Whitepaper.pdf, 2009-06-01 8. Amazon Web Services Team, Creating HIPAA-Compliant Medical Data Applications With AWS,http://awsmedia.s3.amazonaws.com/AWS_HIPAA_Whitepaper_Final.pdf, 2009-04-01 9. D. Obasanjo, Building Scalable Databases: Pros and Cons of Various Database Sharding Schemes, http://www.25hoursaday.com/weblog/2009/01/16/BuildingScalableDatabasesProsAndConsOfVariousDatabaseShardingSchemes.aspx, 2009-01-16 10. D. Pritchett, Shard Lessons, http://www.addsimplicity.com/adding_simplicity_an_engi/2008/08/shard-lessons.html, 2008-08-24 11. J. Hamilton, On Designing and Deploying Internet-Scale Services, 2007, 21st Large Installation System Administration conference (LISA ‘O7), http://mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf 12. J. Dean and S. Ghemawat, MapReduce: Simplified data processing on large clusters2004-12-01, In Proc. of the 6th OSDI, http://labs.google.com/papers/mapreduce-osdi04.pdf 13. T. Schlossnagle, Scalable Internet Architectures, Sams Publishing , 2006-07-31, 14. M. Lurie, The Federation: Database Interoperability, http://www.ibm.com/developerworks/data/library/techarticle/0304lurie/0304lurie.html, 2003-04-23 15. E. Hammond, Escaping Restrictive/Untrusted Networks with OpenVPN on EC2, http://alestic.com/2009/05/openvpn-ec2, 2009-05-02 16. R. Bragg, The Encrypting File System, http://technet.microsoft.com/en-us/library/cc700811.aspx, 2009 17. S. Swidler, How to keep your AWS credentials on an EC2 instance securely, http://clouddevelopertips.blogspot.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html, 2009-08-31 18. Amazon SQS Team, Building Scalable, Reliable Amazon EC2 Applications with Amazon SQS, http://sqs-public-images.s3.amazonaws.com/Building_Scalabale_EC2_applications_with_SQS2.pdf, 2008 19. Microsoft Support Team, Best Practices For Encrypting File System (Windows), http://support.microsoft.com/kb/223316, 2009 20. Solaris Security Team, ZFS Encryption Project (OpenSolaris), http://www.opensolaris.org/os/project/zfs-crypto/, 2009-05-01
21. Amazon RDS Team, Amazon RDS Multi-AZ Deployments,http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/Concepts.DBInstance.html#Concepts.MultiAZ. 2010-05-15 22. Amazon SimpleDB Team, Amazon SimpleDB Consistency Enhancementshttp://developer.amazonwebservices.com/connect/entry.jspa?externalID=3572 2010-02-24 |
