基于亚马逊云的快速架构设计,适用于创业型互联网公司

AWS 架构设计: 需求

概要

有这么一个小公司,处在创业阶段的起步期。他们正在使用的架构是 LAMP 环境。在他们狭小的办公室里,一台 PC 运行了所有的 MySQL、Apache 和 PHP。虽然如此,他们还是和许多创业者一样,心怀远大,深信自己就是下一个谷歌或苹果。他们期待几个月后,业务就会发生翻天覆地的高速增长,那增长大到他们无法衡量。野心和幻想的交织下,他们开始用心考虑如下问题:

-如何扩展系统,才能跟上需求的增长,又能兼顾到各种不确定因素。实际上,他们根本不知道需求什么时候会来,又会有多大。所以,他们一方面不想过早购买太多的设备,另一方面又担心设备不足后悔莫及。

-灾难恢复上,缺乏措施和方案。

-在高效和高容量系统上,他们缺乏配置数据库和数据库访问层的能力。

-如何让用户通过浏览器访问时,保持极低的系统延迟。要考虑到他们大部分的用户距离极远。

-有效的负载均衡。

-基础设施如何实现自我修复。能够将失效的服务实例恢复运行。

-在存储和传输中,数据的安全问题。

-交付团队扩大后,对环境的访问能够保证安全。

-归档策略,针对闲置超过6个月的对象。

-轻松管理多个环境,并根据蓝图架构复制环境的能力。

目标

要支持创业公司的快速增长,我们所建议的架构必须满足:便于管理、安全、可扩展、高性能、高效率、弹性、高可用、容错、可恢复。这种架构必须解决上面所述的各种需求及顾虑。

解决方案:

下面所描述的,乃是一个概要层次的架构设计,对于期待快速增长的创业型互联网公司,有着很强的针对性。所建议的架构,基于亚马逊的 AWS,因此完全可以满足各种不同的企业应用。设计方案的目标读者,是公司CTO,研发总监/经理和其他参与技术决策的负责人。

为何推荐 AWS 给创业公司?

AWS 解决方案的弹性特征,给创业公司提供了企业云计算能力。

要考虑到创业公司的所谓增长,都还是没影的事。为了追求投入的性价比,解决方案就必须可以方便的伸缩,以适合业务的增长趋势。AWS 的组件,全部都是弹性的,可以在运行时根据负载,进行自动伸缩。比如,当服务器上的负载增加或者减小时,可以使用 EC2 增加更多的服务器,或者减少服务器。AWS 按量付费的定价模式,让用户的投入也是弹性的。 这样一来,负载增加,用户增加资源,付更多的费用;负载减少,用户缩减资源,则费用降低。AWS 给解决方案带来良好的弹性,可以应对任何时候的任意负载。

在处理突发流量负载上,AWS 解决方案的弹性极强

互联网系统在高峰负载时,常常性能下降。这都是因为资源无法实现伸缩,难以满足突发负载。AWS 可以自动配置 VM 实例,帮助用户在负载增加时添加更多的web服务器。当负载回归正常后,又可以关闭或取消这些服务器。这个功能,让整体解决方案在面对随时变化的流量负载时,具备足够的弹性。

部署和维护的便捷性

创业型的公司,系统需求变更频繁,系统的部署更新也就非常频繁。在开发、测试、集成测试和生产各个阶段,都需要和一致的运行环境。AWS 对资源进行按需配置的特性,便于用户在每个阶段轻松的部署和测试系统更新,最终保证顺利的生产发布。这就极大的减少了在开发环节需要投入的硬件和维护成本。

创业型互联网公司的 AWS 云计算架构:

在此架构中,我们将关键组件进行分类。

下面所列分层,每个层次的管理都需要相应的技能。这样的分层,帮助企业在增长时,合理分派员工,对访问权限、安全和组件的所有权进行管理。

基于管理技能对关键组件进行分类:

1.  网络层:

a.  管理外部/内部网络配置和安全,可使用的工具包括 AWS Route 53,ELB,多可用区,Elastic IPs, Security Groups 等。

AWS Route 53 是一种可用性高、可扩展性强的云域名系统 (DNS) Web 服务。它的目的是为开发人员和企业提供一种非常可靠且经济高效的方式,把名称(如 www.example.com)转换为计算机用于互相连接的数字 IP 地址(如 192.0.2.1),从而将最终用户路由到 Internet 应用程序。

ELB (Elastic Load Balancing) 在多个 Amazon EC2 实例间自动分配应用程序的传入流量。使用 Elastic Load Balancing,您可以提高应用程序的容错性能,同时提供持续响应应用程序传入流量所需要的负载均衡容量。Elastic Load Balancing 可以检测出池内的不健壮实例,并自动更改路由,使其指向健壮实例,直到不健壮实例恢复健壮为止。客户可以在单个可用区域或多个可用区域中启用 Elastic Load Balancing,以提高应用程序性能的一致性。在 Amazon Virtual Private Cloud (VPC) 中也可以使用 Elastic Load Balancing 来在不同的应用程序层内部分配流量。

