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

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

1. 邱洋的理解

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

  • 快：针对业务需要可以快速获得资源与服务
  • 多：拥有丰富的云服务可供选择，能不自己做就不自己做
  • 好：强调扩展性和高可用，既不要在一开始被“钱”束缚住，又需要良好的用户体验（能用是最基本的用户需求）
  • 省：可以弹性伸缩，并按需付费是最好的节省

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

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

  1. 设计时考虑任何系统都会失效
  2. 松耦合和无状态设计（只有无状态的应用才能更好的快速伸缩）
  3. 设计可扩展性和自动缩放
  4. 安全贯穿设计始终，体现在每层中
  5. 不要过多担心约束和失败（比如每次处理的能力还不够多，要做到的是清晰的了解当前的设计思路，因为云是无限扩展的，所以干好一件事情后云中可以通过复制而扩展能力）
  6. 多考虑平行分布式处理
  7. 充分使用各种不同的服务

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

  • 按业务生命周期方法：从测试开始熟悉操作，再到后续生产部署，逐步习惯云服务
  • 按应用规模变化方法：从一台EC2实例开始，再根据业务发展引入静态数据分离，关系数据库扩展，缓存等需求，逐步了解更多云服务
  • 按业务需要方法：从基础的计算/存储/网络等IaaS服务开始，在逐步根据业务将消息队列、全文搜索、邮件发送等直接使用PaaS服务，逐步将精力放入业务创新

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

• 快速验证产品服务
• 为机会窗口而争分夺秒（互联网1年等于传统7年，狗年）
• 小的技术团队没有历史包袱
• 关注于提供方案解决问题
• 避免工程大而全和返工
• 规避风险准备迎接高速成长

3. 初创公司的技术选型

3.1. 常见技术堆栈

1. 操作系统：linux：centos，redhat，suse，ubuntu
2. 移动端：IOS、Android；HTML5
3. 网站前端：PHP/ASP/JSP、HTML/CSS
4. 前端框架：Flex，jQuery，Sencha
5. 开发工具：Eclipse，SVN，SDK/IDE
6. 技术框架：Struts，Springs，Hibernate；Velocity；Ruby on Rails
7. 开发语言：Java，PHP，Python，Ruby，Net，Node.js，GO
8. 负载均衡：软件：Nginx，Squid；硬件：F5，Citrix Netscaler
9. 数据库：RDB：MySQL；NoSQL：MangoDB
10. 缓存：Memcached ，Redis
11. 内容发布：CDN，DNS
12. 其他：Lucene（全文检索工具）

3.2. 架构的考虑

• 高性能
• 高可用
• 可扩展性
  
  • 支持客户、业务、访问、和数据的高速成长
  • 难于规划，成长无上限
  • 扩展时性能不能受影响
  • 无缝：只需平滑的增加资源
  • 高效：维护每个用户的低成本
• 安全性
• 便于管理
• 成本可控
• 快速交付

3.3. AWS服务的解决方案

• 敏捷、快速、灵活
• 低启动成本、随用随付费
• 不再需要猜测容量
• 集中精力创新
• 摆脱无差异化的体力活
• 数分钟就可以全球化部署
• IT整体成本降低

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

1. 设计时考虑任何系统都会失效
2. 松耦合和无状态设计（只有无状态的应用才能更好的快速伸缩）
3. 设计可扩展性和自动缩放
4. 安全贯穿设计始终，体现在每层中
5. 不要过多担心约束和失败（比如每次处理的能力还不够多，要做到的是清晰的了解当前的设计思路，因为云是无限扩展的，所以干好一件事情后云中可以通过复制而扩展能力）
6. 多考虑平行分布式处理
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服务的关于高扩展和高扩展性的服务

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

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实例置于多可用区的自动缩放组内
• 选择合适的数据库类型
• 在多个层次巧用缓存
• 使用管理工具自动化部署