极牛技术实践分享活动

极牛技术实践分享系列活动是极牛联合顶级VC、技术专家,为企业、技术人提供的一种系统的线上技术分享活动。
每期不同的技术主题,和行业专家深度探讨,专注解决技术实践难点,推动技术创新,每两周的周三20点正式开课。欢迎各个机构、企业、行业专家、技术人报名参加。

本期大纲
随着从0到千万用户的业务增长,通过aws的不同服务轻松地实现高性能和高可用的基础架构。

嘉宾介绍
方坤,AWS解决方案架构师,9年服务器开发和云计算领域解决方案经验。曾任Intel亚太研发公司软件开发工程师和UCloud云计算高级解决方案架构师,熟悉互联网领域多种应用场景,有丰富的初创企业IT解决方案项目设计经验。

方坤老师本次的主题比较偏向AWS实践的基础部分,假设了一个web应用从小型到中型和大型的时候,可能需要用到的AWS服务,以及相关介绍和实践建议。

可能有的小伙伴没太了解,所以几个重要的基础概念先说明下:

首先是区域(Region),它是一个物理的概念,数据中心的集合,可以覆盖一个地区或国家。

比如说北京区,就是覆盖中国地区,然后区域下面有可用区的概念,一个区域包括多个可用区。而可用区是若干物理数据中心(由高速光纤连接)逻辑上组成的,北京区有两个可用区,通俗来说可以理解为同城的多数据中心。

可用edge location,边缘节点可以理解为CDN分发节点,今天主要涉及到的服务会是计算、存储、网络三个部分。

为什么可用区的概念这么重要?是因为AWS的很多服务都是天然跨可用区的,提供高可用或失效转移的特性,这样企业就不用花费额外的工作量和成本来搭建。最初的时候,测试环境或者刚上线的时候,考虑到便利性,通常可以采用all-in-one的结构。

首先需要在AWS环境中创建一个VPC,VPC就像是为你提供了一个虚拟的私有云,一张大的二层网络。再通过我们的控制台工具,在里面划分的子网,配置路由。然后创建一台EC2,就可以SSH登录上,部署您的服务了,甚至可以把数据库也搭建在上面。

配置好IP,绑定到这个EC2上,你的用户就能通过DNS解析访问到这台EC2上的服务了。大体架构如下图:

clipboard.png

Route 53是AWS提供的DNS服务,他可以基于延迟、地区等规则来进行路由。但是目前在中国区不可用,您需要用到国内第三方的DNS服务。这是一个最简单的架构,即使是只有一台EC2,也是大有文章可做,因为EC2本身的配置非常多样。

它有不同的机型,比如内存优化型,适用于构建基于内存的数据库、大数据处理引擎、高性能计算等应用。还有GPU的机型,适用于3D图形应用等等,包括计算优化和存储优化机型。

EC2磁盘的IOPS也是可以配置的,如果有对io要求很高的话,可以选择存储优化,然后加上PIOPS配置,也就是预定义它的IOPS能力。

但是这样一个小型的架构,会存在以下问题:

  1. 很有可能访问会突增,那么势必会扛不住
  2. 没有失效转移
  3. 数据也没有冗余

所以,可以考虑先将web和DB拆开,DB的部分既可以选择比较合适的EC2机型自建,也可以选择AWS托管的数据库服务。其实关系型数据库服务为RDS,菲关系行数据库服务为DynamoDB。

RDS会比较常用,它可以支持oracle,SQL Server、PstgreSQL,MysQL和MariaDB。

好处是维护简单,因为底层都是AWS在维护。可以纵向更改配置,而且有自动备份。它还会在另一个可用区配置一个同步复制的从库,一旦主库失效,就能failover过去,DynamoDB的话后面再详细介绍。

于是,将DB拆出来后,架构图就会演变成这样:

clipboard.png

当然,这个架构还是在单个可用区部署的,所以随着业务的继续扩展,后面需要考虑到负载均衡和多可用区,我们会建议再演变成下图:

clipboard.png

ELB支持HTTP和HTTPS,而且会对后端做健康检查,这样一个原型,扩展性很好了。

clipboard.png

可以一直横向的扩展,当然,最后的瓶颈势必会出在DB上。这样的扩展还是存在一个问题,就是所有的事情都要人手动来做。

AWS提供了一个工具,叫auto scaling。让企业结合监控规则来自动扩展,比方说,可以定义web server这一层的最小和最大数量,根据CPU的负载来决定是否要扩容缩容,具体配置方法比较细节,就不在这赘述了。

同时,还要考虑动静分离,将静态资源分离出来,比如图片、css、js、视频等等,结合源站存储和CDN来部署,源站可以使用S3服务。S3是对象存储,自动扩容,只需要把你的对象放进来,通过控制台或者命令行工具或者SDK来读写。

海外的话,AWS提供cloudfront服务,也就是CDN加速;国内的话,暂时需要用第三方的CDN服务。

S3的好处是持久性高,有11个9,每个对象最高达5TB。S3有两种,除了通用的S3服务外,还可以选择低冗余的类型,用来存储不是那么敏感的数据,这样可以节省成本,这是静态的内容缓存。而动态的内容缓存,基本上是用到内存型存储或者NoSQL。

