Ask HN：用无服务器技术构建本地隧道是个馊主意吗？
1 分•作者: hussachai•6 个月前
使用无服务器架构，选择非常有限，而且这项技术被牢牢锁定。虽然某些部分可以移植，但大部分不行。我通过 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.