@notokoy #34

微信太闹腾了浪费很多时间，而且歪果仁也基本不用，你有 slack 频道没？可以 slack 弄点频道、还能进军海外扩张一下。也欢迎来我的项目的频道：
https://arpcnbio.slack.com/join/shared_invite/zt-16e6yu1mb-FUsil~2Jmn4Usl~IX_zv3g#/shared-invite/email

多数内部业务、尤其是需要很多功能定制的流媒体服务确实不需要太大在线量，毕竟外面有云、CDN 网络层层分担了在线数量的压力、同一 topic 只需要针对外层基础设施请求回源的节点数量就够用了，这个数量不会太大，而这些基础设施可能主流仍然是 c/cpp 的。
如果用 go 做云、CDN 之类的基础设施的开发、面向用户量很大，net.Conn 的开销也确实是还对应着挺高的硬件成本的，如果能换成 poller 和更多的内存优化，还是能声调不少资金、对能源环境问题也友好。

QUIC 这种也是路漫漫，不知道啥时候能普及，我的 poller 库只支持了 TLS/HTTP1.x/Websocket ，不打算支持 HTTP2.0 因为 2.0 太渣了。目前 go 的 QUIC 实现，也同样是一个连接至少一个协程，海量并发照样也是消耗很多资源。但是因为基于 UDP ，而 go 的 UDP 标准库已经足够简单了，所以我的 poller 库不打算支持 UDP 。至于 QUIC ，以后如果有档期，我也想搞一份不需要每个连接至少一个协程的实现，kcp-go 之类的类似标准库方案的一连接一协程也是同样的对海量并发不友好，海量并发时开销远超过其他语言的性能比较好的异步框架，剩下的只剩同步逻辑的便利，性能和消耗比其他语言异步框架劣势很多、甚至在基础设施领域，同步的便利已经无法弥补这个消耗的成本损失了。
每一样基础设施的工作量都有点大，真是想做很多但时间不够用了:joy:

你说的 go 的 io 线程数量应该是指 poller 线程数，这里先以这个作为前提，否则这样说可能不太准确。
之前我也没注意过 go 的 poller 线程数量是否只有 1 个，刚写代码试了下，net.Listen 0 个到 100 地址的时候，以及连接数 0 到 20w 的不同组合，确实都只有一个 eventfd ，而且即使不 listen 、没有连接也会有 eventfd ，是处理所有类型 fd 的 nonbloking 的:
但 top -Hp 查看，随着 net.Listen 地址数量或者连接数的增加，这 listener 和连接数的增加都对应着线程数的增加，应该是协程数多或者所需资源多时，runtime 动态增加了所需的线程。
考虑到 epoll 的不同用法和线程数量的情况，猜测 golang et 模式、epoll 线程里只是处理事件而不进行实际的读写，事件与 runtime 调度结合去触发用户协程的可读写唤醒，实际的读写则发生在用户的协程里，对应的是整个 runtime 的线程池 MPG 调度时被执行，而这个线程也是前面提到的随着负载增加而由 runtime 去增加的。所以前面我觉得“go 的 io 线程数量只有 1 个”这个说法可能不太准确。

引入 IO 框架倒还好，只是如果支持异步 IO ，编解码器要像 c/cpp 那样实现的是异步流解析，不像使用 net.Conn 同步解析这么简单，需要定制优化的地方也更多。统一实现成异步的编解码后，编解码器只收数据进行解析就可以、其实也就无所谓 IO 层是同步还是异步了，我的框架里目前就是这样，uni*是 epoll/kqueue 异步、windows 是使用 net.Conn 封装了下，框架传递数据给应用层。
并且，IO 这层节省了大量的协程数量，应用层则仍可以使用有限数量的协程池，而且应用层的协程池 1w-10w 这种 size 级别也足够用了，有特殊的阻塞需求还可以定制不同的 pool 来控制整个系统的协程资源，这样我们仍然可以在应用层写同步逻辑，我的库里现在就是这样做的，跑着效果还算挺好

并发量大的时候，基于标准库的 net.Conn 还是消耗很大。7 、8 年前记得国外有个团队单机 50w 连接推流，内存、调度成本还是很高
去年我自己的异步框架功能基本完善后，也琢磨支持下流媒体的然后不用每个连接一个协程去循环读了，可以节省太多协程数量、内存、gc ，都可以变得可控，但是我自己暂时没那么多时间精力搞这一大套、得看以后有没有适合的时机了。如果作者有兴趣可以试下搞套异步的

