Serverless 架构开发手册 — “人人都是 Serverless 架构师”先导篇

Serverless - 2021-12-31 09:24:18

---

作者 | 寒斜

前言：关于 Serverless 概念性的相关文章网上已经非常多，原本我也不想再做更多关于 Serverless 概念和价值相关的介绍，主要原因是我觉得当前的这个阶段我们讲 Serverless 应该到了结合现实生产去聊它的落地细节和实际的效果，而不应该还是用 PPT 给大家灌输相关的理念。但基于本篇是笔者想做的《人人都是 Serverless 架构师》专题系列的开篇，所以也还是需要尽量通俗的先给大家做一个关于 Serverless 架构的开题介绍。
​

什么是 Serverless 架构

Serverless 架构是以 Serverless 服务体系为核心的应用架构设计理念，属于分布式架构的一种。最明显特征是它继承了 Serverless 的核心优势：及时弹性，能够应对高并发请求并在降低计算服务成本的同时，具备微服务架构的高扩展，快速迭代等优势。它是一种更加聚焦于业务开发的架构。

我们举例介绍一下 Serverless 架构与传统的架构的对比：

某初创的垂直领域电商公司，需要搭建一个完整的动态站点服务。从最开始的单体架构开始，需要在阿里云购买一台 2 核 8G 的 ECS 和 200G 的硬盘。通常情况下 5M 带宽一年的花费约为 4000+， 且需要用户自己安装 Mysql 数据库，redis, nginx 等基础软件。还要有专业同学长期运维服务器，处理如防止磁盘变满，服务器启停及备份等工作。

当业务量上来之后，为了保持高可用和提高访问性能。需要对基础架构进行升级，要购买阿里云负载均衡、弹性伸缩服务和更多的 ECS 服务器，同时为了防止数据库瓶颈，还需要升级使用云数据库 rds ，此时的整体架构如下：
​

除了架构层面的准备，还需要进一步设置 ECS 的安全组、伸缩规则、SlB 转发规则，后续的运维会比单体的更复杂，整体价格成本也更高。

但是使用 Serverless 架构的话，不管是在项目初创亦或后续业务量变大等时期，整体架构都可以保持不变。其架构如下图所示：
​

业务增加只需横向扩展路由配置并添加函数即可。成本上, 阿里云网关 ApiGateway 共享实例访问量 1000w 次，共计 60 块；阿里云对象存储 OSS 按照存储量和访问流量收费，存储量标准型是 0.12元/GB/月，访问流量 0.5元/GB，阿里云函数计算有免费流量而且也是按量付费整体费用也非常低。数据库根据需求可以采用 TableStrore 按量付费的模式，如果更习惯用 Mysql 则可以采购云数据库。

Serverless 架构的优缺点

从前文中与传统架构的对比可以看出 Serverless 架构的优势：

对初创项目有更好的成本优势，架构体系中大部分按量付费的产品模式对初创项目而言可以最大程度的节省成本，运营成本和开发成本都会降低扩展性更强，升级成本更低。不管是从最开始应对小规模的并发到更大流量的并发，整体的架构基本可以不变，只需要升级产品和实例规格即可（如网关升级到专享，函数内存规格增加），扩展业务无需重启服务只需动态增加路由、函数和静态配置便可以，并且完全不会影响现有业务迭代效率更高，因为基础架构部分几乎无需付出更多关心，开发人员只专注业务函数即可，同时能够做到快速部署上线，整体效率大幅度提升

但是不可以忽视的是 Serverless 架构同样存在以下缺陷：
​

新的架构体系对公司的员工会有更高的要求，新技术体系需要重新学习，对公司组织会造成一定冲击。厂商平台锁定，不同的服务提供商有自己的一套开发模式和规范，不利于迁移，这种风险会在公司必须迁移云服务商的时候会暴露的更加明显。架构在应用层面表现的更加离散，持续集成和构建存在更多的风险。不同于部署到服务器上的应用，无服务架构的应用通常被拆的更加离散，业务路由，业务动态服务和静态服务都分散到不同的产品上。应用层面的管理会是一个挑战。调试和部署更难，Serverless 服务本身对开发者是黑盒的，通常遇到问题不像服务器一样可以登录排查，对问题的定位变得更加困难。

