阿里云腾讯云也不用自家的云解析。
不过用别家的，可能是历史遗留问题吧。

我也不是否认异步对性能提高不大，中间件，数据库这种基础组件，当然应该对性能有更高的要求。也肯定是需要使用异步的架构。
因为异步往往更难以管控，对于普通业务代码，还是要根据实际的业务量来做权衡，平衡性能和可维护性。

@signalas1 同步和异步的区别，只是说一个排队，一个满了就关门，但是如果后端（数据库）慢的话，其实对客户来没区别，都是不能服务。只是说异步的 QPS 看起来大而已，对于用户来说，处理时间超过 30s 就基本没意义了。

至于线程的开销，真的没那么重要，后端（数据库）的速度才是决定性的。如果只是从 redis 查缓存，那同步也可以很快。

我说的主要是比较多写入的场景，这种对数据库要求比较高。当然，现在都是分布式数据库，想扩容都是很简单的事情。

之前看过博主写的 健身一年，就未再关注，现在再看，文章都很有启发，文笔也很好。

支付宝官方已经给出“预测”，一年 30 块钱，你自己去看一下再想想。相互保最大的缺点是没有法律和保监的监督。

问题不大，所以到底是你之前做了什么？

@hantsy
至于性能问题，其实都不是大部分应用担心的，要不然 PHP 就不会在今天还在大行其道了。甚至 Mysql 都要给 MongoDB 让道。特别是现在 K8S 微服务，很多都是靠弹性伸缩就足以提供更高的性能了。

用 netty / webflux / vert.x 高性能只有一种可能，就是全流程无阻塞调用，包括没有本地 IO 调用，没有 Mysql 调用。全部调支持异步的 Nosql，性能才能体现出来。如果调了 Mysql，压测 TPS 肯定是 Mysql 先挂了。

@hantsy #10 响应式编程，没问题，但是必须和传统模式混合，比如 java stream 就非常好。但是 webflux 和 netty 接合之后，就强制要求全流程上 stream，复杂的逻辑下，代码复杂度上升不知道几个级别。

响应式编程想把所有的输入输出都流水线化，后面的流程的输入是上一个流程的输出，想法是很好的，但是现实不总是这样。

举个例子，
我现在需要在 A 库查一个 List A，然后遍历 List A，在 X 库逐个查询，填充每个对象。同时，我在 B 库再查一个 List B。同时，我再在网络（另一个微服务）查一个 List C。然后把这些数据发送到一个数据库 D。

请问你用 webflux 能优雅的写出来吗？要套多少个 zip ？如果我查 X 库有些会出错，有些不会，要 fallback，怎么加？插入 D 数据库异常了，怎么准确地 fallback 到一个 checkpoint，怎么做事务回滚？如果在 A、B、X、D 任意一步出错，我想重试流程，应该在哪里加 retry ？要加多少个 retry ？如果我想 debug，我怎么知道我执行到哪行代码？调用的堆栈是怎么样的？最后，你写出来的这种带着无数嵌套，zip 的代码，你的同事看得懂吗？

如果用 vert.x 异步，上面的流程可以无歧义的用多个回调来表示出来，至少还看得懂，只不过是更加难看。

@oven 腾讯云其实有很多数据库的组，最好的应该是 TDSQL 的，技术肯定没得说。其他的可能还要考虑一下。

@hantsy vert.x webflux 都一样，想法很好，但是不实用，配套也不完善。

最简单的，90%代码异步不异步性能都一样的，只有那些网络 IO 的异步才有意义。

所以强制使用一个不完善的模式，真的很蛋疼，包括但不仅限于 N 个异步接口同时调用，结果需要合并。错误处理。重试机制。fallback 机制。跨作用域变量引用。

数据库还不错吧，基础架构感觉也是搬砖，BAT 应该都开不到 50W

名词我有点忘了，可能有点混乱

你看一下小程序的登录机制，登录的时候，小程序生成一个和用户有关的唯一码 appid，发给服务器，服务器再拿 appid 和 token 去微信服务器拿一个临时的 code，然后服务器可以考虑做或者不做处理

首先，市场上面不是你一个人在做机器学习，所以，无论有什么技术面，基本面的优势，早就被人捷足先登了，股价已经波动到相应的水平。
所以，散户做股票机器学习没有意义的，很多时候好像有利好消息，会涨，那不过是庄家在割韭菜而已。