前言

1.相关概念

1.1 部署方式

1. 压缩包 即将源码和其依赖的第三方包都压缩在一个Zip包中，并将该包上传至Lambda计算平台上。

   其中有几点需要注意:

   1. 需要把编程语言所依赖的第三方库放入压缩包中。具体的存放方式请查看官方文档。
   2. 若Lambda的项目结构与官方默认结构不同，则还需要修改Lambda入口方法的相关配置。即在Lambda控制台上的运行时设置中，将处理程序更改为<处理程序函数所在的文件名称>.<入口方法函数名>。

2. 容器 即将源码和其依赖的第三方包都打进一个容器镜像中，并将该容器镜像上传至Amazon ECR容器镜像仓库。 不同编程语言构建容器的方式详情请查看官方文档。AWS同时也提供了的各类编程语言基础镜像的下载。

1. 按需修改Lambda的超时时间。如果Lambda的超时时间过长和过短都有可能会导致出现异常情况。
2. 为Lambda配置VPC。如果Lambda需要通过网络访问AWS中的其他资源(例如EC2)，则需要为其配置所属VPC。VPC子网以及安全组的配置与EC2配置方法相同，按需配置即可。
3. 调整事件的最长保留时间。由于Lambda是基于事件驱动的方式运行的，用于触发的事件的保留时间如果不合理，则可能会导致Lambda遗漏请求等问题的发生。
4. 调整重试次数。可以通过Lambda平台提供的重试机制来实现业务功能的重试功能。这里需要注意实现的Lambda是否支持幂等性以及其内部是否已经实现了重试机制。
5. 启用死信队列。死信队列可以用来保存那些无法被Lambda所执行的事件(请求)。这些请求可以在后续中被用来做故障分析以及自动化处理异常请求的数据源。
6. 为其分配IAM权限。如果Lambda需要调用或访问AWS的其他功能服务，可以通过为其配置相应的IAM即可。

1.2 调试方式

1. 压缩包 由于Lambda的实现方式实际上就是在编写方法(函数)，类似于使用面向过程的方式去编写脚本。若方法(函数)中没有涉及到调用其他Lambda的逻辑，则可以通过在本地以Debug方法(函数)的形式进行调试。 其中，如果有涉及到调用AWS的相关服务，可以通过为SDK Client或API提供access key和secret_access_key来进行授权访问调用。这里需要注意一点，在正式部署之前应将关于配置认证信息的代码段删除，因为Lambda在运行时可以通过在其绑定的IAM中获取到相应的服务访问权限。这也是Lambda的优势之一，即无需将重要的账号认证信息明文暴露在编码或配置文件中。 其次，如果有调用其他自研服务的需求，则可以通过在本地搭建这些服务或直接调用相应测试环境的服务即可。 最后，通过模拟构造Lambda入口方法(函数)的入参，即可对其进行本地调试。

Tips: 这里所说的类似于编写脚本，只是便于为了让读者更好理解Lambda编码的特点。而不是指Lambda只能使用面向过程的方式去编写。实际上Lambda也可以使用面向对象的方式去编写，Lambda编码的特点在于开发者无需在去实现底层功能框架的代码逻辑，而是直接编写业务逻辑代码即可。

2. 容器 AWS提供的基本镜像包括中Lambda运行时接口模拟器，因此是可以在本地测试Lambda的。 相关操作例如:
   1. 运行Docker映像。从项目目录中，运行docker run 命令：
   # docker run -p 9000:8080 hello-world:latest
   2. 测试Lambda函数。在新的终端窗口中，运行curl命令来调用函数：
   # curl -XPOST "http://localhost:9000/2015-03-31/functions/function/invocations" -d '{}'

   Tips: 接口模拟器下载

1.3 调用方式

1.3.1 原理

1.3.2 同步调用

1.3.3 异步调用

2.实现思路

2.1 面向对象设计的使用

Tips: 当使用该思路设计和编写Lambda时，笔者想提醒大家注意以下几点:

1. 无需过度工程化 面向对象设计通常会用来编写复杂的项目或功能框架。例如会对需求进行深层分析并抽象出底层抽象类，并使用继承或者组合的方式来设计不同类之间的关系等等。而笔者这里想提醒大家注意一个关键点，就是无服务化(Serverless)的核心概念: 无服务化(Serverless)希望我们可以将功能需求拆分的更加细致，将每一个子功能实现为一个基本单元并对外提供服务。因此，在使用面向对象设计Lambda时，应当注意Lambda中所实现的相关逻辑是否过于复杂，抽象或引入的类是否过多。如果出现这种情况，笔者建议应考虑将当前功能需求再次细分，即将当前Lambda拆分为多个Lambda，然后通过链式调用或异步服务调用的方式来将这些Lambda组合起来使用。遵循以从简原则使用面向对象的方式去编写代码即可。

