【总结】初创公司用AWS搭建高扩展性架构

下载地址：完整mp4视频

演讲人：张侠 博士

1. 邱洋的理解

初创公司需要快、多、好、省的技术架构

快：针对业务需要可以快速获得资源与服务

多：拥有丰富的云服务可供选择，能不自己做就不自己做

好：强调扩展性和高可用，既不要在一开始被“钱”束缚住，又需要良好的用户体验（能用是最基本的用户需求）

省：可以弹性伸缩，并按需付费是最好的节省

无论是初创公司还是传统企业，很多架构思路是相通的： OS、前端、后端、数据库、框架等，根据自身需要选择。之后要做的就是在云中找到对应的服务功能。

云应用架构的7大设计原则

设计时考虑任何系统都会失效

松耦合和无状态设计（只有无状态的应用才能更好的快速伸缩）

设计可扩展性和自动缩放

安全贯穿设计始终，体现在每层中

不要过多担心约束和失败（比如每次处理的能力还不够多，要做到的是清晰的了解当前的设计思路，因为云是无限扩展的，所以干好一件事情后云中可以通过复制而扩展能力）

多考虑平行分布式处理

充分使用各种不同的服务

初创公司可以按照如下方法渐进式使用云服务

按业务生命周期方法：从测试开始熟悉操作，再到后续生产部署，逐步习惯云服务

按应用规模变化方法：从一台EC2实例开始，再根据业务发展引入静态数据分离，关系数据库扩展，缓存等需求，逐步了解更多云服务

按业务需要方法：从基础的计算/存储/网络等IaaS服务开始，在逐步根据业务将消息队列、全文搜索、邮件发送等直接使用PaaS服务，逐步将精力放入业务创新

2. 初创公司提的业务和技术要求

快速验证产品服务

为机会窗口而争分夺秒（互联网1年等于传统7年，狗年）

小的技术团队没有历史包袱

关注于提供方案解决问题

避免工程大而全和返工

规避风险准备迎接高速成长

3. 初创公司的技术选型

3.1. 常见技术堆栈

操作系统：linux：centos，redhat，suse，ubuntu

移动端：IOS、Android；HTML5

网站前端：PHP/ASP/JSP、HTML/CSS

前端框架：Flex，jQuery，Sencha

开发工具：Eclipse，SVN，SDK/IDE

技术框架：Struts，Springs，Hibernate；Velocity；Ruby on Rails

开发语言：Java，PHP，Python，Ruby，Net，Node.js，GO

负载均衡：软件：Nginx，Squid；硬件：F5，Citrix Netscaler

数据库：RDB：MySQL；NoSQL：MangoDB

缓存：Memcached ，Redis

内容发布：CDN，DNS

其他：Lucene（全文检索工具）

3.2. 架构的考虑

高性能

高可用

可扩展性

支持客户、业务、访问、和数据的高速成长

难于规划，成长无上限

扩展时性能不能受影响

无缝：只需平滑的增加资源

高效：维护每个用户的低成本

安全性

便于管理

成本可控

快速交付

3.3. AWS服务的解决方案

敏捷、快速、灵活

低启动成本、随用随付费

不再需要猜测容量

集中精力创新

摆脱无差异化的体力活

数分钟就可以全球化部署

IT整体成本降低

3.4. 云架构设计的7大建议原则

设计时考虑任何系统都会失效

松耦合和无状态设计（只有无状态的应用才能更好的快速伸缩）

设计可扩展性和自动缩放

安全贯穿设计始终，体现在每层中

不要过多担心约束和失败（比如每次处理的能力还不够多，要做到的是清晰的了解当前的设计思路，因为云是无限扩展的，所以干好一件事情后云中可以通过复制而扩展能力）

多考虑平行分布式处理

充分使用各种不同的服务

4. 六天完成初创公司的技术架构设计

4.1. 第1天，开发和私测

首台服务器（从云中启动一个vm开始）

通过云中的EC2实例来进行测试（运行诸如apache、mysql等）

可以部署多台来分角色，因为刚开张，先从1台vm开始

为服务器绑定IP地址，（限制：每个账户可以有5个Elastic IP地址）

设置DNS域名来指向Elastic IP

4.2. 第2天，推出和公测

要测试了，当初的vm不够用，需要更大的服务

加大块存储容量（EBS）

使用正确的虚拟机类型（如cpu核多、内存多、GPU卡、硬盘读写速度快等）

按需改变虚拟机大小

了解方案为长期永久，具有过渡性（目标是了解AWS中的各种操作、限制和性能方案）

还没有容错设计

分开网站应用和数据层

更多容量

每层分别扩展

细调每层的实例

实例类型

存储

注重安全

使用防火墙

数据库至于VPC私有子网

如何选择数据库？SQL or NoSQL？

为什么通常使用关系型数据库？

SQL非常成熟，功能丰富

许多现成的代码、工具和知识

扩展设计思路明确发发可行

例如：对频繁读取的apps，采用读写分离

现实：未来将逐渐使用多种数据库

有些工作负载使用NoSQL更合适

为每项工作选择合适的工具

经验分享：关系型数据库很复杂

关系型数据库要实现高可扩展性，管理运营起来往往很困难

管理不善的关系型数据库，会造成：数据不匹配和IT系统宕机下线的原因

