感觉可以再进一步实现一个匿名聊天平台，比如发表把这些网址再接入一个短链接平台，而前端则用 chrome 的方式自动解密。不过这样去中心的优势就没有了

@locoz pixiv 那个应该就是专门花钱买的反爬虫服务，我印象中几年以前，大概三四年以前，pixiv 的登录接口我自己是可以搞定的，然后到一两年前有需求的时候看了一眼发现搞不定了，似乎接入了谁家的反爬服务，但是 github 上还是开源了不少破解的东西。我感觉这样一来的话不如自己实现了，反爬做的再严密，数据价值到位总归有人会破开，不如自己做个简单点的原型，可以拦截 99%的菜鸟

@locoz 是这样，如果用登录限制的话，就像现在这样，不排除有认证用户爬取数据的嫌疑，因为本身就是提供数据服务的，对方对数据有兴趣也并不奇怪。比如现在的 jwt 登录策略，只需要拿到 token 之后就可以退出模拟了，感觉成本并不是很高。防 CC 的话感觉，因为我们现在 nginx 已经设置了一个比如一秒访问一次的频率，最多也是每分钟被访问 60 次，这种频次应该离攻击还远，不会被挡。

@systemcall 我明白了，百度才是反爬届的大哥大！

@abersheeran 我测试的是单纯的 echo server，没有接入其他任何服务，应该是受限于操作系统。但是具体原因也未必很重要，我只是压力能看到很实在的压力和延迟测试数据，只能说实机跑就是这种感觉，我只能根据结果选一个合适的

看到这个问题就想到，同一个 exe 安装包能在 2001 年发布的 xp 上跑，又能在 2021 年的 win10 上跑，真是太强大了

@charmToby 感谢！

@neoblackcap 我理解上 io 复用高效的原因在于避免了线程切换产生的时间切片问题，这是其一。
cython 相关的问题我不是很理解你为什么会指出处理请求时不能进行 cpu 密集操作，因为在线程与协程模型中 cython 反倒是不变的那个，因为是纯计算且不涉及 gil，两者使用上并无差异。

这里用这套工具当然不是为了压榨机器性能，只是因为各方面恰好合适而已，数据操作部分，pandas 可以帮我完成大部分处理，而少数没有覆盖的地方，算法用 cy 实现一下也很快。

另外我觉得用完全实际的项目流量选型也未必合适，毕竟即使是最沉重的 django 的单节点部署后响应能力也不是轻易就能达到上限的，毕竟实际业务当中能做到 1000qps 已经是大站了，而这个并发下显然瓶颈也不在 django 本身，它仍是堪用的。我只是觉得还是要以发展的眼光看问题，毕竟项目日活会逐渐增高，只是希望找一种转发效率和开发效率平衡的方式，不要框架消耗太高，也不要框架太难写导致开发缓慢

@neoblackcap 感谢回复，这个帖子基本上还是调研范围，毕竟已经有一个验证比较成熟的方案，想换框架是因为一些肉眼可见的好处（参数注入等），因为确实目前用的不是说不能用，但是用起来并不开心。路由表打开一看几十行，参数处理要写上千行，比如现在要重构了，让我再重新写一遍，肯定是不开心的。

异步的问题我觉得是这样，因为要频繁和数据库交互，IO 复用肯定比线程模型优势大，比如每次一个请求被访问，最基础的会产生一次权限表请求，然后业务方面或许会产生到不同数据表的若干次请求，比如这样的 10 个小请求，然后再加一次复杂连表计算，这个连表需要计算较长时间。那么理论上我当然希望这若干个请求同时发送，回调业务处理，让通信消耗的时间少一些，我觉得在这方面 asyncio 相比于线程模型要好。比如 django 用 wsgi 部署，echo 的通信延迟可能在几十毫秒的数量级，加入后端请求后在一百到两百毫秒，而异步可以缩减到个位数，django 的 asgi 我不是很了解

