请教 serverless 几个概念性的问题，请各位不吝赐教

[dreamlike]

最近在聊天的时候了解到 serverless 最近几年很火 1 ，serverless 对于语言的要求是什么样子的？拉起速度，包大小？我看大家都是用 go 和 node.js 写 2 ，了解了一些 serverless ，发现似乎都是无状态的，如果我要验证用户信息，并保存一些关于在线的元数据还能用 serverless 吗？

感谢大家的指教，我还有一个问题，请问各位有哪些比较适合 serverless 的项目类型，如果能有确切的使用 serverless 产品就更好了

[Rocketer]

serverless 是云服务商绑定的，先选服务商，再看他支持哪些语言。

就目前而言，js 是最流行的，因为所有的服务商都支持（注意有些不是 node ），并且服务商的官方文档也多用 js 举例子。所以用 js 可以很容易 Google ，用其他语言则需要经常自己研究搞定问题。

[Rocketer]

serverless 必须是无状态的，因为服务实例有很多且寿命很短，你的请求很难一直发到同一个实例。这就是为什么 serverless 可以撑住超级大的突发访问量，又可以在低访问量的时候保持低价，因为实例数量一直在动态增减。

你应当尽量把程序设计成无状态的，但你同样可以使用数据库来持久化一些数据。AWS 的一些数据库（比如 DynamoDB ）也是 serverless 的，可以很好的配合你的 serverless 程序而无需担心数据库会成为瓶颈。

[moen]

从描述来看应该具体指 serverless function

1. serverless function 对语言没要求，只要平台有能运行该语言的运行时即可，有些甚至可以自己提供容器镜像作为自定义运行时。像 AWS 就能用 C# 甚至 PowerShell
2. 能用，需要自己额外提供数据库

[ch2]

1. 本质是个 docker 容器，除了 JVM 基本都适合上 serverless
go 的好处是容易编译成一个二进制文件
python 跟 js 的好处是依赖的库文件也可以较为简单地打包，虽然没有 go 那么简单
JVM 就不推荐了，启动太慢，通常只适合进程常驻内存，不适合被反复销毁重启
2. 保存在 redis 或者 memcached 里，通常情况下需要你额外购买

[Rocketer]

@ch2 用 redis 和 memcache 的问题是这些都不是 serverless 的，你得自己预测流量并手动调整容量和实例数量。而且实例一经创建就得付费，不像 serverless 的产品那样不用就不付费。

[duke807]

serverless 是指不需要服務器，譬如通過公網 IP 連接遠程桌面、查看安防攝像頭（特別是 IPv6 都是公網），又譬如各種 p2p 應用也是 serverless ，甚至 webrtc 也有 serverless 的 demo ，用 webrtc serverless 做關鍵字可以找到。。。

[ch2]

@Rocketer #5 本质上你要实现的这个功能必须使用常驻内存模式才能保证响应速度的及时性，如果你愿意牺牲性能就能达到绝对的"不用就不付费"效果。
现阶段 serverless 只是初步实现了对无状态计算的改造(并不是最终的形态)，数据库也有 serverless 改造但是进展没有那么快，能在市面上用的产品也不多，比如 tx 云就有你可以试试。
缓存中间件的 serverless 化，目前看起来非常得不偿失。在实际使用中，redis 跟 memcached 往往对服务可用性的影响非常大，以至于浪费计算资源预留实例换取服务稳定性是非常合算的做法。你要反其道行之对其进行成本优化，既省不了几个钱又会带来非常多的副作用。这个取舍没啥诱惑力，只有一些研究性质的论文，产品化是遥遥无期的

[shuimugan]

