基于Serverless架构进行应用开发

什么是Serverless

从过去20年IT基础架构层的发展过程来看，计算、存储和网络三种基础资源得到了不断的发展和抽象。从物理机到虚拟化，从虚拟化到云计算，再从云计算到云原生，孕育出诸多新生概念，无论如何变化，一定是向着有利于业务创新方向发展，开发人员越来越不需要关注底层的基础架构。

云原生本身是一个非常广义的概念，主要包含：微服务架构，应用容器化、Serverless化以及敏捷的软件交付流程。所以很多人在谈论云原生时与Kubernetes划等号，是非常片面的。

今天我们重点来说说Serverless，这种技术的本质并不是真的“无服务器”，真正的目的是要帮助应用开发者摆脱应用程序后端所需的服务器资源的管理和运维工作。我们在设计一款产品或应用时，往往要从不同的唯独考虑产品。 从开发与测试角度更多的考虑的是开发语言、框架的选择、数据库、如何进行压力测试等；而从实施和运维角度考虑则要考虑环境怎么构建、高可靠如何实现，如何升级、如何扩容等诸多基础架构的问题。从Serverless架构看，更希望你专注于你的开发和测试，而将实施和运维彻底交给云来解决，前提是你需要遵循Serverless架构。

在构建Serverless架构中，通常包含两种常用的服务类型：

1、后端即服务（Backend-as-a-Servce，BaaS），例如：数据库、消息队列、身份验证由云商直接以服务方式提供的服务 2、函数计算（Function-as-a-Service），主要将业务逻辑代码运行在其中，函数计算通常运行在容器环境内，按照CPU和内存的运行时间来计费。函数计算触发往往与时间相关，例如：定时器、HTTP请求。目前各家云商云商都提供了函数计算服务，而这方面的佼佼者无疑是2014年11月就推出的AWS Lambda服务，在很多AWS的最佳实践中都能看到巧妙利用函数计算服务来解决业务架构问题。

我们在开发一个业务系统时，通常采用传统的架构思想来规划系统建设。但是随着云原生技术的发展，除了逐步打破传统的运维与开发之间的关系，我们的开发架构也随之发生了改变。未来的应用开发架构，让开发、测试与运维的边界越来越模糊，应用开发的迭代速度进一步提升。

当然Serverless并不是万能的，很多劣势无法满足所有的场景需求，但是随着新技术的不断迭代，一定会有新的技术出现来填补这些空白。

从业务视角看Serverless

记得是在2020年12月的微信小程序峰会上一个分享中看到这一组数据，给我的震撼很大。这是一家专门依托于微信小程序从事线上娱乐化社交电商社区。我们从图中数据可以看到1-10月份销售数据为23,909,022.69元，销售在14万笔。

那么如果是一个传统电商平台，承载这样的销量需要付出多少资源的代价呢？我们来看看这家公司的运营数据。是的，你没看错仅仅是3000元，而研发人力投入仅仅不到10个人。

2020年双十一销量数据为2,194,203元，而基础架构层为此付出的额外费用仅为10元钱。

从交易数据看，虽然从并发性上远不及天猫这样每秒几十万的交易量。但是如果从性价比(销量/基础架构投入)看，这样的数据绝对是可以各位同行参考的。为什么可以得到这样惊人的数据，这离不开以Serverless为理念的云开发。

从开发者视角看Serverless

这是一张云开发自身发展的版图，这张图还是与厂商利益之间进行了深度绑定，不过我们重点从技术角度去分析一下。Serverless架构的发展主要集中在平台能力和基础能力两个方面，当然扩展能力也很重要，我们也可以将这些归属为平台能力层，并且可以是多云。这些插件能够给我们应用提供更多的想象空间，例如最近大火的Clubhouse，就是利用了中国声网提供的服务。

去年的时候我曾经专门录制过阿里云的函数计算课程( https://edu.51cto.com/course/22144.html )，在这个课程里，我更多的是将函数计算作为串联云原生服务的纽带进行讲解。但是随着Servless开发框架越来越成熟，函数计算在构建应用的地位发生了变化，上述提到的云开发就是一个典型。通过微信这个入口，快速支撑了业务发展的需要，在2020年初紧急的开发的健康码就是利用了这样的特性实现。

我们设计一款全新的应用架构时，要从云开发能够提供的整体能力角度出发进行思考。简单说，Serverless框架的核心在于围绕着函数计算来设计业务逻辑，通过使用各个云原生服务的能力，满足业务上的需求。Serverless架构的设计更多的是在改变原有的开发框架和开发模式，将原有以架构为核心的代码组织形式打散在各个函数中。将原有架构层需要考虑的并发、高可用等完全交由底层来支撑，开发可以更专注于业务本身。

那么构建以函数计算为核心的Serverless框架应用时，应当注意哪些问题呢？

1、函数计算需要事件驱动，例如一个HTTP请求，或者一个上传对象存储的行为都会产生事件，而这些事件产生都是云原生的，也是最及时的。以最常见的WEB类应用为例，基本就是前端及后端对数据库各种CURD的组合实现。前端的静态文件可以考虑使用对象存储，再使用CDN进行加速，通过API网关来驱动后端的函数计算，如果有需要持久化存储的数据可以选择NAS或对象存储服务。通过这套架构可以很轻松的实现一个高并发的业务系统。 2、虽然Serverless架构看上去很美好，但是仍然会面临很多挑战。性能问题就是其中之一，因为函数计算是触发式启动，在初始阶段和并发激增的情况下响应请求时会很慢。所以在实际开发过程中，除了要合理优化自己的初始化代码逻辑外，还要结合性能监控指标，合理利用预留实例的功能，达到性能与价格的最优。

3、那么用户现有的业务是否有必要改造为Serverless架构呢？我觉得应该取决于需求，因为Serverless的开发模式决定了这个改造一定会产生时间和人力投入的成本。首先研发人员要学习Serverless的理念，熟悉开发模式，梳理出当前系统改造的方式，甚至要重构部分代码。这个过程往往要高于容器改造的成本，但是小于微服务改造的成本。

4、研发管理问题也是在应用Serverless应用中需要考虑的问题，从代码结构如何组织，到如何进行上线前的测试，再到如何优化原有持久化集成的流程，都对研发管理提出了挑战。

结语

Serverless架构为应用开发带来了新的活力，让研发人员能够更加的专注于业务逻辑的开发工作。同时，让企业的总体拥有成本（TCO）降低，但是提供服务的能力和灵活度大幅度提升。