前言

随着技术的倒退，咱们有越来越多的抉择来实现咱们的业务逻辑。Serverless 作为时下前沿的技术，是不是也能够摸索一下微服务架构的新可能性？

这篇文章就是总结近段时间以来，我摸索的用 serverless 落地 SpringBoot 微服务项目的一些成绩。

什么是 Serverless

什么是微服务和什么是 springBoot 曾经不须要我解说了。

那什么是 Serverless 呢？

依据 CNCF 的定义，Serverless（无服务器）是指构建和运行不须要服务器治理的应用程序的概念。

Serverless 并不是没有服务器就能进行计算，而是指对于开发者或者公司来说，无需理解和治理底层服务器，就能进行计算。

艰深一点讲，Serverless 就是封装了底层计算资源，你只须要提供函数，就能够运行了。

这里还要提到一个概念，就是 FaaS（Function as a Service），函数即服务。咱们通常运行在 Serverless 上的逻辑是函数级别的粒度。

因而对于拆分粒度管制很正当的微服务，是非常适合应用 serverless 的。

Serverless 对于微服务的价值

1. 每个微服务 API 被调用的频率不一样，能够利用 Serverless 精准治理老本和弹性。
2. 不必放心一个 API 调用量大而须要扩容整个服务。Serverless 能够主动扩缩容。
3. 不须要去运维每个服务背地部署多少个容器，多少个服务器，不必做负载平衡。
4. 屏蔽了 K8S 等容器编排的简单学习老本。
5. Serverless 这种无状态的个性也十分合乎微服务应用 Restful API 的个性。

初步实际

首先，须要筹备一个 SpringBoot 我的项目，能够通过 start.spring.io 疾速创立一个。

在业务开发上，Serverless 和传统的微服务开发并没有任何不同。所以我就疾速写了一个 todo 后端服务，实现了增删改查性能。

示例代码在这里。

那么应用 Serverless 真正有差别的中央在哪里呢？

如果只是简略的想要部署单个服务，那么次要差别在于两个方面：

1. 部署形式
2. 启动形式

部署形式

因为咱们摸不到服务器了，所以部署形式的变动是很大的。

传统的微服务部署，通常是间接部署到虚拟机上运行，或者用 K8S 做容器化的调度。

传统的部署关系大抵如下图。

如果应用 serverless 通常要求咱们的微服务拆分粒度更细，能力做到 FaaS。
所以应用 Serverless 部署微服务的关系大抵如下图。

Serverless 只须要提供代码就能够了，因为 serverless 自带运行环境，因而 serverless 部署微服务通常有两种形式：

1. 代码包上传部署
2. 镜像部署

第一种形式和传统部署相比是差别最大的。它须要咱们将写好的代码打包上传。并且须要指定一个入口函数或者指定监听端口。

第二个种形式和传统的形式相比简直不变，都是把做好的镜像上传到咱们的镜像仓库。而后在 serverless 平台部署的时候抉择对应的镜像。

启动形式

因为 serverless 是应用的时候才会创立对应的实例，不应用的时候就会销毁实例，体现了 serverless 按量计费的特点。

所以 serverless 在第一次调用的时候存在一个冷启动的过程。所谓冷启动就是指须要平台调配计算资源、加载并启动代码。因而根据不同的运行环境和代码可能有不同的冷启动工夫。

而 Java 作为一种动态语言，它的启动速度也始终被人诟病。然而还有更慢的，就是 spring 的启动工夫，是大家引人注目的慢。所以，java+spring 这种强强联合造就了树懒般的启动速度。就有可能造成首次调用服务呈现超长的等待时间。

不过，不必放心，spring 曾经提供了两种解决方案来缩短启动工夫。

1. 一种是 SpringFu
2. 另一种是 Spring Native。

SpringFu

Spring Fu 是 JaFu (Java DSL) 和 KoFu (Kotlin DSL) 的孵化器，以申明式形式应用代码显式配置 Spring Boot，因为主动实现，具备很高的可发现性。它提供疾速启动（比最小 Spring MVC 应用程序上的惯例主动配置快 40%）、低内存耗费，并且因为其（简直）无反射办法非常适合 GraalVM 本机。如果搭配上 GraalVM 编译器，利用启动速度就能直线降落到原先的大概 1%。

不过，目前 SpringFu 还处于特地晚期的阶段，应用过程中问题也比拟多。另外，应用 SpringFu 会有较大的代码革新老本，因为它干掉了所有的 annotation，所以这次我没有应用 SpringFu 的形式。

Spring Native

Spring Native 为应用 GraalVM native-image 编译器将 Spring 应用程序编译为 native 可执行文件，以提供打包在轻量级容器中的 native 部署选项。Spring Native 的指标是在这个新平台上反对简直没有代码革新老本的 Spring Boot 应用程序。

因而我抉择了 Spring native，因为它不须要革新代码，只须要增加一些插件与依赖就能实现 native image。

Native image 有几大益处：

1. 在构建时会移除未应用的代码
2. classpath 在构建时就曾经确定
3. 没有类提早加载：可执行文件中所有的内容都会在启动时加载到内存中
4. 在构建时就运行了一些代码

基于这些个性，因而它能让程序的启动工夫大大放慢。

对于如何应用它我将在下一篇文章中解说，具体教程能够查看这个官网教程。我也是参考这个教程做的。

我就说说我的测试比照后果吧。

我把编译好的 image 别离在本地，腾讯云 serverless 的云函数和 AWS serverless lambda 进行了部署和测试。

从测试后果看，SpringNative 大大晋升了启动速度。进步 serverless 的规格还能进一步晋升速度。

如果 Serverless 的冷启动速度管制到了 1 秒内，那么大部分业务都是能承受的。并且也只有首次申请的时候会存在冷启动的状况，其余申请都和一般的微服务响应工夫一样。

此外，目前各大平台的 Serverless 都反对预置实例，也就是在拜访到来之前提前创立实例来缩小冷启动工夫。带来业务上更高的相应工夫。

总结

Serverless 作为目前先进的技术，它给咱们带来诸多益处。

1. 主动扩缩容的弹性和并发性
2. 细粒度的资源分配
3. 松耦合
4. 免运维

但 serverless 也不是完满的，当咱们尝试在微服务畛域应用它的时候，咱们仍然能看到它存在很多问题期待解决。

1. 难以监督和调试

   1. 这是目前公认的一个痛

2. 可能会有更多的冷启动

   1. 当咱们拆分微服务为了适应函数粒度时，同时也扩散了每个函数的调用工夫，导致每个函数调用频率变低，带来更多的冷启动。

3. 函数间的交互会更简单

   1. 因为函数粒度变细，在大型微服务项目中，导致本来就盘根错节的微服务会变得更加盘根错节。

总结起来就是，想要齐全代替传统的虚拟机，在微服务这条路上 Serverless 还有很长的路要走。

下一步

我会持续摸索 serverless 与微服务的实际。

前面的文章我会探讨上面几个话题

• Serverless 中的服务间调用
• Serverless 中的数据库拜访
• Serverless 中的服务的注册与发现
• Serverless 中的服务熔断与降级
• Serverless 中的服务拆分