这是一个创建于 310 天前的主题，其中的信息可能已经有所发展或是发生改变。
1.装 nodejs 环境然后 build 完直接服务器 node
2.宝塔面板直接用 node 模块功能
3.pm2 直接跑
4.docker 跑 nodejs 镜像
5.k8s 集群部署 nodejs 镜像
6.服务器上直接 npm run dev
第 1 条附言 · 310 天前
综合评论，基本上 4 最优解，3 和 5 次之
 |
101
cloverzrg2 310 天前
docker compose build
docker compose up -d |
 |
102
zeromike 310 天前
我们生产环境：K8S 集群部署 nodejs
看你使用 nodejs 做什么了，做做接口转发，做做文件处理、定时任务，还是把 nodejs 服务作为主力服务在用，包括登录鉴权、数据库操作等需要管理状态和数据的服务了 部署简单，运维需要花时间和精力 |
 |
103
yzqn 309 天前
Jenkins 构建打包，静态资源加版本号上传 OSS ，网关代理 index.html 和静态资源
|
 |
104
crazyTanuki OP @yzqn devops 吧
|
 |
105
hanyuyu 309 天前
1 或 3 ，看是用來做什麼
|
 |
106
MEIerer 309 天前
4 啊
|
 |
107
lei737123456 309 天前
我们这里部署 next.js 项目，直接本地 build ，打 zip 包，scp 到服务器，然后 unzip ，再执行 next start🤣
|
|
108
crazyTanuki OP @lei737123456 单听你描述都觉得复杂
|
 |
109
lll5758 309 天前
6,主打一个我的开发机,就是服务器
|
 |
110
ada87 309 天前  1
@Jianzs 目前(刻意)没用工具和框架，代码方面和一般项目没有任何区别。配置方面，一次性劳动后，之后就是只用无脑 deploy 就行了，时不时登录下网页上切下版本就 OK 。
比如：这个网站就是几个纯 Serverless ，没有流量，所以可以不花一分钱白嫖免费额度，最高被攻击的时候也就几块钱，重要的是省时间，几年时间完全没有维护过服务器。 https://eedictionary.com/ 自己写代码时用这个 https://dev.eedictionary.com/ 你的这个 Pluto 感觉大部分功能云商都会自带。目前也有一些大点的项目，遇到的问题基本上都是思想上的，公用部分不好分，而且公用部分更新频的话，layer 管理起来也有点麻烦。 |
 |
111
wherewhale 309 天前
@Jianzs Serverless 要看你是基于哪个云服务，是否使用原生云服务还是只是用云服务器自己部署服务。
如果是使用原生云服务，主要一个问题就是，由于云服务的请求链条过于繁琐，响应很慢。而且 lambda 这种东西只是一个短暂的代码运行容器，代码要非常保证数据的一致性，要解决很多异步和并发问题。 |
|
112
wherewhale 309 天前
@Jianzs 目前 AWS 自己提供的页面服务 就算访问 DyanamoDB 或者其它服务 熟悉一下基本对用户来说没啥痛点
用第三方工具 一个要考虑的就是安全问题 我司应该是不会用第三方的 |
 |
113
Jianzs 309 天前
@ada87 太感谢了！我再去深入了解下云商的能力
你提到的公用部分不好分，Pluto 或许能够解决，Pluto 会通过静态分析的方式，把一个 FaaS 的依赖，包括常量、函数等，都自动打包到一块。这算是解决一个痛点？哈哈哈哈 |
|
114
Jianzs 309 天前
@wherewhale #112 感谢反馈！请求链条长是 FaaS 固有的问题，Pluto 会把一个 FaaS 依赖的函数打包到一块，而不是发布成多个 FaaS ，尽可能避免函数爆炸吧。 异步、并发问题，继续关注，感谢感谢！
serverless.com 不也是第三方工具？还是说？ Pluto 会是一个开源的本地工具，输入用户代码，输出要提交到云平台的 artifacts ，安全应该还好？ |
|
115
wherewhale 309 天前 1
@Jianzs https://docs.aws.amazon.com/zh_cn/serverlessrepo/latest/devguide/data-protection.html
AWS 本身开发 serveless 这块是有专门的安全保证的 可以参考这个文档 |
 |
116
junsongyoung 309 天前
1 、3 、4 、6
|
 |
117
GeekGao 309 天前
2 ，5
|
 |
118
Tomoko 298 天前 1
我最喜欢的是 cloudflare workers （不过阿里的 函数计算 FC 以及 AWS 的 lambda 尚未用过）:
1. 省去了服务器运维的复杂流程: 说真的，要我去维护并监控 Linux 服务器上的各种漏洞以及杂七杂八的问题，太让我头大了。光是十几个服务的证书续费就让我折腾的够久了。 2. CLI 很好用: 基本上 terminal 就能够完成所有的操作，不需要在网页上点来点去 3. 文档以及示例非常丰富: 各个云厂商的文档中，我最喜欢 cloudflare 的文档了（不知道是我的问题还是阿里的问题，我什么时候看阿里的文档，都一头雾水） 4. 每日 10w 次请求额度: 对于个人使用或者流量不大的网站，是完全免费的， 5. 免了翻墙这一步: 我搭的服务很多都需要访问一些被墙的网站，这对我挺必要的，不然在服务器上弄代理就很麻烦了。 不过也有不少缺点和限制: 1. 每次请求的时间限制: 免费版每次请求的 CPU 处理时间上限是 10ms ，这意味着对于流量较大的应用或需要长时间处理的请求，免费版可能不够用 2. 需要一定的学习成本: worker 的代码跟传统的 nodejs 代码是有不少区别的，，深度绑定后，也很难从 cloudflare workers 上迁移出来 3. 并非所有类型的服务都适合在 worker 上运行: 比如，需要长时间运行或者需要大量计算资源的任务可能不适合在这种环境下执行。 4. 还有很多很多，备案，合规性，国内的访问延迟以及加速方案什么的，也都要考虑... 场景不同的话要考虑不同方案。我是尽量能用 worker 的服务就用 worker ～～ 不过总的来说，上面只是我个人很主观的视角啦，我也还不是这方面的专家。不过我也想尽量多地对比不同的方案来刷新自己的认知。之后也要用用 FC 和 lambda 。 |
|
119
crazyTanuki OP @Tomoko 是不是类似小程序的云开发模式?
|
|
120
Tomoko 298 天前
@crazyTanuki 应该是的，这些系列方案都属于 serveless , 上面楼层也提到了。小程序开发方面，我也只是在上古时期稍微用过一下，没有实际用过。我只是将我这边的 cloudflare 使用的视角 POST 出来。
|
 |
121
jixiaopeng 292 天前
我用的 docker ，可以看看我的文档本地跑跑，https://github.com/huanghanzhilian/c-shopping
|
 |
122
67373net 273 天前
主要是 3 ，体感比较快
|
|
123
jixiaopeng 259 天前
|
 |
124
lyhq 242 天前
我之前就一直是 6.....
|
 |
125
andyC 235 天前
海外项目 firebase 国内项目 AWS lambda
|
Select Language