前言

最近公司终于开始容器化的普及和推广，逐渐将应用从传统的 KVM 的架构迁移到容器化的云原生的生态当中。但说实话，在云原生如日中天的今天，我司在上云这条路上行动却是有些缓慢了。不得不说，传统的 KVM 架构最大的缺点就是开发人员要专注到机器的业务维护当中，扩容的步骤繁琐且缓慢，通常来说需要经历以下的几个过程：

  • 应用管理平台中申请新的机器，等待审批；
  • ops 组采购实体机，发放到业务线当中；
  • 开发人员登录新机器，安装软件及权限申请（如 IP 白名单等）；
  • 校验完成，配置负载均衡，发布上线。

而云原生的诞生正是为了解决这些不需要开发人员考虑的问题，简化了扩缩容的流程，让开发能更好地专注业务。

其实，借助 Docker + K8S 建立的一套 CD/CI 发布流程已经不新鲜了，早在大四的时候在实验室中就尝试建立了一个发布网站，解决了当时 CD/CI 的痛点，架构流程图如下所示：

但近年来，云原生仍然不断发展。最近在看美团技术博客一篇 【美团Serverless平台Nest的探索与实践】 中了解了 Servless 在美团内部的实际使用和落地，借此机会也尝试做一些尝试和了解。

Serverless 的介绍

第一次听到 Servless 的名词时，不明白其中的含义，想当然地以为是将服务端取代。而真实含义则是：

Serverless 是一种云原生开发模型，可使开发人员专注构建和运行应用，而无需管理服务器。

无需管理服务器，并不意味着没有了服务器，而是从应用开发中抽离了出来。公有云的厂商（AMS、国内的阿里云、腾讯云）负责了维护、部署、扩展等基础架构的工作，而开发人员们只需要简单地将修改好的代码发布到服务中部署即可。部署之后，Serverless 应用可响应需求，还可以根据需要进行自动扩容。

对于 Serverless 的架构模型来说，其最大的两个优点在于：

  • 资源利用率：Serverless 的产品都支持快速弹性伸缩能力，能够根据业务的流量大小来做到自动扩缩容的功能；
  • 研发运维效率：开发人员只需要填写代码路径或上传代码，不需要考虑机器或者容器的管理以及高峰流量是否需要扩容等问题；

在传统的云原生的架构模型中，即使开发人员可以减轻扩容部署带来的痛苦。但是，遇到流量的变化时仍需要考虑容器的副本增多和减少的问题。而当前这种理念有两种实现形式：

  • MBaaS（Mobile Backend as a Service），简称 BaaS：类似于 SaaS，但是更小粒度的应用；
  • FaaS（Function as a Service）：面向函数的构建和部署的方式；

FaaS 体验

目前市场上很多公有云的厂商都支持 FaaS 产品的部署，这里为选择了良心云中的云函数，免费额度中有 100 万次的调用次数以及 40万GBs 的资源使用量，对于只是简单的学习体验足够了。

首先打开 Serverless 的控制台，点击左侧的函数服务菜单，新建一个云函数。一个云函数的服务需要我们配置它的运行环境以及运行的函数代码：

另外还有一个触发器配置，提供了如定时触发（Job Task）、API 网关触发（HTTP）等。如果我们想通过 URI 就能够简单地访问这个云函数服务，则可以选择 API 网关触发等方式，如下进行配置：

点击完成之后，云服务器对厂商就会根据你的配置以及代码做一系列的编译、打包、部署等操作，最终完成云函数服务的成功搭建，整个过程非常的简单和迅速：

接下来，我们点击触发管理，可以看到我们刚才配置的 API 网关触发器的相关信息。除此之外，还提供了一个 HTTP 的访问 URI，能够让我们直接执行这个云函数服务：

点击访问之后，却发现报错了：

这是因为良心云的云函数使用 API 网关触发的方式时，返回的 JSON 数据需要满足它的规范。我们点开函数管理，修改原始代码满足接口的返回数据规范之后，保存并点击部署按钮：

成功部署之后，再次访问上边的 URI，可以看到我们的云函数服务能够正常地访问了：

这样我们就体验了一次 Servless 中 Faas 的从函数服务的配置部署、代码修改重新部署的流程，你会发现整个过程非常地顺畅，不用考虑环境的搭建，也不需要敲命令重启服务，甚至还可以在网页上编写代码，达到一站式的开发部署流程。

后记

上面介绍了 Serverless 的优点以及其实际的体验也非常的友好，即使 Serverless 具备了这些优点，但是也存在着一部分的缺点。其中，最大的问题就是被公有云的供应商捆绑，过度依赖于他们的产品，同时在做服务迁移（例如从良心云迁移到套路云）可能它们之间的配置迥然不同，无法平滑地迁移。

除此之外，扩展性差、安全性问题也是 Serverless 缺点的一部分，而对于 Faas 而言，还有一些独有的缺点：

  • 函数量爆炸：随着使用的深入，你管理的函数数量可能会有一个大爆发。而这意味着混乱，和更多出错的可能。
  • 重复的函数逻辑：函数无法复用，每个云函数服务中需要写重复的代码逻辑（除非你将公有逻辑打包发布成第三方库）；
  • 无状态：Faas 声明周期很短，运行后即销毁，无法做有状态的逻辑，例如本地缓存。

总的来说，Serverless 给我的感觉很惊艳，而对于一些简单和小型的函数方法可以考虑通过这种方式来部署。

参考资料：