前言

随着技术的倒退，咱们有越来越多的抉择来实现咱们的业务逻辑。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中的服务拆分