@woostundy 你的 QPS 没有增长，那么你是 gunicorn 的 worker 跑满了吗，要不然不应该线性增长吗？要不直接加大 gunicorn 的 worker 看看，反正你数据库又不是瓶颈

@woostundy 还有就是你发现 gevent 的 monkeypatch 用了不起效，很有可能是你已经载入了 Python 的底层网络库，那么 gevent 的 monkeypatch 就不起效了，monkeypatch 必须在网络库载入之前使用，否则无效。
requests 对 gevent 的兼容性挺好的，毕竟 requests 是一个纯 Python 的 http 库，gevent 能完美支持的，一般不支持的是因为底层用了 C 库，monkeypatch 没法对这些库进行打补丁导致，具体例子就是 mysql-python。

楼主你需要同步返回给客户端吗？假如是的话，flask 是解决不了这样的，哪怕是 Gunicorn + gevent 也是一样。毕竟你用了大量的同步库，比如数据库连接什么的，那 gevent 肯定也是堵塞的。你可以做的只有用另外的语言或者框架来替代这个 API，比如上面封装一层 Tornado 或者 Golang 写的模块。
如果是异步的接口，那么你可以将所有请求扔到 celery，由 celery 处理，celery 来起一个 gevent 类型的 worker，gevent 的 worker 处理所有的网络请求，完美兼容你的 requests 逻辑。前提是你的接口是异步的，celery 的 worker 能独立地返回请求给客户端。

《 Linux 多线程服务端编程》可以帮到你，不过不要将协程什么的想象得如此美好。

@Ehco1996 小心太快了账号被封，我以前也搞过，实在是太苦逼了。我的方案是用 headless browser，成功率还高那么一点点。楼主可以参考一下。不过支付宝还有风控系统，一旦他们觉得你异常（我是不知道具体的指标了），你的账号就会被封，小心点吧。

@verrickt scala 不说，kotlin 其实是从 C#这边吸收特性。不过 JVM 的底层优化的确好，毕竟这么多公司在用。不过啊，Java 实在是太啰嗦了，我真希望 Java 能多点语法糖，不要动不动就要写大量的配置，xml，真的很累。

你是要开发实时系统吗？楼主你说的都是软实时的，简单来说，内核对你的进程进行调度，那么你的函数执行时间上限就有可能会超过了。真要硬实时的话我还是建议你用 C，然后老实地独占一个核心。

@NSAtools 四大行不缺这点钱嘛，反正对公业务利润高着呢。你看看工行，中行什么的，不存个几十万，压根提都不提信用卡的事。

@est 萝卜青菜各有所好。我只是觉得极大多数情况 Gunicorn 都是够用的。
比如我之前负责的项目，压根就不需要应用自动 rotate 日志，日志都是 syslog 跟 elk 做的。

其实 Gunicorn 的性能也不差，部署起来超级简单的，为什么不用这个呢？而且你觉得性能还需要提升还可以将 Gunicorn 自带的 worker 换掉，换成 bjoern 或者 meinheld

我只想说，负载均衡没有你想象中的那么好搞。你们业务能忍受多久的业务停滞，mysql 的主从可不是高可用，高可用是另外一套方案，但是高可用又会引起写入性能下降，你们能忍受吗？
机器自己负载低的时候用跟生产环境高负载的情况下用是不一样的，你们既然买 20 台，我想负载肯定不低，你们要做好这样的准备。
还有一点就是，你打算投资多少钱打造你们的运维团队？指望一个人全部管过来？不实际的。你们没有历史积累的运维工具，那么只能靠人力去堆，机器的钱是少啊，不过我怕你之后花在运维上面的钱轻松超过你买新机器或者上云的钱了。

不删，不缺那点空间。而且我装的 Python 在 brew 里面

@piaochen 他们提供 perform_create 这样的钩子，你重写这个钩子就好了，update, delete 的都有，具体请看文档

@piaochen 平心而论，drf 还是蛮便捷的。一般接口直接 Model, ModelSerializer, ModelViewSet 三连就好了，当然你有特殊校验就得你自己写 Serializer 来校验了，跟数据库相关的需要在业务层进行校验。

我来一一回答
@zonghua 先看楼主的说法，他可不仅要将数据校验放 view，他是想要将一部分业务逻辑也放这里，这个才是我要否定的。所有东西都放第一个地方，重构火葬场

@qq12345454 drf 默认校验了一部分数据，不过只是我觉得它实现的跟我想要的不一样，我更倾向于在类似中间件之类的部件做完这些。将所谓的校验逻辑从 view 里面脱离出来，可能更倾向于 view->validation->model/bussiness

@timle1029 嗯 Django 不是一个 MVC 框架，我认同，但是哪怕 MVC 也好，MVT 也好，Controller 对应的部分也不应该写业务逻辑，这个没毛病吧，Controller 应该是传递对应的参数给 Model 层，让 Model 层对应的模块去处理业务逻辑。此处我会将数据校验也当作一部分业务逻辑，这才是我认为 drf 的数据校验放在 view 不符合我个人的地方

一听就是坏习惯，View 就是表现层，我觉得他们做数据校验都算多了。你还要将业务逻辑写在里面。你应该封装一个 Service 类，这样你不管换什么 View 都能很好地复用。
项目的话应该参考 sentry 就差不多了吧

windows 下面请用 anaconda 来安装 python，解决你绝大多数包安装不上的问题

Redhat 对编译有优化，这个是出自 CentOS 以前维护者的口中，他们说自己编译出来的东西就是跟 Redhant 原生的有一些效率上面的差距。
Redhat 的人不单单是回答问题以及修 bug，还有就是对生命周期里面的系统进行维护，比如对一些新内核的特性，Redhat 会将它们 backport 到低版本的内核上面，让客户不更新内核也能用上新特性。