使用 Python 书写 AWS Lambda 的一个好处就是能够在控制台中直接编辑源代码，非常方便进行快速验证测试 AWS 环境相关的。这只限于使用 AWS 为 Python Lambda 运行时提供的默认组件(比如 boto3)，尚若需要在自己的 Python Lambda 中使用其他的组件(如 redis), 就不得不把自己的代码及依赖打成一个 zip 包再部署，这时候就无法在控制台直接编辑代码了，也只能坠入本地修改代码，重新打包上传测试的循环当中。
欲了解 Python Lambda 中除了 boto3 外还能直接使用别的什么组件，可点击此链接 https://gist.github.com/gene1wood/4a052f39490fae00e0c3 查看当前。该 gist 也还提供了代码 code to run in Lambda 来获得所有依赖。试了下在 Python Lambda 中，用通常的help('modules') # 或
竟然连大名鼎鼎的 boto3 都无法列出来。
help('modules package')
回到正题来，如果既想用第三方的依赖，又想要在控制台中直接编辑代码进行测试，是否有他法呢？有，那就是 AWS 在 2018 年 11 月推出的 Lambda 层。见 AWS Lambda Now Supports Custom Runtimes and Enables Sharing Common Code Between Functions, 这里的层除了能用来提供 Python 依赖，还许自定义运行时，如 C++ 或 Rust 等写 Lambda 都不是梦。
AWS 的服务就像个大口袋，何时偷偷的加添了什么服务，或出了什么新的我，不时关注它的 What's New with AWS 必是个好习惯。 Read More目前我们在 AWS 上把密钥，API Key 等信息是存储在 AWS Systems Manager 的 Parameter Store 中，它只提供了用 KMS Key 加密存储字符串的功能，最大字符串大小是 4096 个字符，它是免费的。
最近发现 AWS 上有一个新的服务 AWS Secrets Manager(2018 年 4 月发布的)，听起来用它来存储密钥信息更高大上些。它同样提供了用 KMS Key 加密存储字符串的功能，字符串最大也是 4096 个字符。从 AWS Web 控制台上看可配置用 Key/Value 的形式，其实本质也是存储为一个 JSON 字符串。
Secrets Manager 与 Parameter Store 更多的功能是能与 RDS 集成 -- 选择数据库收集数据库的配置信息(主机名，端口，实例等), 还有就是可配置定期更新密钥，这对一个安全的系统定期改密码很重要。对于定期更新密钥的未作深入研究，AWS Secrets Manager 本身知道如何轮换 RDS 数据库的密钥，其他的需要一个 Lambda 来支持。 Read More
- Docker 镜像在未指定仓库时默认是从 Docker Hub 拉取的。如果需向 Docker Hub 推送镜像的话还可用
docker login在交互中完成登陆 Docker Hub 的操作。docker login的命令格式是docker login [OPTIONS] [SERVER]
所以我们可以连接到任何的 Docker 镜像仓库，也可以是本机，但我们这里所要介绍的是如何推送镜像到 AWS 给我们提供的 Docker 镜像仓库(Amazon ECR - Amazon Elastic Container Registry)。每个帐号下都有自己独立的仓库，镜像推送到了 Amazon ECR 后我们能够很方便的在 ECS, Batch 服务中使用它，也可以从 ECR 拉取镜像到本地来。
首先我们来做一个运行 Spring Boot Web 的简单的 Docker 镜像，假定已用mvc pacakge生成了一个可独立运行的 jar 包java-webapp-0.0.1-SNAPSHOT.jar。该应用开启一个 Web 服务，访问 http://localhost:8080 显示一行字符串Hello World!
创建一个目录 aws-docker, 并把java-webapp-0.0.1-SNAPSHOT.jar移入该目录，在其下创建Dockerfile文件，文件目录结构如下：aws-docker
Read More
├── Dockerfile
└── java-webapp-0.0.1-SNAPSHOT.jar - 很早就想写下这篇日志的，因为实际使用 AWS S3 来存取文件使用什么样的 Key 对性能的影响是极其大的。当然，如果你对 S3 的并发请求在 50 以内是无所谓的，要是并发要求很高的话，Key 的选择就变得至关重要的，不可不察。S3 Key 从第一个字符算起的任意长度子字符串都被称作前缀(prefix), 而对 S3 文件访问性能影响不在完整的 Key, 恰恰是那个前缀。
背景：我们最初在使用 S3 时，存储的文件的 Key 直接用了数据库的自增 ID，于是保存到 Bucket 中大概下面那样子的examplebucket/12134850.csv
Bucket 中有百万个文件，当初测试时 60 个左右的 Lambda 实例同时访问这个 Bucket 中不同的文件时，加载每个 S3 文件的时间大约在几百毫秒，然后并发上到 70， 80 后加载同样大小的 S3 文件的时间陡然增加到 10 秒以上，并发继续上到 100 以上直接导致众多 S3 的请求超时。后来了解到虽然一个 Bucket 中放多少个文件是没有限制的，而且官方文档说了文件多了并不影响访问的性能，但背后却有一个文件的分区存储机制，这个才是关键。
examplebucket/12134851.csv
examplebucket/12134852.csv
examplebucket/12134853.csv
examplebucket/12134854.csv
examplebucket/12134855.csv
examplebucket/12134856.csv
examplebucket/12134857.csv
examplebucket/12134858.csv
S3 的分区存储就像是硬盘分区，或文件分布在不同硬盘上的效果。试想一下，如果我们多个线程同时从一块硬盘上读取数据，每个线程需共同一个磁头来读取数据，性能就差; 但如果那些线程同时从不同的硬盘上读取各自的数据，那性能就大大提升了，它们互不干扰。在使用机械硬盘时我有过这样的体验，在同一个磁盘上拷贝文件比从一个磁盘拷贝到另一个磁盘要慢很多。 Read More