对目前 serverless 平台们改进的一个想法

[Contextualist]

谈一谈我对 serverless 的看法，我非程序员，只是最近小小研究了下这类架构，认识可能很肤浅，望大佬们指点批评。

Serverless 或者 FaaS 总得来说的做的事就是进一步解耦业务逻辑和运维，将一系列微分的、模块化的函数彼此间及与外界以一种简单统一的方式连接起来。但是，我觉得这些连接还能做到更简单、更统一。

一个云函数与外界数据的接口就两种形式：1 ） HTTP，2 ）平台的预定义事件（如对象存储发生变化）

对于 1 ），我觉得 HTTP 是业务逻辑之上的一层额外的转接。头部和参数就像无类型的 JSON，拿到后又要反序列化之类的过后才能用。所以，应该甩掉 HTTP 包袱的数据接口，直接对外开放端口，可以用 gRPC over sockets 这样最小化的协议，玩法也多多（全双工流什么的）。

我并不是说要革 HTTP 接口的命，毕竟有些业务本身就跟 HTTP 相关联，这时候用 HTTP 显得自然。只是 HTTP 承载了太多的功能，针对性不够强（不过优势是通用性带来的普适性，可以利用现有生态）。

对于 2 ），首先不能指望各大厂商统一。对于这些差异，只能指望厂商们在各自消息 API 上做得更人性化、文档更清晰些。

之前看到一篇文章讲 AWS lambda 与 PaaS 并无本质区别，我觉得也有一定道理，FaaS 的限制一多，与平台的耦合又回来了。

我对生产环境所知甚少，是不是当今的 serverless 已经可以满足绝大多数的微服务需求了呢？再次，有肤浅或错误的地方请指正！

刚刚发现 AWS Lambda 可以使用 WebSocket 了 （18年底的新功能），但是实现是通过 API 网关分发消息事件，再通过 API 网关送响应消息，对平台的耦合性太大，而且好像只能实现响应流 (server streaming)，发送端还是事件机制。不过也算是提升了一点自由度。

已经过去快两年了，不知道还有没有看到这里的人……
最近发现 Google Cloud 在一年前发布的 Cloud Run 算是一个接近我设想的解决方案：可对外暴露 gRPC 接口。不过 Cloud Run 算是介于容器和无服务器之间的技术（更偏向容器，需要用户提供容器镜像而不是函数）。

[janxin]

目前云厂商提供的 FaaS 本质上收到运行环境限制，比如内存大小限制，执行时间限制，在一些基于 HTTP 短链接请求场景中非常合适，可以方便的去配合实现流量突发性或者临时需求型目前更合适，比如说短期运营活动。

FaaS 还有一个就是配合云服务本身的触发器去实现部分可扩展的批处理执行任务，如图片压缩，视频处理等等。

目前还没有看到长时间驻留的 FaaS，这样就跟 Docker 容器里面跑进程似乎又没什么区别了...

[lhx2008]

感觉限制很多，想持久化存取一些数据太麻烦（包括日志，缓存，数据库），和最开始解耦的初衷背离。也可能是我理解不对。

[feather12315]

其实我很想知道一点：抛弃 serverless 中的隔离不谈，它跟 RPC 有啥区别呢？

[Contextualist]

@janxin
没错，但我感觉涉及核心业务逻辑的倒是很多都是突发的，驻留的部分大多偏架构（当然应该有特例，所以说单靠 FaaS 不能完成所有事情）。这样看来，运行资源限制反倒是可以各取所需的优势，用多少请求多少。

@lhx2008
持久化的东西最终都被平台垄断了（ PaaS 的反扑），不过如果平台的微服务做得好、拓展性强，体验还是好过自己管理数据

@feather12315
我个人理解是，这是两个范畴的概念，可以同时描述一个事物，serverless 侧重描述提供服务的单元的运作方式（即，非常驻的），RPC 侧重描述一个过程，其中提供服务的单元表现得就像本地的一个函数（并不限制服务单元如何运作）

[binux]

HTTP 是最统一的接口

[horacezhang]

说的挺好

[alfredhuang211]

针对 1，其实只是 faas 产品对外暴露的接口形式，和 faas 本身提供的能力可以分开来看，感觉以后不会排除出现 rpc 等类型的接入能力，毕竟只是接口，可以有各种形态对外提供服务。
针对 2，现在的一些基金会、开源组织在试图统一事件结构，但是这个是一个漫长的过程，特别是 serverless 的领头老大 aws 不一定会理睬一些开源规范或定义。

[Contextualist]

@alfredhuang211 是啊，我就是不清楚我这种想法的呼声高不高，之前 AWS Lambda WebSocket 就是应各方要求才有的。规范化的事是得慢慢来，不得不吐槽一下 AWS Lambda 是我用过的最难用的平台。