使用AWS时遇到的那些坑

之前在Amazon实习XD也算是免费体验了Amazon AWS的全套产品XD

应该也算是很宝贵的经验了噗哈哈哈~毕竟AWS还不是我这种学生消费得起的

趁着刚刚离职还热乎着的时候，把所遇到的一些坑都先记录下来把ww

万一有人要用到AWS呢~

任务描述

当时的任务是借助AWS搭起来一个小程序的后端，很简单对不对ww但是AWS就是在其中创造了数不胜数的坑

接下来我们从后端管理的源头——数据库开始，一点一点梳理我在这几个月来遇到的坑

后端数据库

RDS

在后端数据库的选择上，最开始还是希望能按照传统的SQL数据库的方式进行后端数据的操作（毕竟是迁移，省一点事是一点事）

AWS的RDS也确实比较给力，基本完成了自己想要的功能，相关的访问权限什么的也比较容易管理

但是！就是！太他妈贵了啊！一看费用账单全是RDS的费用惊

即使是最小的数据库配置也死贵的 家里没矿不要用鸭哭QAQ

Dynamodb

这个时候Amazon自研的Dynamodb就要华丽出场啦ww

Dynamodb是“一个键/值和文档数据库，可以在任何规模的环境中提供个位数的毫秒级性能。它是一个完全托管的多区域多主数据库，具有适用于 Internet 规模的应用程序的内置安全性、备份和恢复和内存缓存。DynamoDB 每天可处理超过 10 万亿个请求，并支持每秒超过 2000 万个请求的峰值。”——来自官网的xjb吹

我来翻译一下，就是这是一个NoSQL的，键值存储的分布式数据库（而且价格还可以）

但是！注意！这货是键-值型NoSQL数据库！

键值数据库不支持JOIN和两键以上多键查询！ 键值数据库不支持JOIN和两键以上多键查询！ 键值数据库不支持JOIN和两键以上多键查询！

给我他娘的记住咯QAQ即使是两键或非主键查询，也是要通过新建子查询的方式（也就是另交钱）来进行。

而且因为是键值型，很多相关的前端业务逻辑和接口都需要重新定义（或者你也可以靠一副好肝在后端重写）

后端Handler

Elastic Beanstalk

最开始所想到的是AWS的Elastic Beanstalk服务，因为这是一个直接封装了应用程式和运行环境的工具，只要上传代码就可以访问到相关服务，听起来相当便捷了。

但是在我国，这套服务的最大痛点是：无法提供HTTPS 备案的环境，而微信接口要求接口域名必须要HTTPS 备案的环境才可以使用

和AWS再三确认过了，Elastic Beanstalk暂时（2018年12月）无法提供443端口的开放orz

于是这套计划也成功破产，当然迁移当时也因为这个pending了两个月

Api-Gateway Lambda

先说Lambda，这个服务的功能还是蛮强大的，提供多种编程语言的直接运行诸如Nodejs, Python的环境（但是没有世界上最好的语言PHP），只要上传代码就可以进行相关操作（这样听起来有点像EB，当然事实上在分类的时候他们也是被Amazon分在同一类的）

但是重点是：Lambda似乎不支持操作RDS，在技术选型的时候需要谨慎考察一下

我所实验过的是至少Lambda支持Dynamodb和S3，但是RDS似乎没有找到

再说Api-Gateway，这个服务提供了统一的对外API接口，通过这个接口连接到Lambda，就可以对用户的请求进行响应。

Api-Gateway由于是网关层，重点依旧是在备案上，Amazon内部是可以通过直接进行备案Exception的申请来实现备案的，其他公司接入的如何进行备案就不是很了解了。

总之备案过了之后Api-Gateway才会开放，之前不要怪人家总返回502（在这里试了很久直到问了AWS的人）

至于怎么将两者连接，可以直接在Lambda中选择蓝图（blueprint）进行模板式的创建，这样会自动生成一个相连接的Api-Gateway，还是比较便利的

最终

最终还是在离职之前完成了这个任务，总体的后端架构就是 Api-Gateway Lambda Dynamodb，和团队预算也比较相合，另外也可以成功跑起来并减少了层与层之间的耦合，还是比较舒服的。

总体来说最开始虽然吐槽AWS吐槽的很厉害，但后期其实觉得AWS还是一套比较强大的云管理工具，方案其实也比自己想想的要成熟的多，也无愧其现在市场占有率第一的位置，适应了之后就会越用越顺手。

至于更多的，关于云到底能做写什么，我想换一篇文章再说，在这里说就扯多了ww

科技改变生活ww

这篇好文章是转载于：学新通技术网