1：没有语言限制，现在云厂商卷得很，都支持用 docker 镜像部署了，没几个人用 serverless 那个脚手架开项目.
建议 docker 镜像控制在 100MB(推送后看到的大小)以内，冷启动(拉镜像->解压->启动)最好在 0.5S 以内，所以容器里文件越少越好，编译成单文件就比较重要了.
C# 和 Go 都 OK ，写得爽还得是 C# .
如果是 Node.js 的话最好用 https://github.com/vercel/pkg 打包成单文件丢容器，避免 node_modules 大量碎片文件解压影响启动速度的同时体积会小很多很多很多很多

2：持久层用云厂商提供的服务，serverless 是让你跑应用层的

[ClericPy]

@ch2

之前调研并上线了 Lambda 的代码, 怎么跟你说的不大一样, 还是 lambda 比较特殊么. 纯讨论, 不是挑刺哈, 实在对这个领域特别感兴趣, 想多了解一些以后看有没有机会 all-in

1. go 看起来确实香, 但是作为 FaaS 想导入 function handler 时候也并不方便, 还要导入 lambda 库写 handler, 但实际体验在我这边不如可以"依赖代码隔离"以及指定某个函数名字(不用具体写入口函数) https://docs.aws.amazon.com/lambda/latest/dg/golang-handler.html

2. 前面提到依赖代码隔离, Python 那边可以放比较重的不常变的依赖(一般把依赖也打包到 zip 代码里有些浪费) 到 Layer 里面导入就行了, Java 也是可以的, 所以依赖锁到 Layer 上面, 具体代码实际就一点点, 上传流量很小, 对 go 来说上传整个编译程序反而会大了一些, 而且解释型语言调试阶段(没自动上线)在后台直接改代码就发布运行了...

3. 现在 lambda 貌似支持直接部署一个 Docker 了, 不过底层本质是不是 Docker 我不确定, 没注意到

4. JVM 看起来确实冷启动不友好, 不过据说做了各种优化, 以及预热实例相关能满足, 所以之前看到的结论是 Java 在 Serverless 领域其实并不稀少(美团那边也发了博客说 Java 实践), 冷启动以后的 Java 调用速度还是很可观的, 毕竟编译了的

5. 有关内存数据库 Redis 做持久化或者有状态这方面, 之前也是这么想来着, 不过当时看了提到需要 VPS 凑内网, 这个似乎会导致成本上升, 如果走外网, 流量又会很高, 白名单的话 IP 不固定, 所以最后不得不妥协改造成了事件驱动的. 用 Redis 有什么建议解决上面提到的问题么

6. 提到 Serverless 数据库, 以前只听说过具体不太了解, 那个 CAP 放弃的是 P 么, 这个主要卖点是快还是便宜啊? 产品化遥遥无期那还是不期待了...

[ClericPy]

@Rocketer

声明纯讨论不抬杠

1. JS 亲儿子听过听多次, 之前 Serverless 特别火的一个主题就是帮助很多纯前端无痛变全栈. 这个确实挺香

2. 无状态确实是绝大多数分布式计算的捷径, 很早以前听说有个 Serverless 举例是拿来做 session, 这种算有状态的不, 印象里 lambda 最久留 15 分钟, 一般也足够短效会话用一下, 比如限时聊天室啥的, 有没有想过那种是怎么保证每次请求处理者是同一个实例的, 还是说建立连接以后保持住. 对后端不太熟练, 纯好奇, 似乎有调用时候共享运行时状态或者什么机制

3. 看定价策略, 似乎是一个函数调用完了 return 以后就不再计费, 这时候如果有个多线程后台驻留跑着, 会不会扣费呢, 还是说这个容器直接冻结了 CPU 不让分配给这个进程? 之前只见到每个实例启动以后最久保留 5 ~ 15 分钟, 这段时间会不会有没关彻底导致的额外计费呢

[shuimugan]

目前我工作中发现不适合 serverless 的项目
1：网关类型，用 ECS 实例 2C4G 可以随随便便跑上万 QPS ，但是 serverless 单个实例的并发额度很小。以阿里云为例单个实例无论是分配 128MB 内存还是 3G 内存都只给你 100 并发，傻愣得要死，产品经理还想教育你说你场景有问题，阿里味十足。去提工单也就给你总实例最大并发数升到一两万，单实例并发依旧是 100 ，还让你做完压测不够再开放更高限制。

