AWS云服务分析

1，S3

Ø  S3 分为standard（含rrs）、IA两种class，实现上陈靓由于自己公司准备做S3存储，所以基本没有提及，问问题也不回答，只提到EC模式；

Ø  S3是每个region一个大集群，跨多个az。集群大小和bucket不限制容量之间是个矛盾。问大集群如何控制扩容时rebalance和故障时recovery对业务性能的影响，理由比较牵强；其中提到三星电视在赛事当天同时开机导致对应bucket性能缓慢，紧急扩容问题，说明AWS支持对bucket定向扩容；

Ø  由于S3跨3AZ，访问、rebalance、recovery都需要消耗az之间的带宽，尽管az之间是裸光纤，也会影响共用裸光纤的amazon电商业务性能；

Ø  S3每天新增2PB数据，设计上要等到利用率达到98%以上才扩容；经常要扩容；所以性能容量监控CloudWatch很关键； e)        S3除了生产环境，有单独的测试环境；

Ø  S3节点是自动部署上线的，过程一般是先做拷机测试，然后再加入集群，做rebalance；扩容机器到货后扩容般要一周左右， rebalance据说是一个region的集群所有节点的数据都向新加入的集群拷贝数据，一般要2-3天基本才能完成；rebalance有流控，若可用空间特别紧张的情况下，则放开流控，就不顾rebalance对服务访问的影响。

Ø  AWS的2 pissateam比较出名。S3团队分为4个小team，前端20人左右、index20人左右、Volume10多人、Operation10人，总共60人左右（其他团队都相对要小一些，说明S3服务最复杂）。OperationTeam专门负责白天的运维（其他团队没有operationteam），换下研发人员做设计和coding；晚上是研发人员自己运维；

Ø  S3对内和对外的Endpoint之前不是一个入口，但主流是合并成一个，内部和外部API稍有差别，通过权限来控制；

Ø  S3的升级先做新加坡，运行几天稳定后，升级东京，然后是欧洲，最后是北美；这些region业务量从小到大；

Ø  S3存储利用率平均达到90%，CPU利用率平均达到70%

Ø  s3存储服务团队由10人左右的专业运维负责维护全球上百万台的服务器，晚上6点以后运维的责任人切换为研发，每天都有一名研发人员on call

Ø  EC2的业务（比如镜像备份，逻辑卷备份等）是走的s3存储的内部接口调用，而非调用外部公共接口。

Ø  S3存储全球的服务版本发布是同步的，不存在哪个站点是单独的版本，升级的先后顺序通常是选择规模最小的新加坡站点，然后逐步升级其他站点。

Ø  s3存储的鉴权最开始是自己做的，最后才支持IAM模型，所以目前是支持两种鉴权方法

Ø  cloud front是专门给s3存储做的CDN服务

Ø  s3存储最开始使用的是副本作为冗余方式，最后改为EC，并且写了程序，将原来的副本合并为EC

Ø  s3存储的体量十分巨大，全球数十万台服务器，陈靓博士阐述了数据规模与数据持久性的关系：副本冗余方式下，数据持久度随着数据规模增长下降类似于3次方函数的趋势，而EC的数据持久度对数据规模并不敏感，s3存储从来没有因为机器或者磁盘故障丢失过数据，出现过运维人员误删以及遭雷劈丢失（好像是在比利时数据中心）

Ø  s3存储对于网络的带宽要求极高，扩容，故障恢复，老旧替换等场景均会对东西网络产生极大压力，而s3存储作为集中存储，对将南北流量也集中起来，方案的设计需要全栈考虑。

Ø  S3存储的数据冗余度大概是2点几，glacier的冗余度大概是1点几。

Ø  S3存储存小对象实际上服务方是吃亏的，很多人以前钻漏洞，把s3当成一个索引来使用，上传0字节的文件，因此s3的服务按数据量以及下载次数来收费。

Ø  S3存储是AWS所有服务中用户粘性最高，最赚钱的服务，每天都有大量的数据上传下载。

 

2，  Glacier

Ø  Glacier服务设计经历了3次修改，历时1年多，最后实现花了半年；

Ø  修改的原因是在即时、延时，写和读的组合上存在反复权衡；最后决定采用即时写（到写缓存），延时读（一般4个小时，恢复到缓存）

Ø  Glacier架构上分为冷存储controller，利用S3做缓存，利用DynamoDB做index，利用高密盘柜做存储介质（SMR盘，密度非常高）。注：Singaphore机房不能承载这种高密盘柜，欧洲北美可以；

Ø  Glacier中使用了Checksum确保网络错误和内存flip（概率很低，AWS碰到过）；

Ø  Glacier正常1/3硬盘运行；2/3硬盘sleep；

Ø  Glacier并没有使用高温存储

Ø  机架密度1个机架约7-8个host，每个host约100盘，一个rack的存储容量好几个PB。

 

3，  ELB

Ø  采用least connection负载均衡策略；AWS一直用这个策略；

Ø  防止ddos攻击：每个Coral节点（类似Nginx节点）运行Throttledaemon，统计用户的并发链接和带宽上限；

