Nomad提供FaaS服务

通过搜索到的材料 https://www.google.com/search?q=nomad+faas&oq=nomad+faas 整理

  1. Katacoda上有一个Nomad整合OpenFaaS的实验环境但是尝试一下,实验环境初始化有问题。

  2. 官方faas-nomad项目OpenFaaS provider for the Nomad scheduler,描述了如何在本地搭建实验环境,文档描述清晰,上手简单。

这篇博客纯命令行,注意修改网关地址,验证可行。

  1. OpenFaaS官方博客Introducing Serverless with Hashicorp Nomad, Consul, and Vault基于Nomad v0.9

  2. Youtube OpenFass 介绍及源码分析 https://www.youtube.com/watch?v=bZtgrAVR9HQ


除了Amazon functions等商业服务外,开源FaaS项目有很多:OpenFaaS, OpenWhisk, Knative, Kubeless, Fission, Fn Project, and Nuclio.

看到Istio 可以在 Nomad+Consul上部署,但是没有严谨地测试过,Knative是基于Kubernetes和Istio的Serverless框架;当前,还是faas-nomad项目可以用于生产环境。

hashicorp宣布对Kubernetes的第一等支持


Jet公司的所有微服务都部署在Nomad上,与Consul、Vault等进行透明集成,Consul用于服务发现,Vault用于秘密管理,Prometheus和Grafana用于监控,Splunk用于日志管理。这意味着如果可以在Nomad上部署公司选择的Serverless运行时,可以以几乎零成本获得所有这些集成。

Jet公司分享的一篇FaaS运行时选型调研中,有这么一张FaaS运行时对比: FaaS运行时对比

在性能考虑上,选用的指标是冷启动时间自动扩缩容效率。文章中关于cold-start time 和 auto-scaler efficiency的性能测试方法可以借鉴,有时间希望复现

提出的观点很犀利:

Don’t call it serverless yet, if you don’t have production ready controllers abstracting away IO interactions between different functions, between functions and external systems, and between functions and their triggers.

文章认为,如果企业已有微服务架构、CI/CD等敏捷开发工具链,使用现有FaaS架构既没有抽象IO,也没有实现预期的降低成本,提高开发人员工作效率的承诺。

该技术选型结论是:目前serverless技术栈不够成熟,与当前的微服务策略相比,无法更加节约成本和改进生产力。

全栈JVM框架Micronaut通向1.0版本之路

Graeme Rocher: 在过去的几年里,技术领域发生了巨大的变化,特别地,如果你看看类似Docker、Kubernetes这样的系统以及无服务器运动,你会发现,它们实际上都针对低内存微服务和低开销应用程序而进行了优化。其结果是,像Go和Node这样的语言在这些平台上体现出了比Java更显著的吸引力,因为它们具有出色的冷启动性能和内存消耗。有一个非常好的问题,可以问下自己,如果Docker和Kubernetes团队有各种技术选项,为什么要选择Go而不是Java来实现这些平台?在我看来,答案很简单:如果他们用Java编写了那些技术栈,并且有了今天这些技术选项,那么我们就都需要一台超级计算机才能让笔记本电脑在本地运行它们。
原因是多种多样的。一方面是语言层面的限制。JVM是一项惊人的技术成果,但对于短时间运行的操作(如无服务器函数),它提供的优化往往就不存在了,但是,你仍然需要拖着整个JVM来运行你的应用程序。像GraalVM这样的项目有可能通过将Java应用程序编译成本地镜像来解决这些限制,但是,坦率地说,框架设计人员在提高Java应用程序的效率方面有很大的作用。
在框架层,传统的JVM框架(如Spring和Java/Jakarta EE)已经有超过10年的历史了,那时,每个人都在部署单体应用程序,它们主要是围绕着反射和注解的运行时分析来构建。这种方法的问题在于,由于各种各样的问题,从类型擦除,到有限的注解API,再到反射逻辑的相对缓慢,所以,几乎不可能构建一个Java框架,启动速度超快,而内存消耗超低。框架运行时的负担是巨大的。如果你观察一下Spring在运行时所做的工作,就会发现这有些不可思议,从用ASM解析字节代码来生成注解元数据,到积极缓存反射信息以避免不可避免的重复读取减慢速度。在缓存所有这些运行时生成的信息与实现快速启动和低内存消耗的目标之间存在着不可调和的冲突。
我们相信,Micronaut是面向未来的框架的基础,通过消除所有反射的使用,以及在编译时通过一组注解处理器和执行预编译(AOT)的AST转换,生成所有注解元数据、代理和框架基础设施,消除这种矛盾。这使得Micronaut能够实现极快的启动速度、低内存消耗,并且实现与GraalVM本地镜像兼容性的重大改进。
当然,Java生态系统有大量的项目是基于Java的,像Spring、Kafka、Cassandra、Hadoop、Grails等,它还有一个丰富的语言生态系统,包括Groovy、Scala、Kotlin、Java、Clojure等。因此,这也不全是和低内存占用的微服务与无服务器应用程序有关,有许许多多的工作负载仍然受益于JVM和JIT。然而,即使对于这些工作负载,我们也相信,通过在启动时间和内存消耗方面比其他框架更高效,Micronaut可以提供很多东西。

来源: 全栈JVM框架Micronaut通向1.0版本之路