1.Amazon Web Service
应该可以说，Amazon Web Service目前是云计算领域的领头羊，其业务规模、开发水平和盈利能力在业界内都是首屈一指的。从本科毕业离开学校就一直做Java后端，后来又接触到大型的SOA组件和中间件，现在读研毕业后有幸加入到了AWS开发团队，真是做梦都没想到。在异常复杂的系统、大量资料面前，不敢懈怠，抓住这个学习的好机会学习一下AWS。当然，一来因为刚入职不久了解很浅，二来也没法泄露公司内部的资料，所以本文只能比较全面地简要介绍一下各种流行的AWS服务。
关于参考资料，《Amazon Web Service in Action》是一本还不错的书，但也别指望里面能有什么特别深入的干货，毕竟AWS不是开源的。如果想再深入一些学习的话，可以看看AWS的官方文档以及博客，经常会有些讲到设计思想和开发经验的不错的文章。本文介绍了不少AWS的服务，都比较常见，可以重点关注S3、RDS、EC2、SWF等最为核心的服务。其他像Lambda、IAM、VPC等了解不多，所以一笔带过，还请见谅。虽然整体上介绍的比较浅显，但为了增加些乐趣，会加入一些自己的所见所闻。
2.存储介质与数据库
2.1 EBS (Elastic Block Store) & Instance storage
AWS提供了两种块级别存储（Block-level）：EBS和Instance storage。首先，我们为什么需要Block-level的存储呢？有像S3这一种存储不就够了吗？答案是S3不是万能的。块级别存储就是给像MySQL等传统数据库，通过调用操作系统的系统调用与磁盘交互的软件。EBS提供了Network-attached storage（NAS），在AWS中是一种独立于EC2实例的资源。可以单独创建单独付费，然后挂接到某个EC2实例上，提供类似RAID 1级别的备份（数据完全备份到多处）。
而后者Instance storage，则是类似于在EC2实例所在的虚拟机上挂接一个普通的磁盘，所以EC2实例停止或销毁后，存储也就不存在了。因为Instance storage是EC2实例的一部分，所以无需额外付费。其应用场景有：部署缓存软件、用于临时处理和中间结果保存、应用级别有Replication的情况。例如我们使用NoSQL等数据库时，一般情况下都会在Application级别复制，所以就无需使用EBS存储。
因为不管是EBS和Instance storage，同一时刻只能属于一个EC2实例，所以无法实现块级别的数据共享。对于这种情况，AWS提供了一个新的EFS服务（Elastic File System），基于NFSv4（曾经Sun公司的Network File System）。
2.2 S3 (Simple Storage Service)
S3是AWS的主要存储服务，内部按Bucket进行分隔，每个Bucket里都可以直接存储Object，最大支持到TB级别的单个对象大。每个Object都会有唯一的ID，并可以通过Url直接访问。而且还支持一些一致性读写的语义，功能可以说是非常强。一般用它来存储应用程序的配置、运行状态等信息，非常方便。也可以通过引入S3，实现无状态服务（Stateless server）的理念。
2.3 RDS (Relational Database Service)
数据库是应用程序的重要组成部分，当我们在AWS上部署应用程序时当然少不了数据库这块。第一种方法就是在分配给我们的EC2实例上自己安装数据库实例，而另一种更方便的方式就是使用RDS服务。目前，RDS提供了MySQL、Oracle、SQL Server、PostgreSQL等主流数据库的支持。虽然很自然地，使用RDS要比直接使用EC2服务要贵一些，但是从另一方面来讲，数据库的安装、部署、高可用、维护、升级都交给了AWS的专家负责，省去了自己雇佣DBA团队的费用，所以对很多客户来讲，也许还是比较划算的。使用RDS的方式也很简单，RDS隐藏了EC2的细节，我们直接按照RDS的要求配置，就可以得到一个可用的单实例或主从复制的数据库集群了。
此外，还可以关注一下AWS的新东西，兼容MySQL但有更好的性能的Aurora和新型的图数据库Neptune。在公司的工位旁边就是Neptune开发组，有一位梳小辫子的大叔，Principal Engineer，貌似是Neptune的架构，看起来很Cool～
2.4 DynamoDB
DynamoDB是NoSQL数据库的一个典范，因为它集各种先进的分布式技术与一身，但又不是象牙塔里的试验品。迄今为止，它仍然在Production中活跃地运行着。因为之前在学校上Distributed System课时，老师也把它当作Case study进行了详细的剖析，所以准备过后在单独的一篇介绍分布式编程的文章里详细介绍一下，这里就一笔带过了。
深入学习资料：论文《Dynamo: Amazon’s Highly Available Key-value Store》。
2.5 ElastiCache
ElastiCache，顾名思义，就是弹性缓存，目前支持Memcached和Redis两种。与笔者在之前的一家公司做过的缓存云很像，但具体内部设计还没有研究。感兴趣的同学可以自行去官网看介绍。
3.计算与分析
3.1 EC2 (Elastic Compute Cloud)
EC2应该是AWS服务中的王者了，因为任何其他的AWS服务，谁能不需要个虚拟机来计算呢？不管是缓存、数据库、搜索等等，都需要一个运行软件、执行计算任务的载体。而EC2就是这个通用的载体，目前已经不清楚EC2的服务集群到达几百万机器的水平了，这种分布式软件的开发和运维水平还是很让人震撼的！一般使用EC2的话，还会接触到三个密切相关的服务：ASG (Auto Scaling Group)、ELB（Elastic Load Balancing）、Route53。
ASG使EC2的实例根据用户定义的规则自动“伸展”（增加新实例或关闭正在运行的实例），这不仅使用户的网站更有弹性，例如在旺季、高峰季自动增加实例来应对压力，而另一方面还能为用户节约成本，因为最常见的On-demand付费方式是根据EC2实例的使用量来计费的，所以不需要时自动关闭实例能够大大节约成本。因为ASG如此有用，所以用户都希望自己的网站能自动弹性扩展。那自然而然的，ELB也就成了必需。因为使用ASG的话，用户自己维护负载均衡配置就会非常麻烦，那就交给ELB吧，它可以与ASG配合，不会将流量导到已经关闭的实例上，省却了手动维护的烦恼。最后，使用Route53的DNS服务，一整套的网站基础设施就齐全了。怎么样，在AWS上建立一个自由扩展、高可用的网站很容易吧！这方便背后可是EC2等各个部门开发人员的辛勤劳动换来的，程序员不容易 ：）
3.2 Lambda
Lambda目前也是比较火的一个服务，用户提供无状态的服务代码部署到AWS环境中来进行数据处理。可能因为这种思想比较像无状态（准确说是Immutable）的函数式编程，所以起了这么一个比较酷的名字。值得一提的是，面试时有一位面试官就是做Lambda的，正好那学期在学Lambdad Calculus，还说了一嘴，然后还有幸一起讨论了一下他目前在做的设计。
深入学习资料：《AWS Lambda in Action: Event-driven serverless applications》、《Serverless Architectures on AWS: With examples using AWS Lambda》
3.3 ElasticSearch
这是目前我们组正在做的。ElasticSearch的前身是CloudSearch，一个基于Solr的全文检索服务，后来由于种种问问，目前已经不推荐客户使用了，转而大力宣传新的ElasticSearch服务。虽然与开源的ElasticSearch同名，而且的确核心的全文检索部分就是使用的ElasticSearch集群，但Amazon使用每种开源产品时还是有很多工作要做的。重点就是如何集成到Amazon自己的技术栈里，这里有一个很关键的指导原则：尽可能地使用现有的AWS服务，而不要自己去造轮子。所以在内部，经常会看到一个系统大量使用现成的AWS服务。要做到这一点看似容易，实际上是Amazon完善的基础设施使其变得可行。
这里说一些题外话，也是最近的感受。之前曾在国内电商工作过，确实对比才能看出不足和需要改进之处，反之衬托出了Amazon技术的完善和成熟。举一个小例子，比如现在你正在开发的系统要使用一种Worker，即能立即或定时触发任务、出错时能重试、能监控运行状况、能发送警告等。在不完善的情况下，你就要去找到底哪个部门做了这么个能重用的东西，如果找都找不到，那就要上网找开源并进入技术评估环节了，要做的事情很多，包括选取几个主流产品、功能对比、哪些是你需要的哪些是缺失的、社区活跃度如何、License是什么是否可用等等。如果想做的更好一些，想牵头开发个可重用的组建，可能还要公司范围内收集意见和需求等等。好，如果幸运地发现有人做了，就要去找这个人要API、要Sample实例，如果是服务式的还好，否则还要学如何嵌入你的系统，是引包还是单独部署实例等。不管是哪种情况，都需要很多沟通，费时费力。很明显，有许多待完善和改进的地方。
下面说说在Amazon的情况。在内部有个Wiki，之前在一些公司工作时也都有Wiki或者知识库之类的。但Amazon的Wiki真的是一座大宝库，每个部门都维护自己的页面，主页面下又会细分很多块。其内容完善到，从各种系统的介绍、架构设计、使用，到每个部分的新人该如何上手搭环境、部署测试系统、提交代码、Oncall等等，应有尽有。继续前面的例子，当需要某个组建时，在Wiki上搜索。假如我们看到了SWF这个服务很好用，就进去细看，于是就会发现详尽的介绍、目标、架构、编码风格、使用手册、API文档、常见问题、最佳实践、项目组成员、讲座视频、发布计划等等，详尽的已经觉得没什么可补充的了。如此可见，资本主义的确有很多值得学习的地方 ：）
深入学习资料：因为AES（Amazon ElasticSearch）闭源，感兴趣地可以学习一下开源的ElasticSearch，可以从中学到很多分布式的编程知识。权威的书籍就是这本权威指南了《ElasticSearch：the definitive guide》，《ElasticSearch in Action》也不错，都是经典的系列。但要知道ElasticSearch只是AES中一个小小的部分，围绕着它的有各种管理、监控、部署、计费等等组件，由此可以想见AES以及其他类似设计的AWS服务都有多么的庞大。
4.管理与架构
4.1 CloudFormation
前面已经介绍了这么多AWS的服务，一些核心服务使用率很高，而且一些服务还经常一起搭配使用，比如ELB+ASG，那配置起来是不是很繁琐？CloudFormation正是来解决这个问题的，它的设计思想就是Infrastructure as Code，架构即代码。通过类似Json格式的简单配置就能得到你想要的服务，而且CloudFormation远比它看起来的强大。能够定义占位符，能够管理架构创建的顺序和依赖等。
4.2 CloudWatch
CloudWatch也是AWS内部重度使用的服务，服务的运行状态监控、预警等，前面介绍过的ASG（可能是）通过CloudWatch收集的数据，来决定是否进行伸缩。
4.3 SWF (Simple Workflow)
不太清楚从外部客户角度来看，SWF的使用和盈利情况如何，但从内部来讲，SWF是一个非常有用的服务。因为SWF可以将一个复杂的计算过程分成步骤，一步一步地执行并记录状态，所以在内部被很多服务大量使用。其实这种类似Worker和Workflow的框架有很多，例如Quartz、淘宝的TbSchedule等，但多数是Standalone或提供lib包的方式。而SWF则秉承了AWS的一贯原则，将这个功能做成了统一的服务，于是省却了代码维护和线程池管理的麻烦。
个人觉得，就像名字暗示的那样，SWF更注重Workflow，由我们使用者提供Decider决定有哪些状态和如何流转、以及Worker在进入各个状态时执行相应的逻辑，两者都以polling的方式与SWF服务交互获取信息。Worker还可以与Lambda服务无缝结合，充分利用AWS的各种服务和资源。而调度方面则比较弱，一般由一个初始事件触发一个Workflow execution，比如一个订单工作流，当一个用户下单时就会触发一个execution执行。所以在调度方面要远弱于像商业软件Autosys这种，直接支持Cron格式、并可以声明各种复杂的任务间依赖关系，毕竟侧重点有所不同吧。
但即便如此，SWF却是相当有用的。引入SWF后，当一个复杂的流程出问题时，可以很快就确定是在哪一步出问题的。如果代码本身做了防重（或者叫幂等性），那么就可以安全地让SWF重试，让出问题的这个Worflow execution成功执行下去。所以在这方面上，有大量的ops工具可以围绕SWF开发，大大提升系统的解决客户问题和运维的效率。另外也避免了每个系统都维护线程池进行定时调度和工作流执行的资源浪费问题，因为以前就经常碰到比较小的项目，就因为一个小定时任务就得开线程池。
5.权限与安全
5.1 IAM（Identity and Access Management）
IAM仿照传统的RBAC（role-based access control），在用户、角色、资源三者间建立起映射，每个通过AWS API的调用都会通过IAM系统检查请求是否被允许。IAM控制了谁（验证，Authetication）可以做什么（授权，Authorization）。
5.2 Security Group
Security group可以被简单地看作传统意义上的防火墙，规定了哪些端口可以进出数据。猜想Security group功能已经集成到了Amazon自己的Linux版本中，每个使用它作为镜像的EC2实例都能方便地开启。还有很多其他功能也都有着类似的便捷，这种统一的基础设施的设计和推广使用也是值得学习的。
5.3 VPC（Virtual Private Cloud）
简单来说，VPC使用户能够自己定制虚拟网络，就像整个环境都是他自己的一样，随意地为Web服务、应用服务、数据库等定义私有的子网。AWS内部很多系统都与VPC集成，提供VPC功能，使用户可以方便地将AWS服务像使用自己网络里的一个软件一样无障碍地随意使用。
http://blog.csdn.net/dc_726/article/details/77790507