从零到千万用户的云端(AWS)基础架构最佳实践

摘要：本期大纲随着从到千万用户的业务增长，通过的不同服务轻松地实现高性能和高可用的基础架构。方坤老师本次的主题比较偏向实践的基础部分，假设了一个应用从小型到中型和大型的时候，可能需要用到的服务，以及相关介绍和实践建议。

极牛技术实践分享活动

极牛技术实践分享系列活动是极牛联合顶级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上的服务了。大体架构如下图：

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

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

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

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

很有可能访问会突增，那么势必会扛不住

没有失效转移

数据也没有冗余

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

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

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

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

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

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

可以一直横向的扩展，当然，最后的瓶颈势必会出在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的数据存取，总之，架构可以演变成下图：

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

再之后的优化，就是自动化了，一方面是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来粘合，让你的应用更轻量级，也不需要考虑其扩展性和可用性，所以当你的应用到达大型之后，就可以考虑如下几个方法了：

部署多可用区

用ELB负载均衡流量

用auto scaling自动扩展

利用AWS的服务SOA化

利用S3和CDN动静分离

缓存DB

把应用尽量无状态化，这一点可以通过SQS、lambda等服务来支持，参考下图：

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

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

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

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

要使用多可用区部署

充分利用能自动扩展的服务，比如ELB，S3，SNS，SQS等等

充分考虑NoSQL的可行性

外部和内部的缓存

尽可能的自动化，充分利用AWS的自动化工具，比如auto scaling、cloudformation等等

确保您充分利用了cloudwatch的监控服务和日志工具

充分利用AWS的服务来进行服务模块化

别在AWS上重复造轮子

Q&A

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

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

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

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

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

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

下期预告
时间：2016年11月23日 晚8点
方式：线上微信群
主题：直播中视频编码实践经验总结

报名请关注极牛公号（ji-niu）并回复技术分享。