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

下载地址：完整mp4视频
演讲人：张侠博士

1. 邱洋的理解

初创公司需要快、多、好、省的技术架构
- 快：针对业务需要可以快速获得资源与服务
- 多：拥有丰富的云服务可供选择，能不自己做就不自己做
- 好：强调扩展性和高可用，既不要在一开始被“钱”束缚住，又需要良好的用户体验（能用是最基本的用户需求）
- 省：可以弹性伸缩，并按需付费是最好的节省
无论是初创公司还是传统企业，很多架构思路是相通的： OS、前端、后端、数据库、框架等，根据自身需要选择。之后要做的就是在云中找到对应的服务功能。
云应用架构的7大设计原则
1. 设计时考虑任何系统都会失效
2. 松耦合和无状态设计（只有无状态的应用才能更好的快速伸缩）
3. 设计可扩展性和自动缩放
4. 安全贯穿设计始终，体现在每层中
5. 不要过多担心约束和失败（比如每次处理的能力还不够多，要做到的是清晰的了解当前的设计思路，因为云是无限扩展的，所以干好一件事情后云中可以通过复制而扩展能力）
6. 多考虑平行分布式处理
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实例置于多可用区的自动缩放组内
选择合适的数据库类型
在多个层次巧用缓存
使用管理工具自动化部署