我之前有个想法是基于串流用来彻底解决给家人云修电脑的场景。
结合 Easy-GPU-PV 这个项目把显卡也虚拟化给 hyper-v 虚拟机，然后虚拟机给家人用，这样给家里放一个瘦客户端就可以了，配合 Tailscale + 自建 DERP Servers 组网。
瘦客户端可以是装 linux 的老笔记本，树莓派，甚至是电视盒子，拿来跑串流客户端就可以了。
既能防止家人在瘦客户端不小心安装流氓软件，也能把时不时要给家里人解决电脑问题的换成了解决 hyper-v 里虚拟机里的问题。

intel 跑 fyde os 或者 chrome os 不容易翻车，毕竟从统计上看 amd 的 chromebook 比 intel 少得多

@findex 你举的 Google Firebase 扣费案例其实套用到 COS/CDN 之类的也一样，只要在公网暴露，被 DDOS 要么下线要么花钱买高防。
至于“别人想给你封号阻断很随意”，要解决这个问题连机房托管恐怕都不行，只能走自建机房的路了。

“自己配置 k8s+容器就完事了”
即使是自建 k8s 集群跑应用，依然会面临 0 访问量情况下机器资源空跑的情况，我之前在的公司一年在公有云费用几千万，就是用传统自建集群方式跑应用，每个应用最少 2 个节点运行，但是应用负载情况非常符合 2/8 原则，在上班时间之外资源利用率非常低，整个架构设计非常有问题。
所以在我看来 serverless 是目前“0 驻留实例做到应用高可用”的极低成本方式。

自建集群还会面临各种问题，简单列一下就有：
1：服务器的软件安装升级维护、漏洞响应修复、参数调优；
2：服务高可用集群搭建、伸缩实现、演练验证；
3：监控平台搭建、监控指标采集、监控告警建设；
4：日志平台搭建、日志采集、链路追踪搭建；
5：注册中心、配置中心、分布式定时任务系统等的高可用建设；

要做到以上要求，可不是“就是多耗费点精力 devops”那么简单，是要运维团队值班的。

而在 serverless 使用 docker 镜像运行，是为了可以自主控制应用环境（比如要部署漏洞扫描器），同时又摆脱云厂商那些拉跨的设计(serverless framework 、layer 等)锁定。

目前我工作中发现不适合 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 千），云厂商的数据库代理早点接入测试吧。

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

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

快速出活而且维护频率低的用 https://github.com/directus/directus ,设计好表结构一天出成果
不断迭代的用 nest.js

Angular 简单啊，一两天上手不是什么问题，还带 AOT ，在我看来这才是真正的企业级框架。
看一下官方一个小案例 https://angular.io/generated/live-examples/reactive-forms/stackblitz.html 代码结构工整又符合直觉。

再看看隔壁 React 的帖子 https://v2ex.com/t/840200 一个发布了 9 年的框架，在 2022 年状态管理这个问题上，居然有 20 个库在解决，不觉得很搞笑吗？

当然最简单的还要数 amis ，纯 json 定义页面，非常无脑，做东西贼快。

上云的话 all in serverless ，连 k8s 都不需要，打成 docker 镜像丢上去，一个应用 /函数分配一个域名，全部走 http api 调用就行了。
配置中心也可以做轻量甚至不需要，丢环境变量就可以了，稍微自动化一点就是去配置中心取出来丢环境变量

莫桑石戒指，百元级别还带证书

手工管理吧，看你描述 Gitee 还算良心，不是先把东西卖给你们的那种。

在我有限的经验里，如果组织层面想做点改变去提效，那最先改动的应该是组织架构。组织里没有对应人才，又不肯招人，那就靠得你们偷偷自学 Python 然后惊艳所有人了。

现在 Serverless 都支持了使用 Docker 镜像部署，感觉没有什么绑定不绑定的说法了。核心理念是按量付费，传统项目你的应用怎么说也要 2 个不同机器上在跑才叫高可用，而且应用流量也有高峰低谷时间，低谷的时候就要考虑如何避免浪费资源。在 Serverless 上可以是 0 实例做到高可用，虽然是云厂商在资源上帮你做了兜底，但是你自己节省是实打实的。

