@zl939144892 转 go, java 了？

@lepig 还好，兴趣使然

其实还有一点，当 mq 有数据就直接 new goroutine，goroutine 数量很多，那 cli 程序重启就需要考虑必须要把正在执行的全部的 goroutine 全部执行完成才能停止进程，不然就会导致数据不一致的问题（ goroutine 处理一半，进程就 exit 了），用我写的这个 pool 就不许要考虑这个问题，因为我都封装好了。

@Mohanson 你可以这样认为，但是我觉得我做的项目我加了池，限流调大了也不会出问题，但是不加池，限流没做好久会挂，我觉得加上就更好，同样有些情况是突发的，令牌桶是可以续水的，如果桶的容量大，峰值超过了 db 的极限，也会出现上面我说的情况，但是实际不可能把桶设置这么小的，非常浪费资源。

哦，最大的意义复用协程我没有提，这个是 pool 最大的意义，和 db pool 复用连接一样，复用协程同样能节约 cpu，看着可能很小，但是任务一多起来，加起来差异就很大了。

还有并不是每个公司都是一台 8 cpu 的服务器只跑一个业务的，通常会跑很多种业务，用 pool 动态释放的内存，是有价值的，是可以让出给其他业务使用的

当然上面说了：资源分配不合理，限流做的不到位 ，但是现实情况中如果代码健壮一些，是不是就不用这么去甩锅给做限流了呢？

@Mohanson @pabupa 并不是应用在 web api 这种场景的，计算场景中有很多，比如：下单能支持 5000 qps 这是异步入到 mq，但是 mq 的消费用 cli 消费，这个时候消费的 cli 程序里要调用 db，而 db 能支持 500 qps，当不限制 go 数量时，mq 的请求全部取出，变成了一个不断增长的 goroutine，而限制 goroutine 数量的 pool 在消费不过来的时候会把 chan 阻塞，进而会停止从 mq 取新的数据，api 如果做了判断 mq size 的逻辑，接口就会返回错误让用户不再下单，但是没有用 pool 就会把 mq 的新数据不断的变成 new goroutine，直到内存无法分配。

生成的代码里使用了这些轮子，反正你也是看不到的，只看到了代码生成器。

https://github.com/mix-go/xcli
https://github.com/mix-go/xdi
https://github.com/mix-go/xwp
https://github.com/mix-go/xfmt

@CheatEngine 你会用一个别人造的轮子，然后你哪里来的优越感？谁给你的勇气？

@frozenshadow go-micro v2 可以直接使用 gin beego 的 route 作为 web/api 的解析，然后同样可以注册到 go-micro 微服务注册中心

@hgjian 都搞，mixphp + mixgo = openmix.org

@mind3x 推论是对的，php 驱动是 pdo，是 c 写的，应该性能不会差，可能差距在 （基于 Swoole Channel 实现的连接池，pdo 支持协程是使用的 Hook 技术）和 (php 没有 jit，代码越多总执行时间差距越大) 这两方面

@ben1024 正式使用环境也是有 sql 缓存的，这个感觉就没必要的，主要是看框架+语言直接，大概模拟一点真实业务场景，看看差异

@mind3x 移除序列化后测试结果变化非常小，说明序列化在这个测试中影响很小，也就是序列化相对于 db 查询来说，对整体性能影响比我们想象的要小很多。我在帖子后面追加了相关测试，https://zhuanlan.zhihu.com/p/163700975 也有完整的测试细节

@wei193 更换模式后 beego 性能得到了显著提升，测试结果 mix 比 beego 数据库查询+序列化的综合性能要低 48.2%

@lxml 硬刚下来结果也还可以了，但是比我预想的要差一些，我预想是和 beego 差不多的，测试结果 mix 比 beego 数据库查询+序列化的综合性能要低 38.3%，附言那里有链接。

@luozic 分开又会有新的问题，网络吞吐量成为瓶颈，网络的其他软件占用局域网带宽，测试的结果就更加不准确了，只能现在这样了，条件不允许。

@blless 我写了新的测试，是数据库+序列化，测试结果确实是 beego 性能更好，愿赌服输，你给一下付款码吧，测试链接： https://www.v2ex.com/t/693083