4，  监控TP99：用户体验

Ø  AWS非常关注用户体验，分为三种严重级别：Survilance1,2,3，S1是贝索斯亲自关注；S2是30分钟升级，要么下线；S3是team自己处理；

Ø  值班人员配备Pager，有问题会半夜鸡叫；

Ø  s3存储的告警水位设置的比较低，系统压力上来以后（比如全美直播超级碗的时候），call机就会响个不停

 

5，aws服务设计

Ø  任何服务的架构设计一定要高可靠，支持海量可运维，低运维成本

Ø  Aws服务的设计（api的定稿）通常持续很长时间，glacier的服务设计花了接近一年，反复讨论需求和能力，开发只花了几个月。

Ø  Aws服务的高可用高可靠设计均是在region内部的AZ间实现，持久化层，包括DYNAMODB，s3存储，Glacier都是跨AZ高可用，逻辑业务层需要业务自行在多AZ部署业务，跨region容灾是可选项服务，用户需要考虑需求的价值和成本之间的平衡。

Ø  Aws所有的服务设计，技术选型都是相对独立的，各个team自行决定需要采用什么样的技术，架构，其中DYNAMODB S3存储 GLACIER三个服务是完全独立演进，甚至是其他服务的一个强依赖的基础设施服务。

Ø  Aws的服务设计有一条总要求，所有服务组件都必须scaleout，SQL数据库的使用在方案评审的时候很容易被一掌拍死

Ø  AWS所有的服务的入口点均为LB，LB后面通常分为三层设计：接入层，业务层，持久化层

Ø  Aws并没有所谓I层，P层，S层的概念，所有的服务均是面向一定的场景，以功能维度划分切以web服务的方式暴露AWS的基础设施能力。

Ø  Aws所有服务均是通过http进行通信，包括内部接口调用，由一个公共组件coral承担，该组件有比较丰富的功能。

Ø  Aws常用leaseconnection作为负载均衡算法

Ø  Aws认为任何环节都是不可靠的，因此checksum数据校验无处不在。

Ø  Aws API设计的考虑因素：是否cover住了用户所有的需求；每个api提供一个功能还是将多个功能柔和在一个API之内；前后版本的兼容性，因此api的参数大多数都是option可选，已兼容老版本的API；公共服务API的访问控制统一支持IAM；内部服务API基于token;

Ø  API的设计实质上是架构的设计，一般由senior完成，用户实际上并不知道自己的需求何在，因此流程是这样的：PM通常会跟各种用户聊，然后将原始需求返回给SE，SE会站在系统视角理解用户需求，并翻译成系统设计开发需求，最后做架构设计，设计完成后与用户确认，最后进入开发流程，需求分析和设计实际上很多时候都靠领域专家的经验，没有方法论可言。

Ø  AWS内部并不强调微服务的概念，每个服务都是面向特定场景，满足用户需求的一个服务。

Ø  需求的讨论一定要充分，充分的讨论完需求，才会动手开始做API/架构设计。

Ø  存储的设计最难的是做异常处理，所有异常都要在白板上能力穷举出来。

 

6，运维运营：

Ø  Aws的所有服务都必须要支持平滑升级，升级完之后会有一段时间的buffer观察期，观察新版本的兼容性。

Ø  Region与region之间是完全相互独立，region的升级首选规模较小的新加坡站点，region内的升级也是AZby AZ

Ø  S3存储的扩容然开发运维团队相当痛苦，为了保持低成本，通常数据的使用量维持在90%，每个月都有例行扩容，而且扩容会导致大量数据的迁移，对AZ间的网络产生巨大压力。

Ø  计费是一个公共功能，实现通常是在coral组件中插入代码做统计，并调用billing服务，修改费用状态。

   

7，  团队运作：

Ø  服务设计方案团队有完全的自主权，但要经过principal角色评审，评审意见达成一致才能启动开发，也有一些原则遵守，比如AWS服务一般禁止使用关系型database方案

Ø  API的定义决定系统架构和实现，一旦定下来就基本不会修改（只会新增），往往投入大量的时间进行设计

Ø  主要采用DevOPS方式运作，全功能团队，团队内角色不固定，开发、测试、运维都要做；轮流运维导致人员压力大，人员流动率非常高，一般2-3年就换一轮

Ø  少量独立的DBA和Tester角色可以各个服务化team可以共享使用

Ø  基本没有统一标准的方法论、流程和模板来支撑，感觉主要靠个人能力和文化来支撑运作

Ø  Glacier的设计是几个人完成的

Ø  文档和webconsole维护是单独的团队和service团队是分离的，service团队的能力末端即为api

Ø  团队内部人与人之间必须要有不同声音，不同人站在不通角度总会给到你有益的意见

Ø  AWS的组织架构设计：分领域，比如DB，存储，计算等，领域下有一个director，看护架构，比如存储领域下三个子领域：s3 EBS DynamoDB,每个服务当中由两个重要角色组成：产品经理（老板），senior。