PS ，阿里系开源真是各种 KPI 烂尾，之前看他们有人出了个 livego ，代码感人，低级错误、连 panic 都没处理好稍微测试了下就宕机了，本想 pr 修复下，但是看已经烂尾了所以没再关注了

楼主这个，我之前就有关注过，加油！

生活就是这样子操蛋，同情楼主+1

@victor

外层有其他反代、中间件等设施做中转是可以交给其他基础设施处理。

但是 client 直连 go server 的，还是需要注意。比如用 go 做的基础设施

《喜剧之王》

某站上的那些凄凄厉厉声也是让人久久不能释怀的

半尺码克十万起，线上业务一百加

@hello2090
#22 也就写习惯了 CURD 简单逻辑的不太纠结这些。如果真都不用纠结，世间岂不早就被 c/cpp 一统江湖了

支持，java 届的人间清醒。
ps：总有很多巨婴程序员觉得 go 没有这不行、没有那不行，其实都是常年写逻辑的你自己不行

@RedisMasterNode
第一，这与跟风完全无关，我不是因为 rsc 开贴而跟风，我自己的工程结构都是自己设计。
既然说到跟风，你有没有思考过哪种人擅长跟风？自己的设计能力不足、缺少判断力的人，才经常跟风，工程结构这种事情涉及到一定的设计审美能力，但还不至于是难度很大的事情、也不至于太过影响工程效率，因为即使工程结构不漂亮、只要团队人员都熟悉后形成项目规范、那项目就能足够有效推进了。各种语言，项目结构多了去了，对于工程效率，通常是约定大于配置
你觉得这个好，大概率是因为你在自己的 go 项目积累初期阶段没有自己花心思去认真思考和设计工程结构，刚好又看到有可以参考的就直接拿来用、并且用习惯了，用习惯之后其实就无所谓了。所谓的实践里你们很多工程按这个目录来也清晰明了没出什么问题，但你有没有想过其实如果你早期是参考了一个其他模板，习惯后也照样清晰没什么问题？因为这中工程结构，只是目录结构而已，并不是那些决定项目生死的算法、数据结构、框架基础设施实现质量最主要因素，比如高并发高性能，一些算法、数据结构、系统编程能力直接决定了项目能否满足性能要求（尤其是对单点性能要求很高、不是无状态那种随便加硬件就能解决的类型）。所以你说这个模板你们很多项目用着没什么问题——这说法没毛病，确实没什么问题，但这并不能证明它真的就是好，并不是所有人都能够像你们一样能够轻易接受别人的某种设计审美，而且至少我接触的高阶开发人员里，不喜欢这个模板的人居多

第二，先不论这个模板好不好，作者自己冠以 standard 。项目种类很多，你要是类似 spring 或者 larval 或者什么框架之类的，自带工程结构作为自己框架的 standard 那无话可说，然而你不是框架、只是个目录结构，跟中文那些文档类的 star 项目没什么本质区别。并且冠以 go 语言本身的 standard ，作者要脸吗？说句不好听的，这叫鸠占鹊巢、沽名钓誉，个人觉得这不仅不严谨，而且不道德

第三，说说这个模板到底好不好。不同的项目类型有不同的模块、组件需要，对应不同的目录结构通常是项目自家人员设计更贴合实际审美，通常大家倒是有一个共识——对于很多不同场景时没有银弹，既然没有银弹，即使是再去研究并且列举它哪里不好都是对时间的浪费。所以这个作者搞一个自以为通用适合所有项目类型的模板（只是目录结构），我觉得说他是招摇撞骗也不为过

@joesonw 这个项目的工程结构真的没什么可参考的。

@joesonw
又是一个受害者，早期被别人带跑偏了。。。

先看下 go 作者主力和一众人怎么喷这个项目早点纠正下姿势吧:joy:：
https://github.com/golang-standards/project-layout/issues/117

虽然我仍然喜欢大道至简，但是希望有楼主这种项目能让那些对 golang 大道至简阴阳怪气的小白们闭嘴

@sunny1688
#4 简单 review 了下，先 issue 了个，欢迎多多交流

@dubdub 比如标准库 tls 或者其他一些地方，或者 fasthttp 里，用到 2^N size 对齐的多级 pool ，nbio 里用的不是固定 size 的，go 的 gc 无法确定内存的精确释放时机，如果需要比较精准控制，甚至可以 cgo 直接调用 malloc 这些，得看实际需要了。