aws s3仅允许cloudfront访问_初创公司如何用AWS搭建高扩展性架构

‍‍‍‍

亚信云天的理解

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

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

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

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

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

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

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

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

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

o 设计可扩展性和自动缩放

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

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

o 多考虑平行分布式处理

o 充分使用各种不同的服务

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

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

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

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

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

• 快速验证产品服务

• 为机会窗口而争分夺秒(互联网1年等于传统7年)

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

• 关注于提供方案解决问题

• 避免工程大而全和返工

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

初创公司的技术选型

一、常见技术堆栈

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(全文检索工具)

 二、架构的考虑 • 高性能 • 高可用 • 可扩展性     o 支持客户、业务、访问、和数据的高速成长     o 难于规划，成长无上限     o 扩展时性能不能受影响     o 无缝：只需平滑的增加资源     o 高效：维护每个用户的低成本 • 安全性 • 便于管理 • 成本可控 • 快速交付 三、AWS服务的解决方案 • 敏捷、快速、灵活 • 低启动成本、随用随付费 • 不再需要猜测容量 • 集中精力创新 • 摆脱无差异化的体力活 • 数分钟就可以全球化部署 • IT整体成本降低 六天完成初创公司的技术架构设计 一、第1天，开发和私测 首台服务器(从云中启动一个vm开始) • 通过云中的EC2实例来进行测试(运行诸如apache、mysql等) • 可以部署多台来分角色，因为刚开张，先从1台vm开始 • 为服务器绑定IP地址，(限制：每个账户可以有5个Elastic IP地址) • 设置DNS域名来指向Elastic IP

二、第2天，推出和公测 1、要测试了，当初的vm不够用，需要更大的服务 • 加大块存储容量(EBS) • 使用正确的虚拟机类型(如cpu核多、内存多、GPU卡、硬盘读写速度快等) • 按需改变虚拟机大小 • 了解方案为长期永久，具有过渡性(目标是了解AWS中的各种操作、限制和性能方案) • 还没有容错设计 2、分开网站应用和数据层 • 更多容量 • 每层分别扩展 • 细调每层的实例       o 实例类型       o 存储 • 注重安全      o 使用防火墙      o 数据库至于VPC私有子网 3、如何选择数据库？SQL or NoSQL？ 为什么通常使用关系型数据库？ • SQL非常成熟，功能丰富 • 许多现成的代码、工具和知识 • 扩展设计思路明确发发可行       o 例如：对频繁读取的apps，采用读写分离 • 现实：未来将逐渐使用多种数据库       o 有些工作负载使用NoSQL更合适       o 为每项工作选择合适的工具 4、经验分享：关系型数据库很复杂 • 关系型数据库要实现高可扩展性，管理运营起来往往很困难 • 管理不善的关系型数据库，会造成：数据不匹配和IT系统宕机下线的原因 • 针对初创企业团队小，人员少在兼职，尤为如此 AWS提供托管的关系型数据库MySQL、Aurora、PostgreSQL、Oracle、SQL Server

5、如何进一步提升效率？ • 部署静态内容—Amazon S3        o 高可用性、易扩展的对象存储        o 任何格式的静态文件(javascript，CSS，images，videos)        o 用户可以直接上传        o S3 URLs 可以从S3直接提供        o 让网站服务器集中处理动态内容 • 缓存这些静态内容—Amazon CloudFront        o 全世界分布的边缘站点       o 在边缘站点提供缓存 – 减少延迟 Reduce latency – 减轻原始服务器的负载 – 静态和动态内容        o 更少的时间缓存大量热点数据        o 优化连接 – 优化连接路径 – 重复使用连接 – 对不能缓存的内容也有帮助(减轻负担)

• 数据库缓存—Amazon Elastic Cache        o 从内存读取速度更快        o 减少数据库的工作负载        o 部署简单        o 完全托管(自动替换失效节点、负责升级补丁管理)        o 好的弹性扩展        o 兼容性(支持memcache，redis)

三、 第3天，客户上线 1、高可用性被摆上台面 • 第2天的情况是：动态内容在EC2实例中，静态放入S3，用CloudFront加速，用RDS托管数据库，并且用ElasitcCache缓存 • 今天，继续在第2天的基础上，在另一个AZ(可用区)中创建EC2保存动态内容，并且用ELB负载均衡来进行跳转 o ELB是托管的负载均衡服务 o 容错 o 健康检查 o 分布在多个可用区 o 弹性-自动扩展容量 • 开启RDS的muti-AZ，这样RDS具备高可用了 • 在另一个AZ(可用区)再创建一个ElasticCache的实例

2、用户访问的User Session问题

• 问题：状态通常存于本地磁盘(没有共享)

• 简单解决：ELB Session stickiness(session绑定)

• 更好方案：DynamoDB(将session状态保存在NoSQL数据库中)

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

       o 易启动，易扩展

       o 到百万IOPS

       o 读和写

       o 一致、快速的性能

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

四、第4天，让我们病毒式成长

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

2、使用自动缩放能力(三剑客：CW、AS、ELB)

3、微服务化/SOA化 

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

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

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

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

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

       o 配置具体参数

       o 将代码部署到多个实例

       o 管理开发测试生产多个环境(Dev，Test，Prod)

       o 维护应用的多个版本

解决方案：使用Elastic Beanstalk

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

• 基础架构由Beanstalk管理和部署

• 客户仍然掌控

• 预配置应用容器

• 容易更改配置

• 支持下述平台

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

• 将任务部署到队列服务

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

• 异步处理-自己把握节奏

• 移除关键路径的延迟

五、第5天，增加更多功能

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

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

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

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

六、第6天，继续快速成长

数据太大了，需要扩展关系型数据库增强RDS实例

• 大的实例类型

• 更多存储/更多IOPS

• 只读副本read replca(主master—从slave)

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

o 对RDS for MySQL、PostgreSQL 和 Aurora适用

o 【写】=>主 master

o 复制有延迟

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

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

如果需要经常写？

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

• 方案1：联合Fedration(根据数据功能分到多个数据库上)

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

o 跨功能函数查询很困难

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

• 方案2：分片Sharding(将一组数据分道多台主机上)

o 将行的子集存入数据库分片(大数据领域很常用)

o 应用层面更复杂

o 扩展性实际上无上限

o 运营的复杂性

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

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

      o 更灵活的数据模型

      o 水平伸缩可以预测的性能

• 可以大规模无缝扩展

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

      o 切片 + 复制

• 自动分区

      o 数据大小增加

      o 增加预设容量

总结

1、无用户数上限的架构

• 应用层面做了自动伸缩

• 数据层面做了多AZ部署

• 使用了缓存

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

• 用S3存动态内容

• 用DynamoDB存非结构数据

• SNS、SQS、CloudSearch解决业务需要

• …

2、初创公司AWS架构原则

• 保持简洁和无状态

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

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

• 选择合适的数据库类型

• 在多个层次巧用缓存

• 使用管理工具自动化部署

‍