我感觉不是太理解你这个 web service 的定义
一般作为 web service，不是常驻一个服务端进程，一直处理传过来的 http request 吗？

【 在 eGust 的大作中提到: 】
: 我的实现还是基于 web service，对 lambda 的 event 进行转发。本地启动服务的时候，也能感觉到不是马上就起来的，所以 web service 本身的初始化也是占用不少时间的。如果直接处理 lambda event，就能把这部分时间省下来，缺点是直接绑 aws 上了。这个目前来说我觉得不重要
: 乙簿褪谴蟾攀砸幌拢懈龈拍疃选
: 这方面可能 node 还是有优势吧，另外一个用 rust 写的服务，冷启动也要 1s+ 才返回结果。不过做的事情不一样，不好直接比。基于 web service 的实现，本身服务的启动速度非常敏感。而对传统的 web 框架来说，服务启动的时间不敏感。我回头还得再试个 py，这样做对比的时候有
: ...................
--
FROM 59.41.68.*

用 node 做示例的话，应用大概是这样的
// app.ts
import fastify from 'fastify';

export const app = fastify();

app.get('/foo', async () => { ... });

app.post('/bar', async () => { ... });

// standalone.ts
import { app } from './app';

const main = async () => {
  await app.listen({ host: ..., port: ... });
};

main();

// index.ts
import awsLambdaFastify from '@fastify/aws-lambda';
import { app } from './app';

export const handler = awsLambdaFastify(app);

这样本地开发，或者部署成单独的 http server 的时候，用 standalone 来启动应用，这种情况下用不到 index.ts。反之 aws lambda 用的话，就不需要 standalone.ts，aws 会调用 index 里的 handler。

【 在 keygen 的大作中提到: 】
: 我感觉不是太理解你这个 web service 的定义
: 一般作为 web service，不是常驻一个服务端进程，一直处理传过来的 http request 吗？
:
: ...................
--
修改:eGust FROM 222.153.59.*
FROM 222.153.59.*

了解

【 在 eGust 的大作中提到: 】
: 用 node 做示例的话，应用大概是这样的
: // app.ts
: import fastify from 'fastify';
: ...................
--
FROM 218.17.141.*

这些都是比较具体的问题了，我们公司生产环境能用上 container 还有很长一段路要走

如果是基于 k8s 的话那自然是没问题的

另外能做成 serverless 的服务相对来说应该比较独立，规模不至于太大，功能也不会太复杂，我觉得用什么语言问题不大

【 在 keygen 的大作中提到: 】
: 噢，你说的是 serverless
: 我们是传统的写个 service，让它一直跑。跑在自己 DC 类 k8s 集群上，实例在更新之前一直存在。
: lambda 如果保证比较稳定的输入量的话，一直 hot 着应该还好。或者自己写一个定时请求保活？
: ...................
--
FROM 203.184.25.*

没特殊需求，选大路货是最合适的，除非你是老板愿意为个人喜好付费

【 在 eGust 的大作中提到: 】
: java 当然也不是不可以，只不过我个人不太喜欢
--
FROM 106.120.46.*