网关是网关，dns 是 dns ，网关做 dns ，什么叫网关做 dns 呢？请抓包 dns 过滤做依据来讨论

他是未来的领导，这看不出来吗？因为他懂得，有事的话，我还在，我上。

在 pg 里可以认为两个是同一个东东。

过来帮我充实下面项目，顺便加点营养：
https://github.com/dotnetcore/WebApiClient
https://github.com/dotnetcore/FastGithub

http.sys 你可以理解为饭店材料的供应商，他们工作高效，保证供应链供给充足。
asp.net 的工作线程，你可以理解为厨师们，他们负责炒菜给客人；
如果这些线程是同步 IO 工作，那么就像一个厨师为一桌客人做好菜之后，还要等客人边吃边中途继续加菜，直到客人吃饱喝足之后走人了，才能开始为下一桌客人继续做菜一样；但如果这些线程是异步 IO 工作，那就像厨师为一桌客人做好菜之后，就结束工作了，空闲的他如果有人通知他继续做菜，他就继续干活。相同的数量的厨师，异步 IO 可以让工作线程从无畏地等待中解放出来，干更多有意义的工作。

@lambdaq 你可以理解 async await 为应用层的 iocp ，应用层如果还是同步 IO ，木桶的短板就短在里了，这时底层是不是 IOCP 可能都不是短板了。

如果你能告诉我：老代码没有使用 async await 异步，那么我们就以大概确定：你的 db 可能变慢了，而且慢的原因，可能是索引问题，或者磁盘问题。

姑且算十万是 RPS(Requests per second)，单机能达到这个么高的，要么是无 IO 请求的快速同步操作，要么是使用了异步 IO 。当然，如果 IO 操作耗时很短，同步 IO 可能也得到这么高的 RPS ，但是只要 IO 操作的时长变长，同步 IO 就立刻表现为 RPS 倍数级降低。
所以我觉得可能是：老代码使用了同步 IO 去读取了文件、Db 或网络了，之前的环境里面，这些 IO 操作耗时不大，切换到新环境之后，这些 IO 操作的（因某些原因）耗时变大了，代码不变，还是以同步 IO 的方式调用，造成在相同的工作线程下，等待 IO 结果的时长变以，所以 RPS 跌落严重。

一个月就跑。

我姑且不说问题是什么问题，答案是：男的错了。如果还纠结为什么错了，那更是大错特错。别问我为什么，我是已婚人。

建议还是搞基于 http.sys 的 yarp ，劫持部分域名，且反向代理与负载均衡同时支持

这个场景我遇到过，某个有历史的 web 服务，用了 a,b,c,d 等多个二级域名完成各个业务模块，后面重写了 d 模块，并使用多台服务器来部署 d 模块。使用 yarp 托管在 http.sys ，可以只动 d 模块。

@Huelse windows 的 nginx 性能太差了，做不了总网关

当然，你也可以在 IIS 和你的新服务（非 IIS)之外，购买一台具有独立 IP 的服务器，上面跑一层 nginx （网关），把域名解析到新服务器的 IP ，然后在 nginx （网关）根据域名做反向代理规则

如果有需要，我可以帮你写这个与 IIS 共享端口（但分摊域名）的反向代理服务，这个服务可以灵活的配置反向代理到的任意上游服务

IIS 的反向代理太难用了，IIS 其实是 http.sys 的前端而已，使用 yarp 托管在 http.sys ，继续监听 80 和 443 ，同时从 IIS 手里抢过 a.v2ex.com ，就可以灵活的配置反向代理了，而且性能也最佳。

这个系统能做流浪人管理吧

我希望人类优先救助人类

给 nginx 写插件吧，只能这样才能为所欲为。话说插件我也不会写，让我来做的话，我就用 yarp