AWS Lambda从入门到精通
Amazon发布AWS Lambda服务，云计算的抽象层次被进一步提升了，这项创新的服务允许开发者把一组函数打包发布，然后由AWS平台来负责具体的管理和执行。在这种情况下，人们不再需要主动管理依赖的基础框架和操作系统，也无需处理运行阶段所面临的高可用性和可扩展性问题。每一个函数都有属于自己的安全配置，这些配置可以借助Amazon Web Services（AWS）的标准安全功能，设定函数的执行范围和对资源的访问权限。
介绍
AWS Lambda采取了一种新颖的计费方式，因为它能为用户更加高效实用地调用底层资源。在AWS Lambda环境下，计费的方式是：
·根据函数被调用的次数。
·全部调用的累计执行时间（以100毫秒为单位）。
执行时间的计费和内存的使用量呈线性关系，如果把内存容量加倍，但是保证函数执行的时间不变，对应的费用也将随之加倍。为了让用户有更好的学习和实际操作体验，AWS Lambda的免费资源包（Free Tier）允许用户免费使用一定数量的资源，每月免费资源包的限额是：
·不超过100万次函数调用。
·以1GB内存容量为基准的首个40万秒执行时间。
如果选择较小的内存容量，则可以获得更多的免费执行时间。例如，如果选择128MB（1GB的八分之一）的内存容量，那么AWS Lambda提供的免费执行时间可以长达320万秒（40万秒的八倍）。更直观地说，AWS Lambda每个月可以提供从40万秒（111小时或4.6天）到320万秒（889小时或大约37天）的免费执行时间，具体取决于用户为函数选择的内存容量。
调用AWS Lambda的函数
在调用AWS Lambda的函数时，需要在输入中提供一个事件（event）和一个上下文（context）对象：
·事件是函数获得输入参数的一种方法，通常采用JSON格式。
·上下文对象用来描述执行环境的有关信息以及事件是如何被接收并处理的，类似于传统操作系统的环境变量。
函数可以被同步调用并立刻返回结果）。我们使用同步（synchronous）这个词来表述这类函数调用方式，但是在例如“AWS Lambda API参考文档”或“AWS命令行文档”这些在线文档中，这种调用方式也被称为请求响应（RequestResponse）式调用。
请求响应（RequestResponse）式调用
采用请求响应的同步方式
采用请求响应的同步方式调用AWS Lambda函数，函数收到包括事件和上下文对象的输入信息，执行完毕后立刻返回结果函数同样可以被异步调用。在这种情况下，函数被调用后开始执行，同时立刻返回，并不会输出任何返回值（见图1-3）。我们使用异步（asynchronous）这个词来表述这类函数调用方式，但是在例如“AWS Lambda API参考文档”或“AWS命令行文档”这些在线文档中，这种调用方式也被称为事件（Event）式调用。
数可以执行针对其他资源的创建、更新、删除操作。资源也可以是另一个服务，比如用来发送对外的电子邮件
举例而言，我们可以使用AWS Lambda的日志输入能力来实现一个简单的日志功能，用户通过异步的方式在Node.js中调用
以函数作为应用程序的后端
我们通常倾向于把这些前端程序所依赖的外部逻辑作为应用的后端服务。
为了实现这些外部的逻辑，常规的做法通常是开发一个供移动应用调用的Web后台应用，或与现有的后台应用集成，为浏览器渲染内容。但除了开发一个全新的Web后台应用或修改现有后台应用的功能以外，开发者还可以通过在网页或移动应用的代码中，直接调用一个或多个AWS Lambda函数，由这些函数来完成相应的逻辑执行工作。这些函数就构成了一组无服务器的后端。
为应用程序实现后端逻辑的一个重要原因就是安全，用户访问后端服务时，必须时刻进行认证和授权信息的检验。AWS Lambda沿用了由AWS提供的标准安全框架来控制函数的行为。例如：函数只能读取指定路径的文件、向指定的数据库写入记录。这个安全框架基于AWS Identity and Access Management策略和角色。以此方法，开发者可以更轻松地为代码的执行创造安全的环境，把安全维护整合进开发流程。开发者可以自由地裁剪每一个函数的安全权限，用一组仅具备最低权限的模块，就能轻易实现应用程序。
最低权限是指执行应用时必须获取的基本权限，例如：代码从一个中央存储区读取用户信息并发布到网页上，这样的模块就不需要为其配置写入权限，只需要读取待发信息的子集。任何超越了这个权限的安全设置都可能是潜在的漏洞，加重未知攻击的后果，入侵者往往先攻破一个模块，然后借助模块本身过于宽松的权限设置为跳板，攻击整个系统。
后端应用程序的用例和需求
用户通过后端服务与应用程序交互，请注意后端有一些逻辑和数据。
取决于应用程序计划支持的设备类型数量，使用应用程序的用户可能选择不同的设备。同时支持包括Web界面、移动设备、供高级用户集成第三方服务的Open API等在内的交互方式，正逐渐成为行业标准，也是一款应用取得成功的不二法门。
但审视不同设备与后端通信的接口，我们发现这些接口通常都是不一样的：Web浏览器往往占据主导，因为这些内容都需要被用户界面（动态生成的HTML、CSS、JavaScript和多媒体文件等）和应用后端逻辑（采用API的方式呈现）使用。
如果移动应用是在Web浏览器接口实现之后才开发的，那么后端服务需要在以Web渲染为主的API基础上进行重构，以满足移动应用的需求。不论原始应用是如何开发的，这样的重构通常都不太容易（花费不必要的时间）。这还会导致两套后端应用并存的尴尬局面，一套服务Web界面，另一套服务移动应用和可能的新设备，比如可穿戴设备、家庭自动化系统、物联网等。即使这两套后端被很好地设计，能够共享大部分功能（代码），这也是对开发资源的浪费，因为今后添加每一个新功能都需要理解两套平台上的实现差异，运行更多的测试，在一系列毫无价值的工作上浪费时间。
如果对数据进行分类，把可以导入一个或多个数据库的结构化数据分成一组，把文件之类的非结构化数据分成另一组，我们就能用以下几步，完成对整体架构的简化：
·增加一个安全的Web接口来访问所有的文件存储，这可以成为客户端直接访问的单一资源。
·把一部分的逻辑置于Web浏览器，使用JavaScript客户端与移动端的逻辑逐一配对。从架构的视角来看，这个运行JavaScript的客户端程序，不论是功能实现、安全还是与后端交互的方式，跟移动应用都是一样的。