针对初创企业团队小，人员少在兼职，尤为如此

AWS提供托管的关系型数据库

MySQL、Aurora、PostgreSQL、Oracle、SQL Server



如何进一步提升效率？

部署静态内容—Amazon S3

高可用性、易扩展的对象存储

任何格式的静态文件（javascript，CSS，images，videos）

用户可以直接上传

S3 URLs 可以从S3直接提供

让网站服务器集中处理动态内容

缓存这些静态内容—Amazon CloudFront

全世界分布的边缘站点

在边缘站点提供缓存

– 减少延迟 Reduce latency

– 减轻原始服务器的负载

– 静态和动态内容

更少的时间缓存大量热点数据

优化连接

– 优化连接路径

– 重复使用连接

– 对不能缓存的内容也有帮助（减轻负担）



数据库缓存—Amazon Elastic Cache

从内存读取速度更快

减少数据库的工作负载

部署简单

完全托管（自动替换失效节点、负责升级补丁管理）

好的弹性扩展

兼容性（支持memcache，redis）

4.3. 第3天，客户上线

高可用性被摆上台面

第2天的情况是：动态内容在EC2实例中，静态放入S3，用CloudFront加速，用RDS托管数据库，并且用ElasitcCache缓存

今天，继续在第2天的基础上，在另一个AZ（可用区）中创建EC2保存动态内容，并且用ELB负载均衡来进行跳转

ELB是托管的负载均衡服务

容错

健康检查

分布在多个可用区

弹性-自动扩展容量

开启RDS的muti-AZ，这样RDS具备高可用了

在另一个AZ（可用区）再创建一个ElasticCache的实例



用户访问的User Session问题

问题：状态通常存于本地磁盘（没有共享）

简单解决：ELB Session stickiness（session绑定）

更好方案：DynamoDB（将session状态保存在NoSQL数据库中）

DynamoDB是托管的文件和KEY-VALUE存储

易启动，易扩展

到百万IOPS

读和写

一致、快速的性能

持久性：特别适合存储session data

4.4. 第4天，让我们病毒式成长

目标：使用弹性IT代替猜测计算容量



使用自动缩放能力（三剑客：CW、AS、ELB）



微服务化/SOA化

将应用分解许多成小的、功能单一的、松耦合的、无状态的构建单元

只在实例存储上保存暂时的数据

只要超过单一http调用的数据均需持久保存，然后存储



这样就可以做到按需进行弹性伸缩了



这样的结构虽然简单，但你仍需

配置具体参数

将代码部署到多个实例

管理开发测试生产多个环境（Dev，Test，Prod）

维护应用的多个版本

解决方案：使用Elastic Beanstalk

容易部署、监控和扩展的三层web、应用、数据库架构

基础架构由Beanstalk管理和部署

客户仍然掌控

预配置应用容器

容易更改配置

支持下述平台



如果系统更复杂一些，可以使用SQS实现松耦合

将任务部署到队列服务

SQS通过队列为后端系统提供缓冲

异步处理-自己把握节奏

移除关键路径的延迟

4.5. 第5天，增加更多功能

AWS拥有更多的服务，你可以根据需要选择



AWS服务的关于高扩展和高扩展性的服务

本身可以扩展和高可用	与合适的架构配合实现可扩展和高可用
ElasticLoadBalancing	EC2（本身不是高可用，而是在部署在多个AZ中后，可以实现一个高可用架构）
CloudFront	VPC
Route53
S3
SQS
SES
CloudSearch
Lambda
…

在扩大团队时保持对创新的关注

4.6. 第6天，继续快速成长

数据太大了，需要扩展关系型数据库

增强RDS实例

大的实例类型

更多存储/更多IOPS

只读副本read replca（主master—从slave）

扩展到超度单一DB实例的计算容量

对RDS for MySQL、PostgreSQL 和 Aurora适用

【写】=>主 master

复制有延迟

能容忍过期数据的【读】=>只读副本（从）read replca（slave）

高一致性的【读】=>主master

如果需要经常写？

挑战：你迟早会达到主节点写操作或存储的极限

方案1：联合Fedration（根据数据功能分到多个数据库上）

将数据库表分成多个小的自立的数据库

跨功能函数查询很困难

对于单一较大的函数、表的帮助不大



方案2：分片Sharding（将一组数据分道多台主机上）

将行的子集存入数据库分片（大数据领域很常用）

应用层面更复杂

扩展性实际上无上限

运营的复杂性



另一种解决方案，NoSQL数据存储—DynamoDB

牺牲关系数据库的查询和性能，以获取

更灵活的数据模型

水平伸缩可以预测的性能

可以大规模无缝扩展

分布式系统可以对读写均实现扩展

切片 + 复制

自动分区

数据大小增加

增加预设容量

5. 总结

无用户数上限的架构

应用层面做了自动伸缩

数据层面做了多AZ部署

使用了缓存

使用了读写分离、跨区部署的关系数据库

用S3存动态内容

用DynamoDB存非结构数据

SNS、SQS、CloudSearch解决业务需要

…



初创公司AWS架构原则

保持简洁和无状态

多使用托管的自动缩放的服务

将EC2实例置于多可用区的自动缩放组内

选择合适的数据库类型

在多个层次巧用缓存

使用管理工具自动化部署