传统部署你得考虑这些：
服务器的软件安装升级维护、漏洞修复、参数调优 -> 服务器都没了，注意一下 docker 安全就好，用一下 docker 镜像安全扫描和代码依赖扫描可以解决；
服务高可用集群搭建、伸缩实现 -> 丢个函数上去，配置一下伸缩策略就搞定了；
监控平台搭建、监控指标采集、监控告警建设 -> serverless 可以配置指标和告警，比如 web 函数使用云 api 网关，把 api 采集到的指标做到告警里；
日志平台搭建、日志采集、链路追踪搭建 -> 直接往控制台输出，serverless 一般会集成自己云的日志服务，简单配置就可以让开发登录来排查日志了；
高可用的注册中心 /配置中心 -> 一个函数分配一个域名，配置塞环境变量里，部署时候动态写入就好；
高可用的分布式定时任务搭建 -> serverless 自带定时器；

搞定上面这些你得算下要招什么人来持续维护，成本有多少，搞定就可以下云防止云厂商绑定。

@mineralsalt CNVD-2021-29068 微信 Windows 客户端远程代码执行漏洞。
抛开腾讯系软件扫用户文件的历史，往程序里塞入的东西越多，暴露的攻击面也就越多，微信这种大而全的东西还是让它在虚拟机里躺着吧

@rsonghao 针对微信这种国产应用，我现在是放虚拟机里跑的，哪怕宿主是 windows 也会单独开一个虚拟机跑国产应用。

我现在有 2 种新思路，一种是台式机跑 windows ，结合 Easy-GPU-PV 这个项目把显卡也虚拟化给 hyper-v 虚拟机，再加上 tailscale 组网和串流比如 parsec ，不仅自己能用，还可以给家人用，这样给家里放一个瘦客户端就可以了。瘦客户端可以是装 linux 的老笔记本，树莓派，甚至是电视盒子。既能防止家人在瘦客户端不小心安装流氓软件，也能把时不时要给家里人解决电脑问题的换成了解决 hyper-v 里虚拟机里的问题。这条路我验证通了，就差寄个瘦客户端过去了。


第二种思路是宿主安装 chrome os ，在 chrome os 上跑微信安卓版，日常软件就在 linux gui 子系统跑。这个思路还没验证完。

电子产品不是刚需别买，买了必降价，没有需求想买就是中了消费主义陷阱，有钱不如买个显卡锻炼下。


我是一直没有 mac 需求的人，所以一直没买。

以前读书的时候又菜又喜欢研究 crack ，一直用的 windows ，在内存只有 768MB 的时候就开始用 vmware 了，光是一个 crack 就让我学了不少东西：OllyDbg 调试程序、抓包、给加壳的程序打内存补丁、CheatEngine 自己做单机修改器、提取程序资源自己做汉化、虚拟机组网等…好多技术都是在 windows 里学会的。

第一台自己的笔记本是小米 pro ，板载的 16g 内存，6999 元，同期 MacBook Pro 15 寸 2017 16g + 256 大概要 1.8w 。
第二台笔记本是 xps 15 9570 ，丐版 7999 ，自己换了 32g + 2t 固态 总共约 1w ，同期 MacBook Pro 15 寸 2018 32g + 2t 大概要 3w 。
现在用 Code01 直接上了 64g 内存 ，系统换 Manjaro 也一年多了，原生 docker 方案用起来就是爽，总价不超过 8k 。

mac 贵的地方带来的体验是什么？
软件生态：我用不上，安全性来说也是众生平等，比如不上监控你都不知道你运行的软件有没有读取你的 ssh 私钥
屏幕色彩：我外接 27 寸显示器
雷电口：我用不上
触摸板：我直接外接键鼠

如果上面这些体验你也一样没有感觉，但是还是想用 mac ，我建议你去玩一玩 OSX-KVM ，就算失败了也积累不少虚拟化经验。

都是大家加班出来塞进去的屎

监控告警想做好,CMDB 少不了,最后演进的路线就是 AIOps,这块坑还是挺大的.
我之前试用腾讯蓝鲸那套体系发现真的是又菜又爱吹,混乱无比,真正用起来那叫一个难受.
CMDB 项目两万多的提交大部分都是写废话(新增 /修复了 xx 条件的查询支持),还不如用低代码配个 CURD 界面 + 定时器采集.
流程编排又菜 bug 又多,还不如用 node-red 拖拉拽结合 ansible 简单高效.

可以考虑做"云的最后一公里",整合多个云平台的监控信息.

目前看来开源的类似项目有滴滴的夜莺,商业项目有睿象云.

不过我之前用下来这些告警项目还是比较原始,比如"一条慢 sql 根据调用的表能直接触达到具体的研发团队和相关产品的功能"满足不了,更别说结合其它链路的日志分析出一个 502 背后可能产生的原因,也就是偏向 AIOps 部分

除了消息队列和国内平台对接，https://github.com/directus/directus 都符合。