问HN：使用无服务器技术构建本地隧道是个坏主意吗？
使用无服务器架构时，选项非常有限，技术也被锁定。虽然某些部分是可移植的，但大多数并不是。我使用的是基于WebSocket的二进制协议（Protobuf）。是的，它的速度比像TCP这样的低级本地隧道服务要慢，但对于大多数场景来说，速度还是足够快的。
扩展是一个主要挑战。大多数无服务器计算引擎依赖于内部负载均衡器，并且所有实例都是短暂的。这意味着实例之间的通信是不可能的。可以通过像Pub/Sub这样的消息总线来实现扩展，但这又引入了另一个问题。发布到主题的请求和响应会在所有活动实例之间复制，这样效率很低。
其他令人烦恼的限制包括计算过程绑定于请求，并在请求完成时立即结束。另一个问题是需要处理由于实例的短暂性而导致的订阅泄漏（我真的很讨厌这一点）。
缺点：
- 扩展效率低下。
- WebSocket是有状态的，这违背了无服务器架构成本优化的目的。如果客户端保持连接，成本可能超过运行专用服务器的费用。
- 协议和平台选项有限。
- 强烈的供应商锁定。
优点：
- 性能对于大多数用例来说足够好。
- 扩展和基础设施完全由服务提供商管理。
- 无使用意味着无成本，同时服务仍然可用。
- 小规模使用通常是免费的，因为大多数云服务提供商提供免费套餐。
我认为将其构建为SaaS是个坏主意。这并没有降低成本，实际上还增加了成本，并且增加了复杂性。我认为在今天的市场中，以SaaS形式运行它很可能不会盈利。
话虽如此，你认为任何组织会对开源版本感兴趣吗？它是可扩展的，除了初始设置时间外，运行成本为零，如果他们能够妥善管理网络访问，安全性可能更高。我甚至不确定是否有人愿意为此支付小额费用。
也许我在构建垃圾。我在这里询问是想知道这是否可能是某人的宝藏。
查看原文
With serverless, the options are quite limited and the technology is well.. locked in. While some parts are portable, most are not. I use a binary protocol (Protobuf) over WebSocket. Yes, it'sslower than local tunnel services that operate at a lower level like TCP, but it's fast enough for most scenarios.<p>Scaling is a major challenge. Most serverless compute engines rely on an internal load balancer, and all instances are ephemeral. This means instance-to-instance communication is not possible. Scaling can be achieved through a message bus like Pub/Sub, but this introduces another problem. Requests and responses published to topics are replicated across all active instances, which is inefficient.<p>Other annoying limitations are that the compute process is bound to a request and ends immediately when the request completes. Another is the need to hack subscription leaks caused by the ephemeral nature of the instances (I really hate this).<p>Cons:<p>- Scaling is inefficient.<p>- WebSocket is stateful, which defeats the purpose of cost optimization for serverless. If a client stays connected, the cost can exceed that of running dedicated servers.<p>- Protocol and platform options are limited.<p>- Strong vendor lock-in.<p>Pros:<p>- Performance is good enough for most use cases.<p>- Scaling and infrastructure are fully managed.<p>- No usage means no cost, while the service remains available.<p>- Small usage is often free, as most cloud providers offer free tiers.<p>I think building this as a SaaS is a bad idea. It does not reduce costs, in fact it increases them, and it adds significant complexity. Running it as a SaaS is very likely not profitable in today market I assume.<p>That said, do you think any organization would be interested in an open source version? It is scalable, costs nothing to run aside from initial setup time, and can be more secure if they can properly manage network access. I am not even sure if anyone would be willing to pay a small fee for this.<p>Maybe I'm building trash. I'm asking here to find out if it could be someone's treasure.