有关 LoCyanFrp 未来的发展方向和技术变迁的一点说明

引言

我是 LoCyanFrp 的现任站长，夏沫花火zzz🌙。
过去的两年间，LoCyanFrp 完成了大量的升级，正式发布了第二版，并得到了广大领域用户的青睐。

我们一直牢记我们的初衷，秉承着一颗做公益的心，维护着 LoCyanFrp。三年间，LoCyanFrp 一直保持着全公益的运营模式。
在这片文章里，我想谈谈我对 LoCyanFrp 接下来的规划，以及进行一部分答疑。

现状

LoCyanFrp 从 2022 年 4 月起，一直运营至今。如你所见的，我们一直是全公益的运营模式。
尽管期间我们遇到了一些难点，但是我们没有放弃，没有选择跑路，也没有选择改变为商业运营模式。

迄今为止，我们已经成为业内第四大的 Frp 内网穿透服务（按服务用户量计数）。我们拥有将近 30k 的用户，用户创建过 104k 以上的隧道，每个月传输 TB 级别的数据，与官网宣传的保守统计不同，我们实经传输数据量可能超过 100 TB。
在三年来，我们为用户提供了尽可能稳定，低成本的流量穿透服务。

稳定的背后

海量的数据传输，意味着对服务的可靠性的依赖。我们拥有着上万的用户，我们是如何保障我们的服务的呢？请听我道来。

首先，我们基于 Frp，由于 Go 语言有着在 IO 上的一些优势，使得我们的服务能够拥有优异的包转发性能，能够为用户带来高效的流量穿透。当然，也有其他语言在网络传输上具备先天优势，不过我们最开始是基于现成方案制作的，所以一直沿用至今。
其次，我们通过使用 Spring 框架自研后端，借助 JVM 和 Spring 的性能和调度优势，我们的后端每天处理超过 600k 的请求量，也丝毫不显逊色。
通过结合两者，我们实现了一套高效的系统，为用户提供更好的体验。

然而，光有性能是不够的。

或许用过同类产品的用户可能遇到过这种尴尬情况：由于主控服务器挂了或者维护，导致节点服务无法获取数据，从而无法正常使用服务或启动节点服务器。
我们的节点服务则不同，在设计上便可离线运行，即使主控服务器离线，也能维护现有状态运转或启动。通过这样的设计，即使我们对主控服务器进行维护，也不会影响节点端的运作。

另外的，为了保障我们的服务不受渗透攻击、拒绝服务攻击（DDoS）、泛洪攻击的影响，我们对全部业务采用容器化部署方式，且具备完善的 WAF 规则，可拦截大部分恶意流量，并且我们使用了 高防服务器 + 安全加速 的组合，有效防护 DDoS 和 CC 等常见攻击手段，并实现了全球的高速访问。我们在后端上也做了严格的权限控制，并在近年接入了人机验证、行为检测等技术，且实现了 OAuth 2.0 以精细化对权限的控制并进一步控制 API 访问，有效保护用户的账户数据。

感谢这些服务商，它们为我们的服务提供了高速稳定的服务（不分先后）：

• 阿里云
• 括彩智能 CDN
• 木韩网络
• 火山引擎
• 百度智能云
• Cloudflare
• 湖南裕米云数据科技有限公司
• 武汉新软科技有限公司

感谢这些产品为我们提供了高效的服务器管理和解决方案：

• 1Panel
• JumpServer

LoCyanFrp，还会有下一代吗

LoCyanFrp 目前看来是一个很完善的平台，它拥有自研的前后端面板和节点控制程序，并具备强大的服务能力。
但事情并不会这么简单，我们还有很多没完成的事情要做。在不久的将来，我们会一一实现我们的 TODO，真正做一个用户友好的、功能健全的穿透平台。所以，先不要着急，在下一步我们并不打算推出 LoCyanFrp 3，因为这是极其不负责任的——我们还有很多的事情要做，还有很多能够做的更好的地方，既然如此，又为何着急心切推出一个全新的大版本？

或许 LoCyanFrp 会有下一代，但不是现在，也不是不久后。

关于技术栈的选择

或许有一些开发者会好奇，为什么我们会选择 Spring，而不是 Gin，明明 Frp 本身就是 Go 写的，同样的技术栈不是更好维护吗？
事情并没有看起来这么简单。

首先我们先来谈谈，为什么选择了 Spring。