有个服务叫ElastiCache可以提供memcache和redis服务,可以把DB的热点数据放在这里面,提供更高的IO性能。ElastiCache也是托管型服务,好处是可以方便的分片或者构建集群和副本集,像redis的话可以支持数据持久化,多个可用区。

缓存也可以用DynamoDB来替代,它可以提供延迟低于10ms的数据存取,总之,架构可以演变成下图:

clipboard.png

简单起见,这里只显示了一个可用区关于这两个服务的更多细节,所以基本上,一个中型的web服务,在AWS上就可以这样架构:

clipboard.png

再之后的优化,就是自动化了,一方面是auto scaling这个工具,另一方面AWS也提供了一些自动化运维的工具。

像ElasticBeanstalk,你可以把你的应用上传过来,只需要简单的配置,这个服务就会帮你配置好网络、服务器和数据库;像OpsWorks,它是一个托管型的chef服务;还有Cloudformation,它可以帮助你把AWS上使用的服务通过一个JSON文件来管理,这样不论是基础架构的版本管理还是自动部署,都会更加方便,一切都代码化。

另外,监控方面,需要用到CloudWatch服务,它不仅基本的基础架构监控,也可以让你自定义应用级别的监控。后者需要用到我们的代理agent。然后,AWS也有工具和服务可以帮助你把架构SOA化,把服务当做独立的单元对待,独立地进行扩展,比如邮件服务,消息通知服务,消息队列服务等等。

那消息队列服务来说,AWS提供的SQS服务,可以帮助架构解耦合,通过简单的API来首发消息,消息存储在无限制容量的SQS里,然后可以对队列做认证和权限控制,而且这个消息队列也是基于多个可用区存储的,所以也提供高可用。

当然,出于性能的高可用考虑,它无法百分百保证先进先出,所以只需要在应用里面加入对顺序对的控制即可。

还有一个lamdba服务,它是一个函数的托管服务,您可以把基于事件触发的函数托管过来,不需要关心底层的扩展,比如说你有一个用户在S3上传了图片,可以触发Lambda的函数来处理,并将通过SQS队列来把任务发给EC2,处理完后又触发Lambda函数把该图片的元数据保存到数据库里。

在各个AWS服务之间,都通过Lambda来粘合,让你的应用更轻量级,也不需要考虑其扩展性和可用性,所以当你的应用到达大型之后,就可以考虑如下几个方法了:

  1. 部署多可用区
  2. 用ELB负载均衡流量
  3. 用auto scaling自动扩展
  4. 利用AWS的服务SOA化
  5. 利用S3和CDN动静分离
  6. 缓存DB
  7. 把应用尽量无状态化,这一点可以通过SQS、lambda等服务来支持,参考下图:

clipboard.png

最后的话,就要解决DB的瓶颈了。如果您在使用关系行数据库的话,只有两个办法。要么按业务和功能划分数据库,这一点AWS能协助的是帮助你方便地搭建读副本,但是更多的需要您从业务层面来梳理和划分;要么就是做sharding,这一点来说,AWS RDS也只是能提供底层的支撑,更多的是应用层面的分片。

然而,在NosQL这一部分,AWS的DynamoDB可以提供强大的帮助,所以您需要考虑哪些数据是可以上NoSQL的,这一点的扩展性在AWS上是非常好的支持的。

DynamoDB是一个托管式的NoSQL数据库,可以提供很高的性能,您可以更具实际的需求来配置读写性能。底层支持分布式和容错,基于SSD的存储,平均延迟低于10ms。可以提供最终一致性或强一致性。数据的副本基于多可用区分布是部署,您只需要管理你的表和项目,而至于底层的节点,对您来说是透明的。

当然,更重要的是从业务层面来梳理,再来归纳几个重要的点:

  1. 要使用多可用区部署
  2. 充分利用能自动扩展的服务,比如ELB,S3,SNS,SQS等等
  3. 充分考虑NoSQL的可行性
  4. 外部和内部的缓存
  5. 尽可能的自动化,充分利用AWS的自动化工具,比如auto scaling、cloudformation等等
  6. 确保您充分利用了cloudwatch的监控服务和日志工具
  7. 充分利用AWS的服务来进行服务模块化
  8. 别在AWS上重复造轮子

Q&A

Q1:如果业务既面向国内,也面向海外,是使用aws国内版,还是海外版?互通性会不会不同地区用户的体验问题?

A1: 首先不可避免的是海内外网络的稳定性和性能问题,基于国情建议如下考虑:

如果主要的用户来自国内,您可以部署在国内,然后海外部分通过将静态内容CDN加速来降低延迟、甚至是使用国际专线,我们也有合作伙伴来支持;反之国际亦然。

还有一个办法,就是看能否分开部署,这个完全取决于您的业务和应用能否支持了,这个主要还是网络基础设施层面的问题。

Q2:从国内现有的云服务,迁移到aws,有什么好的方式不?

A2:其实困难主要就是在于数据库的迁移。我们有个工具叫DMS,国内尚不可用,将来应该会有。所以一般的方法就是先将全库拷贝过来,然后再增量复制。因为不同数据库特性不同,总的来说,就是AWS会帮助大家一起想出最佳的方案。