​

当然对于后面的个问题，我们目前都给出了解决的答案，我会在后续的文章进行更详细的介绍。

构建 Serverless 架构

​

Serverless 应用的的核心还是在业务逻辑处理上，不过你仍然需要更多相关的知识体系才能很好的把它落地，下面介绍一下构建 Serverless 架构我们需要哪些相关的知识储备。​

1、基本的云计算架构体系

​

因为 Serverless 架构是云原生的架构体系，构建在云上必然需要掌握一些基本的云计算架构知识，比如网络，存储，安全等。网络部分主要包括你需要知道你应用的端到端访问路径，比如如果是 http 的请求，你需要知道域名解析，以及网关。

存储部分则更多的是合理的规划成本需要，比如你需要了解静态资源摆放的最佳实践应该是对象存储，数据的存储则毫无疑问应该是在数据库中，不过至于是 Serverless 化的数据库还是传统的 Mysql 数据库，则要看你的使用习惯、成本预算和对新事物的接受程度。安全的话题则比较多了，比如安全的秘钥管理，安全的服务调用，安全的流量管控等。

虽然 Serverless 本身会面临厂商锁定的挑战，但至少这些基础的云端服务能力是每家云厂商都会有的。对于阿里云 设计网络相关的产品有 DNS 解析，CDN 加速，ApiGateway 等，存储的话则有数据库存储 比如 RDS, OTS 等产品，对象存储如 OSS，这些会在后面实战中为大家详细的介绍。

2、开发者工具

开发者工具则是开发 Serverless 架构的应用绕不开必选项之一。鉴于 Serverlss 架构是一种离散的架构，对云端服务物尽其用的架构，所以 Serverless 应用在构建部署，调试，以及持续集成上都有别于传统的应用，Serverless 架构的应用可能会是一个多语言多服务类型的集合体，对于 Monorepo 的诉求会更强烈，此外在构建部署以及调试运维上也存在诸多不便，Serverless 的开发者工具正是为了弥补 Serverless 应用架构的不足而生的。

几乎每一家云商都有自己的 Serverless 开发者工具，比如阿里云的 ServerlessDevs，AWS 的 SAM ,以及跟腾讯云合作的 Serverless Framework 等。
​

除了基本的项目初始化及构建部署能力之外，这三款工具又都兼具 Iac 的能力，能够满足多样化的 Serverless 应用持续集成诉求。
​

本系列会以 Serverlss Devs 为核心工具，为大家讲解 Serverless 的架构实践。
​

除了基础云计算的相关概念以及开发者工具外，你还需要知道如何工程化的管理 Serverless 架构的应用，包括持续集成，多环境部署测试，可观测等，此外对安全有更高要求的项目还需要进一步处理安全的问题，还有性能调优等问题。
​

写在最后

Serverless 的技术成熟度曲线已经从高热度到目前的一个二次爬坡阶段，实际上也是真正开始落地生产的阶段。通过工具链的整合，已经可以做到把多个应用相关的项目整合成一个独立的代码仓库，也就是有独立的开发脚手架供更多的开发者使用去构建自己的 Serverless 应用。
​

随着社会对创新落地的效率要求越来越高，我相信 Serverless 架构的天然优势一定会比传统的应用架构更能满足这个诉求，所以希望能有更多的人参与进来一起践行和为 Serverless 开发者生态贡献，欢迎更多的开发者加入到我们自研的 Serverless 开发者工具 Serverless Devs 项目中来。
​

如果对 Serverless Devs 有任何疑问或希望更进一步了解，可以加入社区建设钉钉群：31193960
​

作者介绍：

王庆（寒斜）｜阿里云云原生中间件前端负责人

2016 年加入阿里中间件从事云产品企业控制台研发工作，负责中间件 20 多款云产品前端研发工作，主要技术栈为大前端通用技术，目前专注在 Serverless 开发者工具链的建设，是云原生 Serverless Devs 研发负责人之一。

\

Tags 标签

前端gitnode.js

扩展阅读