通过Serverless的发展历程及带给我们的挑战，引出我们改如何改变思路，化繁为简，趋利避害，更好的利用其优势，来释放企业效能，为创造带来无限可能。
一 Serverless概述
无服务器计算近年来与云原生计算都是在互联网背景下产生，其顾名思义是指开发者在构建和运行应用时无需管理服务器等基础资源设施，应用被解耦为细粒度的函数，函数是部署和运行的基本单位。用户只为实际使用的资源付费。这些代码完全由事件触发（event-trigger），平台根据请求自动平行调整服务资源，拥有近乎无限的扩容能力，空闲时则没有任何资源在运行。代码运行无状态，可以轻易实现快速迭代、极速部署。
1.1 Serverless背景
- 云计算演进历史
在快速发展的互联网时代，从最初的物理服务器，到使用XEN、KVM等虚拟化技术的虚拟机，再到云计算自动管理这些虚拟化资源，再到容器技术的出现，隔离了应用关于操作系统，现在，我们又有了Serverless，让用户无需关心程序运行环境、资源及数量，只要将精力 Focus 到业务逻辑上的技术。
云计算的发展从IaaS，PaaS，SaaS，到最新的BaaS，FasS，在这个趋势中Serverless(去服务器化）。
- Serverless的组成
对于一个完整的应用，想要上Serverless，需要我们考虑前端，API网格即后端的服务以及对象存储数据库等，从技术角度来说，Serverless 就是 FaaS 和 BaaS 的结合。
FaaS（Function as a Service） 就是一些运行函数的平台，比如阿里云的函数计算、AWS 的 Lambda 等。
BaaS（Backend as a Service）则是一些后端云服务，比如云数据库、对象存储、消息队列等。利用 BaaS，可以极大简化我们的应用开发难度。
Serverless 则可以理解为运行在 FaaS 中的，使用了 BaaS 的函数。
1.2 Serverless特点
- 无状态：但也决定了Serverless的无状态特性，因为每次函数执行，可能使用的都是不同的容器，无法进行内存或数据共享。如果要共享数据，则只能通过第三方服务，比如 Redis，COS 等。
- 无运维：使用 Serverless 我们不需要关心服务器，不需要关心运维。这也是 Serverless 思想的核心。运维的发展经历了人肉运维，自动化运维，DevOps，AiOps等，而Serverless带来一种新的运维模式，这种模式下用户需要管理的只有Code可以认为NoOps。
- 事件驱动编程：Serverless 的运行才计算，便意味着他是事件驱动式计算。
- 低成本：运营成本，Serverless将用户的服务器，数据库，中间件委托于BaaS/FaaS，用户将不再参与基础设施及软件的维护，尤其在大规模的集群运营上成本大幅度降低。开发成本，对比IaaS或者PaaS平台的服务器或者操作系统，Serverless的架构中，用户操作的是服务化的组件比如存储服务，授权服务等，可以缩短开发周期，降低开发难度。
- 按需计费：Serverless/FaaS区别于IaaS/PaaS预先分配计算资源的计费方式，其计费方式通常是按请求次数及运行时间，一方面可以最大程度利用资源，另一方面真正的按需计费可以降低用户的资源成本。据统计，商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出，本质上这是对社会资源的一种浪费。而在Serverless架构下，提供商将提供更细力度的计算能力最大限度满足实时需求，资源利用率将大幅度提升，可以认为相对IaaS与PaaS Serverless/FaaS是一种 “绿色” 计算。
- 弹性伸缩：Serverless架构一个显而易见的优点即“横向扩展是完全自动的、有弹性的、且由服务提供者所管理”。
二 Serverless带来的挑战
2.1 服务改造
- 使用场景有限：Serverless并不是适用所有场景，在目前的发展情况下，Serverless适合事件驱动的异步工作流程，如果应用本身场景不适应，改造起来难度非常大，且后期很难达到成效。
- 开发部署：目前Serverless的生态处于快速发展阶段，目前各大公有云厂商都有自己的Serverless产品，为了便于开发人员快速开发，厂商都针对自己的产品编写了各种IDE插件，可以自动补全，代码检测，并且可以一键自动化部署到云端，但是对于传统一些应用的覆盖面不到，目前还有很多需要持续优化改进的地方。
- 运行测试：对于函数的测试，目前各大公有云也提供了运行测试用例，但是对于多个接口参数传递，目前还没有很好的功能支撑，对于想在部署节点集成到CI中，对此也非常的麻烦
2.2 基础设施挑战
- 底层基础设施构建维护：目前对于开源Serverless，例如：Knative/Openfass/Kubeless还是OpenWhisk对于其的搭建、部署已经后期的维护，对于企业都带来了巨大的挑战，如果业务迁移上去，出现基础设施层问题，需要在短时间内进行修复，对运维人员提出了非常高的要求。
- API的维护：对于将业务迁移上Serverless，对于后期大量的后端API的维护，没有统一的管控平台，或维护工具对此管理可谓异常困难，对于API的后期维护，不仅仅是来自统一仓库，更是需要将管控延伸到平台上。
- 相关生态维护：对于Serverless不仅仅是后端的单个函数，其也包含Baas相关的产品，如果企业自己选型开源工具，需要同时维护API网关，对象存储，日志，监控等都需要用户自己实现，对此一入Serverless深似海，不但没有降低用户成本，反而带来了更大的技术挑战。
三 AWS Lambda概述
针对上述Serverless面对的挑战，我们需要清楚的认知知道的业务是否适用于Serverless的场景，拆分业务，对于某些接口，某一类模块功能是否可以迁移上Serverless来优化架构。
对于基础设施带来的挑战，在目前公有云快速发展的阶段，其为我们提供了统一的一站式上云体验，与最佳实践，在我们考虑范围内或未来可能遇到的问题，都已经替我们考虑到并解决，真正的实现了让我们在云计算的时代，用户将所有的精力关注在自身的业务创新，释放更大业务价值上，在此我们就AWS 的Lamdb进行展开实践。
3.1 AWS Lambda概述
- 什么是AWS Lambda
AWS Lambda 是一项计算服务，可使您无需预配置或管理服务器即可运行代码。AWS Lambda 只在需要时执行您的代码并自动缩放，从每天几个请求到每秒数千个请求。您只需按消耗的计算时间付费 – 代码未运行时不产生费用。借助 AWS Lambda，您几乎可以为任何类型的应用程序或后端服务运行代码，并且不必进行任何管理。AWS Lambda 在可用性高的计算基础设施上运行您的代码，执行计算资源的所有管理工作，其中包括服务器和操作系统维护、容量预置和自动扩展、代码监控和记录。您只需要以 AWS Lambda 支持的一种语言提供您的代码。
- Serverless生态
AWS Lambda是属于FaaS，Serverless还需要Baas的相关服务，公有云为我们提供了完整的一套解决方案，例如事件响应，更改Amazon S3 存储桶或 Amazon DynamoDB 表中的数据；以及使用 Amazon API Gateway 运行代码以响应 HTTP 请求；或者使用通过 AWS SDK 完成的 API 调用来调用您的代码。借助这些功能，您可以使用 Lambda 轻松地为 Amazon S3 和 Amazon DynamoDB 等 AWS 服务构建数据处理触发程序，处理 Kinesis 中存储的流数据，或创建您自己的按 AWS 规模、性能和安全性运行的后端。
对于DevOPS，您可以使用 CodePipeline 和 AWS CodeBuild 自动部署这些应用程序。
3.2 应用场景
Serverless 有一定的应用场景,分析自身业务的架构即场景，结合Serverless的特点，来拆解或将适应场景的业务迁移上Serverless。
- 定制图片网店店家进行商品图片维护时，需要根据商品陈列位置，将图片动态切割成不同尺寸，或者打上不同水印。当店家把图片上传到对象存储 OSS上，会通过函数计算上定制的trigger来触发函数计算。根据计算规则，生成不同尺寸的图片，满足在线商品陈列需求，整个过程无需再搭建额外服务器，也无需网站美工干预。
- 物联网中的低频请求物联网行业中，物联网设备传输数据量小，且往往是以固定时间间隔进行数据传输，因此经常涉及低频请求场景。例如：物联网应用程序每分钟仅运行一次，每次运行 50ms，这意味着CPU的使用率仅为 0.1%/小时，或者说有 1000 个相同的应用可以共享计算资源。而Serverless架构下，用户可以购买每分钟 100ms 的资源来满足计算需求，既能有效解决效率问题，也能降低使用成本。
- 定制事件用户注册时发邮件验证邮箱地址，同样可以通过定制的事件来触发后续的注册流程，而无需再配置额外的应用无服务器来处理后续的请求。
- 固定时间触发事件触发固定时间触发，例如在夜间或者服务空闲时间来处理繁忙时候的交易数据，或者运行批量数据，来生成数据报表，通过Serverless方式，不用再额外购买利用率并不高的处理资源。
四 AWS Lambda实践
您将使用 AWS Lambda 控制台创建一个 Lambda 函数。接下来，您将使用示例事件数据手动调用 Lambda 函数。AWS Lambda 将执行 Lambda 函数并返回结果。然后，您将验证执行结果，包括您的 Lambda 函数已创建的日志和各种 CloudWatch 指标，由于篇幅有限，在此我实践Lambda最基本的使用，后期高阶部分可以仓库官网，来享受一站式服务体验。
4.1 创建函数
打开 AWS Lambda 控制台，选择 Create a function。在函数名称中，输入函数名称，选择 Create function。
4.2 设计函数
设计器显示您的函数及其上游和下游资源的概述。您可以使用它来配置触发器、层和目标。
- 创建函数
在此我们创建一个python 3.6 解释器运行时的函数。
创建完成后，我们可以看到函数模版代码为：
import json
def lambda_handler(event, context):
# TODO implement
return {
'statusCode': 200,
'body': json.dumps('Hello from Lambda!')
}
完成后，可以看到我们编写的函数。
4.3 运行测试
点击测试，创建测试事件，在此选择一个简单的hello world世界测试模版，自定义命名后，进行测试。
创建完成测试事件后，运行测试，可以看到运行的结构。
注意：每个用户每个函数可以创建最多 10 个测试事件。这些测试事件不适用于其他用户。
4.4 配置详解
我们可以先来看看运行测试后的结果输出。
通过打印结果，我们可以得出以下配置结论：
- lambda_handler：该函数为lambda每次运行的函数，所有我们的业务逻辑在该函数内部进行编写，通过测试修改函数名称导致函数无法正常运行，该函数名称为固定的。
- event：为我们需要处理的数据，也就是输入参数。
- context：为该函数运行的一些信息，例如：aws_request_id为该函数调用后盛出的requestid，function_name为该函数的名称。
- 在最后我们可以利用函数进行return结果等。
4.5 日志监控
4.5.1 查看日志
对于函数测试运行后，我们可以通过监控日志来查看函数运行的相关信息，
- 执行结果：部分将执行状态显示为 succeeded，还将显示由 return 语句返回的函数执行结果。
- 摘要：部分显示在 Log output 部分中报告的密钥信息（执行日志中的 REPORT 行）。
- 日志输出：部分显示 AWS Lambda 针对每次执行生成的日志。这些是由 Lambda 函数写入到 CloudWatch 的日志。为方便起见，AWS Lambda 控制台为您显示了这些日志。
4.5.2 查看监控
对于函数运行监控，我们可以通过CloudWatch来进行查看，后期可以进行统计分析，函数的瓶颈及并发数，进行调优。
4.6 资源清理
再使用完成函数后，进行相关资源清理，再清理资源的时候有用有日志和IAM角色，也需要一并清理。
- 删除lambda函数
- 删除日志组
- 删除执行角色
至此就完成了整个函数、角色和日志组的清理工作。
4.7 注意事项
- 并发性：当函数代码运行时，如果有另外一个请求，那么需要去配置函数并返现，预配置另一个实例来提升函数的并发性。并发性受区域级别限制的约束
- 触发器：是调用 Lambda 函数的资源或配置。这包括可配置为调用函数的 AWS 服务、您开发的应用程序以及事件源映射。事件源映射是 Lambda 中的一种资源，它从流或队列中读取项目并调用函数。
- Virtual Private Cloud (VPC) – 如果您的函数需要通过网络访问无法在 Internet 上获得的资源，需要将其配置连接到VPC才能正常获取Internet上的资源。
- 对于敏感数据，可以通过环境变量来注入到函数中，以保证函数的安全性。
五 Serverless上的思考
在使用 AWS Lambda 时，您只需负责自己的代码。AWS Lambda 管理提供内存、CPU、网络和其他资源均衡的计算机群。函数计算虽然适用于很多场景，但也不是覆盖全部应用场景的万金油，无服务器云函数想要后期更快的发展，需要进行业务逻辑的精细梳理和各函数调用，其次需要云厂商多个性化定制服务，已经自己需要完善生态，最少无服务器云函数支持自家云上各产品。虽然目前来说Serverless还是有不少的局限性，Serverless一直在发展完善中，广大开发者和服务提供者都在寻找Serverless的无限可能。