适合 serverless 的应用
1：网络代理，懂的都懂
2：内部管理后台 /文档平台。绝对的低频，10 分钟都不一定有一个访问量，前端资源丢对象存储，API 用 serverless 跑，一个月没几块钱。
3：定时任务 /队列消费端，特别是那些写得垃圾很吃内存的傻愣代码，什么事都没干一运行就吃你一两 G 内存的那种，你用传统 ECS 跑 4C8G 的配置都算低，丢 K8S 集群又怕业务量上来把其它节点资源给挤掉，单独分一个集群又浪费钱，直接丢 serverless 可以睡个安稳觉。
4：扫描器，比如做个云 nmap ，云 sqlmap
5：CI/CD 类，传统服务器最少都给个 4C16G 吧，然后资源占用曲线有明显波峰（上班时间）和低谷（下班时间），换 serverless 用完即走及其合适。但目前国内 serverless 都不支持分配核心数，编译时可以用到多核的反而吃亏。
6：冷启动快，内存占用低的程序，无脑丢 serverless 就是了

不一定适合 serverless 的应用，可以考虑混合部署：
1：java 应用。冷启动很慢又吃内存，云厂商一般可以设置驻留实例，比如你配置上班时间段驻留 2~5 个实例，然后通过网关计数但请求到达多少阈值时扩容到多少实例。但是驻留实例多了费用也多，还得算过账才知道。
2：本来就优化得贼牛逼的代码，比如网关这种 2C4G 的轻量云都能搞定几千上万并发甚至更高的，日常流量也的确有那么高，这种情况还不如开一个 ECS 实例在那里跑，然后去 serverless 也部署一个做保底，万一 ECS 那个死掉了就切换到 serverless 版，低成本做到高性能高可用。

如果你想 all-in serverless 的话，业务增长上去之后数据库连接池可能会成为一个坑点，毕竟日常跑几个实例和突然扩容上百个实例，对于数据库的连接数是突增的，而云厂商数据库连接数一般有限制（比如阿里云独享 MySQL 16C64G 的连接数在 2W ，隐藏限制单个账号连接数限制大概在 6 千），云厂商的数据库代理早点接入测试吧。

[gam2046]

期待 serverless 能有一个公共的标准，也就是有个标准的 runtime ，这玩意用起来的时候确实很爽，但是如果要跨服务商迁移，真就火葬场了，说要彻底重写一遍都不过分。

[dreamlike]

@shuimugan 多谢 CI/CD 确实适合

[ch2]

@ClericPy #9
1-3. 目前 FaaS 发明 layer 这些东西只是产品不太成熟的产物，理论上 serverless 不应该设计地比单纯使用 docker 更复杂。也就是代码以及依赖库安装应该是一次性的，layer 破坏了依赖库跟代码的一致性，你的代码使用的依赖库变更了还要重新传一份 layer ，而且很多语言的依赖库没法用 layer 拆分，这个只能说是权宜之计。真正成熟的 serverless 在处理代码依赖跟二进制体积问题上应该跟你在本机的 docker 上装依赖一样简单。
4. 即使是一个 Hello World 的 Spring Boot 冷启动也要好几秒，这意味 JVM 生态的冷启动是基本无法优化的，serverless 对 JVM 的意义很小，保证它的性能必然或多或少地需要让它常驻内存，如果额外使用了计算资源来优化其在 serverless 下的表现，其实跟 k8s+容器比没什么优势。
5. 没有什么好办法，要么花钱买 redis 要么就只能放弃这个特性
6. 卖点主要是便宜，理论上只用付存储的费用以及计算的费用

[wuyufeng2333]

还 serverless 呢，炒这么多年了