2019.03.10 | Else | 1 条评论


之前在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

标签: 文章, 微信, PHP, 域名, 代码, aws, 数据库, lambda, rds, 键值

2

只有一条评论 QAQ

  1. idealclover
    idealclover 回复

    实验评论ww