FaaS - 函数计算

函数计算越来受到开发者的青睐,目前大多数函数服务都是通过HTTP REST API、gRPC,RPC等协议进行服务暴露的,同时考虑到函数还需要和外部进行通讯,这也是为何大多数FaaS的架构设计方案中,函数侧会伴Sidecar和Web Server这两个大胖子。 这种结构设计对对于传统的巨型应用来说问题不大,但是对于短小精悍的函数来说,这个完全是不划算的买卖,你需要为只有500行代码的函数付出10倍于函数本身的保护费,而且还增加了系统的复杂性。

借助于RSocket,我们可以将FaaS的平台通讯层进行一些调整,结构图如下:

FaaS Diagram

FaaS和RSocket在进行通讯协议整合后,一些历史遗留问题就不复存在啦:

  • 无端口监听: 函数在主动连接到Broker并注册后,然后基于该连接完成相互间的通讯。对比传统的启动服务端口号然后对外提供服务,新的架构不需要Web Server暴露监听端口和协议、不需要HTTPS证书、不需要攻击防护等。
  • 流量保护: Broker会作为代理人帮助函数完成安全验证、流量保护等。
  • 基于消息/事件通讯: 很多人都说到,函数计算是基于消息/事件通知的,这个没有错,而RSocket协议就是基于异步消息
  • 函数、服务间调用: 在Broker接入后,函数和其他服务或者函数之间的通讯就非常简单啦,函数不需要再引入复杂的SDK,只要向Broker发送调用请求就可以,然后Broker会负责服务路由和返回,这样函数负担也轻了很多

不能说RSocket协议和FaaS是绝配,但是确实让FaaS的架构设计更简单,去除不必要的累赘,让FaaS的成本更低。当然目前FaaS的发展并不是火箭式的速度,究其原因,我们不知道"是开发者不喜欢FaaS,还是昂贵复杂的FaaS让开发者怯步”。