如你所见，Spring 是一个老牌的框架，你别看它老，正因为老，经过了无数使用者的考验，我们才选择了 Spring。我可以直接举一个例子：淘宝。淘宝的后端最初是 PHP 写的，但最后还是转向了 Spring。与 PHP 比，Spring 具备更完善的 REST API 实现，更高效的处理方式和更完善的生态链。不只是淘宝，阿里系的大部分产品都使用了 Spring。

另外的，Spring 具备有一套完整的分层，如控制层、服务层等，在每一层开发无需关心其他层的实现，这是选择 Spring 的理由之一。
以及，Java 在学习难度和上手难度上，对新手是比较友好的，无需很深入的理解，就能够写出一套完整的服务。我们的原站长刚开始编写第二代 LCF 后端时并不会 Java，他也能写的有模有样的。

Spring AOP 为我们提供了一个相对于中间件更强大的剖面系统，可以让我们根据需求打造不同的功能。

基于如上还有很多其他考量，我们选择了 Spring 而不是其他技术栈。

接下来，让我们谈谈其他技术栈。

为什么不是 Go 的 Gin？

Gin 固然是一个优秀的框架，但经过考量我们最终没有选择 Gin。

首先，Go 与大多数语言不同，它的错误处理有些独特。对于习惯了 try...catch 的我来说，转换到 Go 语言的错误处理思路非常不友好。以及 Go 脆弱的稳定性：我只是不小心写错了非常小的一个逻辑，你却让我的服务整个“panic”，造成整个程序的崩溃，进而导致整个服务体系崩溃，这很明显有违我们保障服务稳定性的初衷。尽管 Gin 提供了统一的错误处理机制，但你如何保证其他部分一定不会 panic？
其次的，我们开发组里面对 Go 的了解程度并不深。老实说，我以前完全没有接触过 Go，对语法一概不知，也没有任何实操经验。而我做过一些 Java / Kotlin 的开发，对于选择一个毫无把握的语言和框架作为服务基础，我是做不到的。当然我们的友商也有在使用 Go + Gin 的方案，不是说不好，而是不适合我们。

以及，我真的很不喜欢 Go 的 public 和 private 机制和命名法。

那，其他的呢

有人和我们提过其他语言，最多的当属 Rust 了吧。

我倒要好好说一说为什么不使用 Rust。

Rust 凭借自身的优势和各种其他因素，似乎受到很多开发者的追捧。
但我并不喜欢这门语言。我没有写过 C/C++ 这类较为低级的语言，主要还是写一些中级和高级语言，Rust 的语法对我来说非常不友好。
另外的，Rust 自开发组一直到社区的高傲的态度，实在无法令我接受。或许 Rust 是一门好的语言，抑或是高效的语言，但我无法认同它——我遇到过不少的开发者，无脑的吹捧 Rust，并一踩一捧的贬低其他语言，或是故意引战。
况且，Rust 给我的感觉，并不是一门稳定或者具备有企业级能力的语言，至少现在不是。如果你直接和我提起 Rust，我想不到一个完善的 Web 框架的名字，但 Java 和 Go 我起码能想到一个或两个。哪怕是 Node.js，我也能想到 Express 亦或是 Koa 这些框架。基于这个原因，Rust 成功的被 pass 掉了。
我们可能会用 Rust 做启动器，但不会用，至少现在不不会它来做后端。

上面提到了 Node.js，如果你问我为什么不用，那我会和你说，我们有部分开发成员代码习惯并不好，写 JS 的话后续因为动态类型绝对会炸。什么？你和我说 TypeScript？如果你很喜欢做类型体操，那我也不反对，但是我不想要在我的代码里包含如此多的毫无意义的类型定义。如果你不使用类型检查器，那 TS 的类型功能也完全是个摆设。如果你和我说那 Java 不也要声明类型，那我会和你说：拜托，请你自己去写一下 Java 和 TypeScript，你就知道 TS 的类型系统有多令人恼火了。

关于语言和框架的讨论到此为止，点到即可，我也不想引战，只是单纯发表我的观点。

未来的一些规划

在未来，我们会逐步实现这些功能：

• WebAuthn 无密码登录
• 违规使用审计与计费
• 节点详细统计数据界面
• 捐赠节点可视数据面板
• 定制节点管理面板
• Eda 功能的增强

是的，我们打算对违规使用进行计费，不按要求使用，我们为什么一定要给你免费提供服务呢？
可能还会有更多功能，敬请期待。

马上就是 LoCyanFrp 的生日了，基于各种因素，我写下了这篇博文。这些看法也不一定全对，欢迎你在评论区评论，纠错或提供建议。