Serverless 能带来什么
Serverless 字面翻译过来是无服务器的意思。怎么理解无服务器？无服务器肯定不是说应用运行无需服务器。这里无服务器的意思是研发人员无需关心服务器底层的运维工作。所涉及的服务器范围，从起初的应用服务器，发展到像数据库这样的服务器。现在已经出现了一些数据库 Serverless 的产品。
Serverless 的这种简化屏蔽底层复杂性的做法，在计算机领域能够找到很多例子。例如，Java、Python、Go 等语言，提供了垃圾回收器，避免了程序员手工分配和回收内存，从而极大解放了程序员的生产力，也使得这些语言比前辈变得更加流行。这种做法在发展早期会有这样或那样的问题，但随着技术的完善，最终会接替研发人员完成大部分的工作。
云计算的发展目标是让计算、存储、网络等 IT 资源就像现在的水电燃气一样可以方便地使用。但目前云计算的发展和这一目标还有相当的距离。业务研发人员如果要使用云计算服务，还是需要掌握相当的云平台运维和基础设施的知识和技能。如果必须要让业务研发人员完成相关工作，无疑会增加其工作难度，使其无法集中精力解决业务问题。而安排专门的运维人员，一方面增加了成本，另一方面又与 DevOps 的发展趋势不符。Serverless 的出现，就是从云计算基础设施层面解决这两方面问题。同时，在计算资源成本方面，提供了更细粒度的按需使用的特性。归纳起来，Serverless 主要有如下三方面的特性：
- 无需关心基础设施
- 更快速地弹性伸缩
- 细粒度按需使用，按需付费
image
Serverless 的这三个特性可以让研发人员将精力放在业务研发上，提高业务研发效率，在兼顾成本的同时满足业务对于系统的可用性和性能方面的要求。
Serverless vs PaaS
在云计算发展早期，PaaS 是一个很流行的云计算产品形式，Google 也凭借其 Google App Engine 服务成为当时云计算市场的一支主要力量。但市场很快发现，大型系统落地云计算所需要的各种基础设施、云产品、云服务、中间件，远不是 PaaS 这种形态所能提供和支持的，使得 PaaS 逐渐被更灵活的 IaaS 所取代。
PaaS 这样的以研发视角提供云计算服务的产品形式尤其市场需求。但其诞生之初，并没有 Docker 这样的统一的应用封装运行形式，更没有 Kubernetes 这样能够为容器应用提供基础设施统一抽象的技术。所以，早期的 PaaS 虽然能提供部分无服务器特性，但是无法满足大规模云计算落地的需要。
Serverless 技术的出现，可以看作是 PaaS 这一云计算产品形式在新技术的支持下的复苏。Serverless 和 PaaS 一样都强调底层基础设施无关这一特性。并且，现在 Serverless 的产品是构建在容器技术之上。通过容器技术，Serverless 产品可以和现有的基础设施和其它云产品整合在一起，融入整个云计算产品群和生态圈，而不是原来 PaaS 那样只是一个单一的产品，没有体系化作战能力。
并且，Serverless 增加了细粒度的弹性伸缩的能力，可以降低云计算平台和客户的运行成本。
正是因为 Serverless 与 PaaS 的这层关系，一些新出现的 Serverless 产品，不论从使用方式还是产品名称，都能看到以前 PaaS 产品的影子。例如阿里云的 SAE (Serverless App Engine)。
Serverless 的挑战
Serverless 目前最大的挑战还是在于大型微服务系统难以落地 Serverless。Serverless 最主要的产品形式是 FaaS，例如 AWS Lambda。Lambda 简单易用，并且有 AWS 强大丰富的产品线的加持，有丰富的玩法和使用场景。但像 Lambda 这样的 FaaS 产品目前并不适合现在的微服务架构。虽然目前也出现了 FaaS 之外的 Serverless 产品形式，但总体而言，要在 Serverless 上大规模落地目前主流的系统架构，还有很多困难。归纳起来主要有以下几点：
挑战一：全研发周期适配
传统的元计算技术聚焦于软件的运维阶段工作，但随着技术发展，云计算需要逐渐深入软件研发整个生命周期中，从而促进研发效率提升，降低成本。另一方面，微服务架构的流行对软件研发也带来了很多挑战。大型的微服务如何调试、测试、部署，这些都比单体应用要复杂许多。这些对于 Serverless 技术来说，是挑战，同样也是机遇。未来，不仅测试、调试、部署工作可以在云上完成，甚至开发也会通过云上 IDE 完成。借助 Serverless 技术，研发人员可以一键在云上部署测试应用和其所依赖的服务，快速完成独立测试环境的部署。并可利用 Serverless 快速伸缩的特性迅速回收测试资源，节约成本。
挑战二：基础设施升级
Serverless 技术在促使基础设施透明化的同时，也对基础设施提出了更多要求。例如，服务治理，之前以小时为粒度进行的服务伸缩，在使用 Serverless 之后，会变为秒级甚至更小的粒度。这会导致服务注册、服务信息推送的频率大幅提升，对服务治理技术将带来巨大挑战。在这些方面，像 ServiceMesh 这样的技术也会在基础设施方面对 Serverless 的普及起到帮助作用。
挑战三：封装格式标准化
Serverless 技术在带来开发便捷的同时，会导致对平台的依赖。为了使应用在不同环境，如不同的云计算提供商之间、混合云环境下、本地和线上环境下都享受同样的研发体验，需要为应用提供统一标准的封装格式。容器技术解决了镜像和运行时的标准化，但对于一个云上的应用来说，服务治理、日志、链路监控等也都需要标准化。在这方面，微软提出的 OAM (Open Application Model) 做出了探索，值得关注。
Dapr
挑战四：系统轻量化
目前大部分微服务系统启动时间都是十几秒至一分钟之间，部分需要更长的时间。这样的启动速度显然是不适应 Serverless 技术的。所以，在升级云平台的同时，对其上的运行的应用也需要升级。一方面，应用需要避免过度复杂庞大，另一方面需要通过技术升级的方式提高启动速度。这方面，Quarkus 这样的 Java 原生框架的热度甚至超过了 Spring Boot 这样的传统微服务框架技术。
开源微服务框架活跃度报告
另一方面，也可通过中台等手段，将核心业务能力集中实现，在提高研发效率的同时，避免因过度拆分导致资源利用率的降低。即通过集中业务功能，降低系统伸缩的必要，这样的通过业务架构手段解决技术架构问题，也不失为一种思路。
总结
Serverless 是云计算服务即容器技术之后的重大发展。我所在公司的私有云平台的容器平台其实是以部分 Serverless 的形式提供服务的，用起来很方便，不用关心底层虚机、容器、网络的配置，只需配置应用镜像、环境配置、实例规格和大小、自动伸缩、负载均衡等内容。这对运维工作已经是很大简化了。但从业务架构和研发工作角度，应用机房架构、基础服务如数据库的架构等都还是需要关注的，例如：
- 同城两中心还是两地三中心还是需要做单元化
- 应用的部署架构与所依赖的服务是否一致，是否会导致机房局部的流量不均
- 应用实例数、数据库等是否满足大促等对性能的需要
总之，业务流量是瞬息万变的，而传统的基础架构设计方式是相对静态的，是难以在兼顾研发和硬件成本的同时满足业务对容量和容灾方面的需要。因此，Serverless 技术是大势所趋，是解决上述难题的关键技术。
参考
- 喧哗的背后：Serverless 的概念及挑战 https://www.infoq.cn/article/FDSTKcZbosp7Fefgm0ZG
- 为什么下一个十年的主战场在 Serverless https://www.infoq.cn/article/p3ogNPqvIv9Q8tThH9Bm
- 聊聊 AWS Fargate 在容器世界中的角色定位 https://amazonaws-china.com/cn/blogs/china/the-role-of-aws-fargate-in-the-container-world/
网友评论