是来自Pivotal的Spring团队的新项目，它致力于促进函数作为主要的开发单元。该项目提供了一个通用的模型，用于在各种平台上部署基于函数的软件，包括像Amazon AWS Lambda这样的FaaS（函数即服务，function as a service）平台。

与其他的serverless模式类似，该项目致力于将函数变成开发人员所使用的主要理念。这个项目第二个重要的元素就是将业务逻辑从部署profile中解耦出来。尽管业务逻辑以函数的方式实现，但是相同的代码可以通过一个部署profile将函数暴露为RESTful服务、流处理应用（比如）或有限的（finite）任务。这意味着相同的单个函数可以部署为独立的应用，也可以部署到FaaS平台上。到目前为止，团队已经提供了针对和的适配器，而对于像Google Cloud Functions和Azure Functions这样的serverless平台，只要它们提供对Java的支持，该项目就承诺会支持。

这样的平台凭借整洁的抽象和明显的成本优势，对很多开发人员都非常具有吸引力，但是有个重要的顾虑，尤其是对企业级用户来说更是如此，那就是因为在源码中包含了框架特定的代码就会导致锁定到该厂商上面。

就像serverless专家Mike Roberts在

\

通过依赖于环境，[serverless FaaS系统]能够明显减少运维成本和复杂性，但代价就是厂商依赖以及（此时）尚不成熟的支持服务。

\

Spring Cloud Function能够改善这种状况，它在交付管道（pipeline）的打包阶段引入了部署平台依赖。这意味着，开发人员可以以隔离的状态实现函数（包括创建单元测试），只需关心逻辑以及函数的输入输出参数。然后，函数会基于这些依赖进行打包，这些依赖就能让函数运行到目标平台上。

Spring Cloud Function项目的主管这样告诉InfoQ：

\

在serverless领域，我们希望提升Java开发人员的体验，毕竟可移植性和一致性是很大的挑战。

\

这个项目的核心是推动基于函数的编程模型，而不是Spring之前更为大家所熟悉的POJO模型。已经涉足serverless领域的人可能熟悉这种模型，在这种模型中，开发人员不用关心底层基础设施或框架，只需将关注点放到业务逻辑的实现上即可，而不是样板式的代码或其他“plumbing”代码。借助Spring Cloud Function，业务逻辑会使用包中所定义的核心接口：、和的实现进行开发。

在这个非常简单的例子中，我们可以创建一个实现Function接口的类：

\import java.util.function.Function;\ public class LengthCounter implements Function {\      @Override \      public Integer apply(String name) {\          return new Integer(name.length());\      }\  }\

然后，它的魔力会通过@FunctionScan注解所启用的类路径扫描发挥出来：

\@FunctionScan\@SpringBootApplication\public class ExampleSpringFunctionApplication {\...\

除此之外，函数还可以在类中声明，这里要通过添加@Bean注解实现：

\@Bean\public Function lowercase() {\       return flux -\u0026gt; flux.map(value -\u0026gt; value.toLowerCase());\}\

如果采用这种方式的话，就不需要使用@FunctionScan注解了。

函数会打包为Jar文件，这个文件会被必要的配置以及适配器包装起来，在包装的过程中就带上了目标部署平台的部署profile。

Mark Fisher告诉我们：

\

除了serverless以外，我们还希望提升函数作为开发单元的简洁性，以及跨各种部署平台的可移植性。

\

开发人员专注于业务函数的创建，可以使用Spring Boot生态系统所提供的工具、过程和辅助设施（例如自动化测试、自动配置、依赖注入以及系统指标），这些他们是非常熟悉的，而底层的传输细节、基础设施和部署框架已经抽象了出来。

这个项目还处于初期阶段，但是Spring的人员承诺会有更多的举措，比如与和其他基于Kubernetes的serverless平台的集成，另外，与新版本Spring Cloud Data Flow的集成也会更加紧密。

查看英文原文：