@vegito2002 其实大学多接触点象牙塔的东西挺好的，毕竟工业界也需要象牙塔的理论作为支撑。而且象牙塔的东西搞不好就向工业界扩散了，到时就成了自己的优势了。
好比以前都是吹面向对象，现在连前端都鼓吹函数式编程，这在我看来就是象牙塔向工业界的传播了。

maven 不是都用 tomcat 跑？

@wsgzao 你这这些问题，我只能说能解决一部分，但是不能根本解决，毕竟你的 IO 差，怎么调优也没办法啊。我这配置是 JVM 的参数调优，主要是增大 Heap 以及使用 G1 的垃圾回收算法，以起到缩小 STOP THE WORLD 的时间。当然如果你的内存很大，我觉得你可以调高 heap，然后关闭自动保存，有一定的成效。Pycharm 对 GPU 这方面要求应该不高，毕竟 openjdk 的光栅化都不如 oracle jdk。现在都改用 openjdk 了，使用起来也没什么影响。你的 IO 差大概只能寄托于你们系统管理员了吧。

custom vm option:
-Xms1024m
-Xmx2048m
-Xbootclasspath/a:../lib/boot.jar
-XX:ReservedCodeCacheSize=256m
-XX:+UseCompressedOops
-XX:+AggressiveOpts
-XX:+UseG1GC
-XX:+AlwaysPreTouch
-Dide.no.platform.update=true
懂的话就拿去用，充分利用系统资源，减少卡顿

以上的均不对，community 版本在企业也是能用的，前提是你们公司的年营收不超过 100 万

做什么都可以，只要你愿意付出对应的努力，若是学历是硬伤，那读一个博士不就行了。世界本没有什么行还是不行，倒是你现在要去找对应的工作比较难，你要付出比较大的努力，而且是非常大，若是别人本科 2 年能找到这样的工作，你怕是要 4 年

@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 台，我想负载肯定不低，你们要做好这样的准备。
还有一点就是，你打算投资多少钱打造你们的运维团队？指望一个人全部管过来？不实际的。你们没有历史积累的运维工具，那么只能靠人力去堆，机器的钱是少啊，不过我怕你之后花在运维上面的钱轻松超过你买新机器或者上云的钱了。