个人感觉，PC 的话不确定，服务器的话倒是安全？因为彻底关闭 ssh 以后实际上并没什么被攻击的入口，只能从第三方程序下手，而服务器上部署的服务非常有限，且运维对这些服务有很强的掌控，很清楚每一个服务在干什么。一些广泛使用的服务，即使是开源项目，也是久经检验的，比如 fail2ban 这种。虽然开源项目有恶性事件的记录，但是总的来说还是问题不大

@laminux29 大佬为什么提到大内存服务器的问题，我这帖子里没提到啥服务器的内容啊。。

@neoblackcap 大佬勿喷，当然是因为有不清楚的地方所以才来问的，我当然不是什么都懂，我只是说了我的逻辑，如果你觉得我逻辑哪里有问题可以指出，而不是像这样问我都了解什么。

关于第五点，我在楼上的回复里有过说明，我认为文件服务交给业务而不是 nginx 可以让部署更加方便。我再举一个例子是，实际服务里面往往也不是一个纯粹的 SPA，大部分内容交给 SPA 操作，但实际仍有可能嵌入一些单个页面，比如从外部（同事，或者第三方）引入一个独立的 html+js+css 结构的页面想要嵌入 SPA 的某个路由当中。这种问题当然有很多种解决方法，前端可以解决，用 nginx 的方法也可以解决，我只是觉得这种方式更直接，而且在我看来无论是文件服务交给 nginx 或者交给业务节点，并没有什么明显的 drawback 。

关于第六点，人非生而知之者，不能说不懂的就全部否掉不用了，总要慢慢学

@so1n 大佬能不能讲一下 logroate，我搜了搜 logroate+python 没搜到什么有效的信息。大概看下来这似乎是一个 linux 的计划任务工具，属于第三方进程监控文件，然后当文件过大时触发清理？按我目前的理解，如果想用这个记录日志的话，是正常使用 web 框架写程序，正常记录日志，然后再附加一个第三方的清理进程这样吗？

计算机系统的功底不扎实，当清理触发的时候，程序内的文件描述符会怎么样，会不会出现原进程都无法继续写入日志的问题。我看网上一些中文资料里写的范例，触发之后都是要重启 nginx 的

@abersheeran 显然不是线性的，实际测试中我用 gunicorn 启动的几乎所有框架都存在软上限，比如单进程 qps 可以达到 15k，四进程并不能达到 15k * 4，实际大概会达到 15k*4*0.5 这样，广义的说比如你有一台 64 核心的机器显然用 fastapi\aiohttp\index.py 这种也不能做到单机百万并发

@zhuangzhuang1988 有很多 py 依赖不能很容易的迁移，比如项目中一些科学计算的部分依赖 numpy 和 pandas，可视化方面 html 前端可以用 echarts 解决，图片就只能依赖 matplotlib 了，另外还有一些中文自然语言处理的内容，这些都迁移到 go 我头都要大了。还有有时要进行一些信息爬取，这个 go 应该也能做，但是还是 py 更熟悉一些，写得快

@abersheeran prefork 模型，不是单进程，不 fork 的话在生产中没有太大意义。详细可以参考，https://github.com/TechEmpower/FrameworkBenchmarks

@so1n
@abersheeran
starlette 我不太了解，他在多大程度上和 fastapi 耦合呢？比如我需要的参数注入，starlette 使用上和 fastapi 完全相同？

@abersheeran 前几天专门发了一个帖子测试，gunicorn+uvloop+aiohttp 的性能确实是没有 gunicorn+uvicorn+fastapi 的好，不过这个倒不重要，qps 也就是四万比五万这种感觉，需求是一种普遍性的快，而不是要快到极致，高出的性能完全冗余了。

@so1n
@wdhwg001
原来项目倒不是稀烂，因为性能需要要把 cpu 密集的部分用 cython 重写，想干脆把接口全重构一下算了，aiohttp 到 fastapi 确实不是太大的变动，选这个框架主要还是因为近期比较火，感觉以后也会一直是生态领头的工具，所以想学起来，像 starlette 这种主要还是用的人少，能不能完美满足需求倒是其次，项目不用大众化框架搭感觉没有钱途。切换 go 框架则是步子太大了，py 的业务生态要换到 go 怕是今年都做不完了