2. 功能类复用方式 引入面向对象设计后，我们可以将经常会使用到的一些功能封装为基础功能类。而这些功能类可能会在多个Lambda中都使用到。这种复用需求，在不同的部署方式有着不同的实现思路。若使用容器进行部署，需要将功能类源码拷贝到多个Lambda中。若使用Zip包部署，则有两种方式。一是类似于容器部署，将功能类源码拷贝到多个Lambda中；二是可以利用Lambda的Layer功能，将这些功能类都制作为Lambda的Layer。后续在实现Lambda时，代码依旧编写引入这些类的相关逻辑，但无需在Lambda工程结构中加入这些类的源码文件。只需在部署配置Lambda时，指定Lambda使用这些Layer即可。

3. 抉择 这里笔者所说的抉择指的是：什么时候使用面向过程设计？什么时候使用面向对象设计？ 对于这个问题，笔者提供一些思路供大家参考。面向过程设计更适合那些简单的业务逻辑，例如创建云主机，采集日志数据，变更指定数据等等。像这些能够通过封装少数方法(函数)就可以快速实现的逻辑，可以优先选择使用面向过程设计来实现。而面向对象设计适合的业务场景有以下几个特点: 1.相对复杂的业务需求;2.若该业务需求灵活多变，需要Lambda能够快速支持;3. Lambda可能会有多个人同时负责开发和维护。如果业务场景有上述的特点，可以优先考虑使用面向对象设计来实现。

2.2 日志打印

2.3 异常处理

2.4 权限配置

Tips: 对于配置AWS IAM，笔者这里想分享给大家一些实践的经验。了解和配置过AWS IAM的人应该都清楚其中的痛点，由于AWS对于其服务操作权限的划分过于细致，会导致在配置IAM时会因不熟悉服务的权限划分而出现权限遗漏现象，从而导致Lambda因权限不足而无法正常运行。针对上述问题，笔者这里推荐给大家几个解决该问题的思路:

1. 开Case 解铃还需系铃人，直接询问AWS的专业工程师是最快也是直接的方法。通过在Case中描述清楚你的Lambda都需要那些服务的操作权限，AWS会将Case指向专业处理Lambda的工程师们。他们对于Lambda的熟悉程度是高于我们的，因此可以他们的帮助来快速解决这个问题。同时这也是合理利用云厂商提供的便利服务的一种体现。

2. 善用控制台的提示 现阶段，在AWS IAM的控制台进行相关配置时，系统会自动把某个权限所需的其他必备权限罗列出来。因此在配置时，需留意将系统提供的这些必要权限加上。

3. 被动查找 所谓的被动查找，实际上是指在不绑定任何AWS IAM的情况下，直接运行Lambda。这时Lambda一定会因为没有某些服务的操作权限而报错(前提是正确记录了这些异常)，此时就可以根据返回的这些错误信息来为Lambda添加所需的权限了。这种方法的弊端在于效率极低，调试Lambda的次数会随着Lambda中所涉及到的服务调用的数量而增多；而优势在于这样的做法能够产出一个最小需求的权限集合，以此能够保证Lambda指定的操作不会越界。

2.5 数据落地

2.6 提供Web Service

1. 结合AWS API Gateway 通过和AWS API Gateway服务结合使用，可以为Lambda提供创建、发布、维护、监控和保护任意规模的REST、HTTP和WebSocket API。
2. 内置HTTPS终端节点 通过使用Lambda的内置HTTPS终端节点功能，也可以使Lambda对外能够提供Web Service。

总结

1. 与公司的成本控制和业务发展结合度高 在无服务化(Serverless)的实践中，更多的人力可以用于去实现业务逻辑，而不再像微服务化时需要有专业的团队专注于设计和实现底层框架。这大大能够节省公司的人力成本，而且使得研发团队能更够专注于业务上的功能开发。
2. 减少开发成本 使用无服务化(Serverless)后，开发人员不用再考虑底层框架的相关实现。这一点笔者深有体会，平常在实现新工程时，我们需要先将底层框架实现好，然后在其上实现业务逻辑。即使能够通过拷贝原有工程的底层框架部分，但拷贝后的细节配置更改依旧会消耗时间和精力。但这些问题在无服务化(Serverless)中就不复存在了，开发人员从一开始就可以直接针对业务需求进行设计和研发，无需再花费时间去搭建，对接底层框架。