看实例记录，上次尝试 Serverless 还是三年前。

在连续两天的折腾无果后，我又一次他么的放弃了。

Serverless 厂商

这次是想把 SSR 迁移到 Serverless，应用已经做了一些改造，成熟的厂商屈指可数。

• AWS 不考虑，虽然在香港有节点，但那 CDN 在国内用起来简直就是减速 CDN
• Google/Azure 也是离得远
• 就剩下阿里腾讯两家可选了

先说两家的特点吧。

腾讯云

1. UI 相对简单些，特别是「Serverless 应用」这个功能做的最新手很是友好，可以让你对一些资源服务不甚了解的情况下帮你打包一套操作流程
2. 和 Serverless 社区官方合作，承包中文站（看起来是钱给够了），做了一些跟自家产品配套的组件
3. 有集成社区存储库的能力，可以自动监听 GitHub 指定分支代码的变化自动部署
4. 营销文比较多（垃圾资料比较多）...

阿里云

1. 可以配置单实例多并发，这个能力相当实用啊，能降低冷启动频率，IO 场景还能减少耗时，当然，还能省钱
2. 不走社区 serverless 合作那条路，而是自己搞了一套 CLI ，然后这套 CLI 也特么废弃了，又跟一个新的社区项目 Devs 合作，这家公司我简单看了下，差不多也是杭州嫡系的，或者就是之前阿里的人搞的，社区参与度不高，也不够国际化，但是似乎也还行
3. 文档真是一团糟，和字节内部的飞书有得一拼，处处处处处处都是各种信息不对称，你需要核对搜集多方资料才能确定一个概念表达的准确性，我快被文档气死了
4. 社区非常难找到相关的最佳实践，我已经开启了 24 小时超级试错大法，也没让应用跑的起来

两家的共同点

• 最佳实践极其匮乏，所谓的 ”三分钟“ 营销文、DEMO、starter 项目全特么骗人的，真去跑一个生产项目，处处处处处处都是坑啊
• 文档！文档！文档！我再次感受到专业文档工程师的重要性，两家文档都是相当的杂乱，各种时效不一致的文档互相引用...唉
• 唉，连 Demo 都不完整，各个都是 HelloWorld，连个成功的 layer 配置都没见过

Serverless 哲学

Serverless 并不需要怎么个入门法，从技术上说就是更细粒度的运行容器。

Serverless 真正需要理解且去执行的是，它要求以一种异于传统的编程模型去实现程序。

为啥说是哲学呢，Serverless 像啥？

• 像程序中的解耦：一个函数只干一件事。（Law of Demeter）
• 像 immutable 的数据流哲学：有输入，有输出，无副作用。（Functional programming）
• 像互联网的万物共生：一切皆为 HTTPS。

适合与不适合

SSR 这种应用，本身是适合的，但得是足够简单的应用。

得多简单：

• 无状态（像有缓存业务就不行，状态必须另行他法，部分厂商支持 initialize 之类的初始函数，但也就是连连数据库之类的，云函数都有最长执行时长的要求，所以即便 initialize 也一定是是在 Serverless 的 ”事件周期“ 可接受的范围内的）
• 无 IO（要是想写点静态文件，又得传 OSS 去了）
• 依赖不能太多，否则冷启动的时长用户可能无法接受（我一个 Blog，打包后的体积都在 100M 上下，含 node_modules，必须含，又没法拆）

总体看来，对于绝大部分的个人项目、小项目，Serverless 并不适合，因为 Serverless 其实意味的是 Serverless 生态，是 + 云数据库、+ 云 Redis、+ 各种 PaaS 生态，而这些资源更适合为成熟的商业项目服务。

所以最后我决定，根据 “Occam's Razor”，我放弃 Serverless 了，等过几天俩厂商的便宜轻量机器出来了，就订台香港的迁过去得了。

迁过去之后

迁过去之后我将要：

• 实现一套新的基于 Disqus 的评论系统（通过一些代理设计保证国内可用）
• 实现一套基于 Instagram API 的相册
• ...

不说了，不用了，以后谁推荐我也不用了。