多可用区 (Multi-Availability Zones) 亚马逊在全球11个地区(region)拥有数据中心。 每一个地区拥有最少2个可用区(Multi-Availablity Zone),一个可用区由一个或多个数据中心构成。

Elastic IPs,弹性 IP 地址是专为动态云计算设计的静态 IP 地址。弹性 IP 地址与您的 AWS 账户关联。借助弹性 IP 地址,您可以快速将地址重新映射到您的账户中的另一个实例,从而屏蔽实例故障。弹性 IP 地址是公有 IP 地址,可通过 Internet 访问。

安全组(Security Group):在EC2环境中启动的实例都属于某一个安全组。每个安全组定义自己的防火墙规则,为在组中运行的实例指定访问限制。可以根据IP地址或无类域间路由(CIDR)规则授予或限制访问权,CIDR规则允许指定端口范围和传输协议。

b.  保证来自全世界的访问,都能够正常到达网站。并实现各种层次的负载均衡,比如在 web 服务器层和 app 服务器层进行负载均衡。

2.  Web 服务器层:

a.  管理 Web 服务器,可用的组件包括 AWS EC2, AMI 镜像等

b.  配置和维护 web 服务器实例,保证对 web 请求的处理。

Amazon Elastic Compute Cloud (Amazon EC2) 是一种 Web 服务,可在云中提供大小可调的计算容量。该服务旨在降低开发人员进行网络规模级云计算的难度。

亚马逊机器镜像(AMI)是启动一个实例时,所要提供的信息。实例实际上就是云端运行的一个虚拟服务器。AMI 包括实例 root 卷的模板(例如,操作系统、应用服务器、应用),使用权限,启动实例时要挂载卷的块设备映射。

3.  App 服务器层:

a.  使用 AWS EC2,AMI 镜像等,管理 App 服务器,

b.  配置和维护 App 服务器实例,保证对 web 请求的处理。

4.  数据库层:

a.  使用 AWS RDS, IOPS Volumes 等,对数据库服务器和数据进行管理,

b.  负责对后台数据库访问、安全、性能和可用性的配置及维护。

Amazon Relational Database Service (Amazon RDS) 让您能够在云中轻松设置、操作和扩展关系数据库。它在管理耗时的数据库管理任务的同时,可提供经济实用的可调容量,使您能够腾出时间专注于应用程序和业务。Amazon RDS 提供 6 种熟悉的数据库引擎供您选择:Amazon Aurora、Oracle、Microsoft SQL Server、PostgreSQL、MySQL 和 MariaDB。

Amazon Elastic Block Store(EBS)可作为EC2实例的持久性数据块级存储。
Amazon EBS共提供三种硬盘类型,SSD(固态硬盘), Provisioned IOPS SSD(特供IOPS固态硬盘)和Magnetic(普通硬盘)。SSD是默认的EC实例的硬盘格式,Provisioned IOPS SSD具有高一致性及超低延迟的性能,专门设计用于I/O密集型操作,比如数据库。IOPS全称为Input/Output Operations Per Second,即每秒进行读写(I/O)操作的次数,用来衡量随机访问的性能。

最终用户侧:

无宕机的系统/网站: 获得更多用户并保留住他们的关键是保证网站永远可用。达到高可用性,就需要在各个层次为故障制定防备策略。亚马逊为互联网产品在各个层面,提供了防备故障的能力。例如使用“多可用区”,这样用户就会被分发到处于某个选定地区的有效实例。


如上图结构所示,www.mywebapp.com 的用户访问“区域”(region)是新加坡,使用了两个“可用区”,一个是ap-southeast-1,一个是ap-southeast-1a。当来自新加坡的用户进入 www.mywebapp.com,则系统分发这个访问请求到ap-southeast-1或者ap-southeast-1a。若是其中一个“可用区”失效,则用户请求自动转移到另一个“可用区”。当故障恢复后,用户请求再次分发到两个“可用区”。 这些动作,用户不受任何影响,甚至觉察不到。网络运营小组,也无需干涉,一切都是自动执行的。

更快的网页速度:互联网用户可能来自世界上的任何地方,必须保证网页和应用的加载是快速的。实现这个目标,最简单的方法是将互联网产品部署到靠近用户的地理位置。亚马逊在全球主要的地区都拥有多个“区”。 通过将网站托管在亚马逊 Route 53 托管区,便可以将用户访问分发到最靠近他们的区,从而保证网站的访问速度。还可以使用亚马逊 CloudFront 和 S3,对静态文件的访问进行加速。其他加速措施还包括,为 RDS,网页和应用数据增加更大的 IO 性能。

