『 作为一个不断发展的新兴技术， Serverless 热度的制高点已然到来。』
或许，Google Trends 所显示的 3 年猛增 20 倍的“ Serverless ” 搜索量，可以佐证 Serverless 在整个行业中的火爆程度。
不仅如此，据 KBV 研究公司新发布的《全球 Serverless 架构市场》及 RightScale 云服务状况报告 2018 版显示，全球 Serverless 架构的市场渗透率已超 75%，市场规模预计到 2024 年将达到 140 亿美元，并将在预测期内以 23.4% 的年复合增长率增长。
作为一种云原生的架构，Serverless 与 BaaS、FaaS 之间有何“爱恨情仇”？冤家路窄却能完美解决前后端联调等开发痛点，解决方案又是如何？相较于传统开发模式，基于“无服务开发”理念的小程序·云开发模式又“新”在何处，有何利好？下面我们从 Serverless 的架构演进来具体分析。
『 Serverless 架构详解 』
在过去的十几年里 (2006 年诞生 IaaS)，云计算的进程从物理机演进到 IaaS，再到 PaaS，已经将应用程序的运行环境和通用组件，越来越多地交给云服务商。Serverless 进一步将主机管理、操作系统管理、资源分配、扩展、甚至应用逻辑的整个组件，都交付给云服务商，在成本和运营效率方面获得了显著的提升。
作为一种云原生的架构，Serverless 使得开发者在开发应用时不需部署、配置和管理传统服务器，转而依赖于第三方服务，将代码托管到云端平台。
目前，业界并没有给出明确的定义，而是把其分成两种类型，分别为「 Backend as a Service 」 和 「 Functions as a Service 」。换一种开发者更熟知的表达方式看，也就是「 后端即服务（BaaS）」和「 功能即服务（FaaS）」。
Serverless=BaaS+FaaS？听着很高深，其实很好理解。
「 BaaS 」是将应用开发中所有后端的需求，通过统一的云平台来解决，让开发者无需再编写和管理所有服务端组件。BaaS 使开发者无需编写完整的逻辑组件，但需要将应用程序与云服务商提供的特定接口和模型集成。
而「 FaaS 」是把函数作为一个线上服务、远程计算服务，可以通过 API、邮件、IoT 等执行。FaaS 是一种构建和部署服务端软件的新方式，面向部署单个的函数或者操作，是一种新的运行代码的托管环境。FaaS 本质上是事件驱动的，优化了函数运行时的资源使用，它的目标是在运行的时候才消费资源。
从表面上看，BaaS 和 FaaS 是两码事——前者是把应用中的各个部分完全外包出去，后者是一种新的运行代码的托管环境。
那么，为什么要把它们都划归为 Serverless 呢？
关键在于，它们都不需要开发者管理自己的服务器主机或者服务器进程。Serverless 并非是无服务器，它仍然涉及服务器，只是这个服务器在云上。实际上，这是一种使用服务的新方法，在很多情况下，它比自己去买服务器更为划算，而且加快了项目上线的时间，降低了开发、维护、扩展的复杂性。
Serverless 技术的崛起不但让开发者无需过多考虑服务器问题，并且完美地解决前后端联调等开发痛点，作为一种全新的架构，Serverless 可谓是云计算发展演化的必然结果。
『 传统开发痛点解析及解法 』
“Serverless 所提供的接口，简化了云计算的编程，其代表了程序员生产力的又一次的变革，一如编程语言从汇编时代演变为高级语言时代。” 2019 年，伯克利在《将云中的编程变得简单：伯克利视角下的 Serverless 计算》中的犀利语句也论断了 Serverless 云时代主宰般的地位。
此前，云计算服务并没有从根本上改变设计应用程序的方式。
例如，当使用 Docker 这样的工具时，开发者在应用程序周围放置了一个更薄的“盒子”，但它仍然是一个盒子，逻辑架构不会发生显著的变化。再比如，在云中托管 MySQL 实例时，开发者仍需考虑工作负载所需的虚拟机资源，以及故障切换等问题。
现如今，这种情况在 Serverless 面前，迎刃而解。甚至在前后端分离与联调所产生的一系列权责、沟通与调试等开发痛点上，Serverless 也能从以下 5 个维度完美解决：
▪ 按需计费。不同于 IaaS/PaaS 预先分配计算资源的计费方式，Serverless 按请求次数及运行时间计费，一方面可以最大程度利用资源，另一方面真正的按需计费可以降低开发者的资源成本，开发者只需要为函数实际执行所消耗的资源付费，即用即付；
▪ 高效率。在 Serverless 的架构中，用户操作的是服务化的组件，如存储服务、授权服务等，缩短了开发周期，降低了开发难度，且避免了由基础设施产生的延迟；
▪ 绿色计算。在 Serverless 架构下，服务商提供细力度的计算能力，最大限度地满足开发的实时需求，资源利用率将大幅度提升；
▪ 高扩展。Serverless 架构的横向扩展是完全自动、有弹性的，且由服务提供者所管理；
▪ 无需运维。运维的发展经历了人肉运维、自动化运维、DevOps 和 AIOps 等阶段，而 Serverless 带来一种新的运维模式。在这种模式下，开发者只需要关心业务本身，无需运维。
正因开发痛点重重，在想要突破传统开发模式，探索新型开发方案的过程中，开发者借助 Serverless 技术架构，基于“无服务开发”理念创造出了一种新型开发模式——小程序·云开发。
小程序·云开发，是微信与腾讯云联合开发的原生 Serverless 云服务，它集成了微信公众平台及腾讯云两个核心业务的技术能力，免鉴权、免后端配置和运维、一切围绕 API 和 SDK 为核心。
以云调用功能为例，只要在小程序端触发云函数，便将经过微信自动鉴权直接调用，如数据分析、客服消息，插件管理等开放 API 接口。这些开放接口通过系统配置、将大幅提升效率、优化体验、降低运营成本。
「 那么，在用户量峰值过大或黑客攻击的情况下，小程序·云开发是如何保证后台服务性能与安全的呢？」
首先，小程序·云开发没有传统的后台服务器，也就没有被 DDoS 的目标，这是从产品形态上保障用户业务安全；其次，小程序·云开发之间的环境是互相隔离的，即便发生攻击，从架构上将不会相互影响；再次，小程序·云开发服务构建在腾讯云基础设施之上，天然拥有快速扩容和安全防护的能力。
在用户量突增时，小程序·云开发的开发人员会立即通过响应的监控及告警发现流量的变化，然后确认是否需要扩容。腾讯云基础运维能力也保证了开发者拥有能够快速扩充服务的能力，以避免对用户的服务造成影响。
而在突发黑客大流量攻击（如 DDoS）时，小程序·云开发的开发及运维人员也会先确认遭受攻击的真实性，当得到确认后会第一时间与腾讯云系统运维、腾讯安全中心确认，确保已经对小程序·云开发的服务器加强防护，以保护系统服务安全。此外，小程序·云开发控制台也有响应的流量实时数据告知开发者，开发者可以据此了解服务的流量数据，如有异常可以联系小程序·云开发官方。
『 小程序·云开发架构详解 』
云开发是一种 BaaS，在引入了 Serverless 技术架构的同时，让开发者在构建应用的过程中无需关注计算资源的获取和运维。
在应用端，开发者可以直接使用官方提供的接口。在云函数端，开发者可以直接使用官方提供的 Node SDK，来操作云资源。
目前小程序·云开发一共提供了三大基础能力，分别是云函数、数据库、文档存储。简而言之，就是提供了存文件、存数据和运行业务逻辑的能力。
其中，云函数能力来源于腾讯云的“无服务器云函数 SCF” 。通过与 SCF 的深度结合应用，可以形成一套比较完整的 Serverless 解决方案。
▪ 使用 SCF，可以让开发者更简单的管理服务端代码，无需管理或配置服务器，只需将代码上传至 SCF，就可以自动运行；
▪ 可以更高效的利用资源，按照执行时间和调用次数收费，代码不运行时不产生费用；
▪ 可以快速建立持续扩展的能力，每个云函数互不影响，并行处理不同的逻辑。
此外，小程序·云开发的数据库能力则是基于腾讯云的 NoSQL 数据库服务，并兼容 MongoDB 协议。每个数据库资源都会分配一个实例 ID，每一个实例都是至少一主一从的副本集或者包含多个副本集的分片集群，数据库反向代理转发请求去最优副本集。
同样，小程序·云开发借助腾讯云提供的面向非结构化数据——对象存储（Cloud Object Storage，COS）支持文档存储服务的文件上传、下载和删除等功能，可以帮助开发者处理文件相关的业务逻辑。所有上传的文件都会有一个全网唯一的文件 ID，使用文件 ID 可以在 image、audio 等小程序组件中直接访问文件。通过小程序·云开发上传的文件在小程序内默认允许访问，不需要配置 CDN 域名白名单。
2019 年 1 月，腾讯云宣布推出总价值超过 10 亿元的“小程序·云开发”资源扶持计划，对超过一百万个小程序开发者提供免费资源扶持，全面助力开发者打造优秀小程序。
小程序·云开发将持续丰富 SDK 能力，释放腾讯的技术价值，逐渐支持多种开发语言，让开发更便捷。不仅如此，腾讯云还会加快丰富云开发的各类行业解决方案，满足企业业务不同应用场景需求 。
未来，新的技术层出不穷，但是要知道技术始终是为人服务的。不解决人的问题，技术无法成长壮大。
将开发者的精力解放出来，让他们投入到业务逻辑等更具价值的工作中，从根本上赋能技术发展，才是推动行业”车轮“不断向前驶进的源动力。
如果你有关于使用云开发CloudBase相关的技术故事/技术实战经验想要跟大家分享，欢迎留言联系我们哦~比心！
云开发
Tencent CloudBase
关注我可以说是相当酷了~