Amazon CloudFront 是由Amazon提供的一套覆盖全球的CDN网络。该服务拥有云计算服务特点,可以根据流量和请求数量进行收费,并且相对来说费用还算低廉,因此适合小型公司或个人。

Amazon Simple Storage Service (Amazon S3) 为开发人员和 IT 团队提供安全、耐久且扩展性高的云存储。Amazon S3 可轻松使用对象存储,具有简单的 Web 服务接口,可用于在 Web 上的任何位置存储和检索任意数量的数据。使用 Amazon S3,您只需按您实际使用的存储量付费。没有最低费用和准备成本。

用户数据安全:用户的业务数据非常重要,需要极致的保护,防止未经授权的访问。在选择互联网服务时,安全就成了首要考虑因素。亚马逊“安全组”(Security Groups)可以用来在系统的各个层次对访问规则进行配置。以上图的架构为例,在“Security Group: Web Servers”(安全组:web 服务器)上,可以定义规则,只允许 https/http 协议可以访问 web 服务器。在 “Security Group: App Servers”(安全组:应用服务器)上,可以定义规则,只允许自己的web 服务器,从固定的端口,用固定的协议,去访问应用服务器。同样的方法,可以去定义数据库访问策略到“Security Group: DB Access”(安全组:数据库访问)。这样一来,对资源的外部访问就被总体上定义清楚,只有满足了每个层次上的所有安全要求,才能够获得对数据的访问。 通过使用 HTTPS,也保证了数据在传输过程中的安全。

基础架构侧:

快速的服务器调配:服务器资源的高可用性,对每一 IT 公司来说,都是持久不变的追求。可用性不理想,提供给客户的服务质量就会降低。 使用 AWS EC2 实例,可以瞬间启动多个 VM 实例。而通过 AMI 设置,更进一步,可以将所需的个性化配置存在镜像里,然后通过这种镜像启动实例。带来的好处是,随时可以在流量高峰时,启动更多的 VM 实例。如果还不满足,则可以使用 Auto Scaling 服务创建“容量组”,可以随着容量需求变化而自动的增长和缩小。

Auto Scaling服务,EC2实例可以被放置在被称为Auto Scaling Group的逻辑组中,经过简单的、适当的设置,这些EC2实例将立即具备高可用性、自动横向扩展能力、定时横向扩展能力。

负载的自动分发: AWS ELB可以对来自用户的web请求,执行自动负载均衡,将请求分发到不同的web 服务器组。这样,负载平均的发送到服务器上,保证用户体验的质量。一切都是自动实现的。

简化的 IT 网络运营:实现了对资源进行自动扩张,还需要考虑整体系统的可靠性和运营能力。为了简化这个工作,亚马逊提供了 CloudWatch 功能,实现对 EC2 实例的健康状况监控。 Auto Scaling 便可以基于监控获得的数据,执行 EC2的扩张和缩减。 这就保证了快速伸缩的同时,无损服务可靠性。

Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您可以使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改。

简化的存储管理: 使用 AWS Elastic Block Store 功能管理存储卷。用户为实例创建一个持久的存储卷,这样系统重新启动后,重启的实例自动挂载正确的硬盘/存储设备。 这个特性保证了应用和系统能够访问一致的数据。

Amazon Elastic Block Store (Amazon EBS) 可在 AWS 云中提供用于 Amazon EC2 实例的持久性数据块级存储卷。每个 Amazon EBS 卷在其可用区内自动复制,以保护您免于组件故障的威胁,同时提供高可用性和持久性。

简化的数据库维护:AWS 支持几乎所有的主流数据库,包括 Oracle, MySQl, MS SQL。有了 RDS,数据库可以实现自动备份,并能够进行任意时间点的恢复。RDS 在多个可用区的部署,带来了最关键的好处是保护数据库不受意外故障的破坏。在上面的架构示意图中,选择了 "M" RDS 数据库实例作为"主/首要“数据库。 不论从那个可用区访问网站,所有的请求在数据库层次,都被分发到位于ap-southeast-1区的主数据库实例。 然后,为主数据库创建一个拷贝,配置到其他的可用区,例如ap-southeast-1a中,作为备份数据库运行。 当主数据库实例出现宕机,则系统自动切换到位于ap-southeast-1a的备份数据库。当主数据库再次恢复运行后,又可以从备份数据库切换回主数据库。如果更进一步,使用了 EBS 部署数据库文件,即便在数据库主机宕机时,还可以获得和持久的数据库文件一样的高性能。

总结:以上建议的架构中,所用的 AWS 特性及功能,完全可以帮助创业公司实现云计算,在基础架构上获得低成本、高扩展性和容错等好处。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,884评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,347评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,435评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,509评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,611评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,837评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,987评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,730评论 0 267
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,194评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,525评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,664评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,334评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,944评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,764评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,997评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,389评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,554评论 2 349

推荐阅读更多精彩内容