@monsoon 有理太敏感了，我根本就是字面上意思，外加一点欢乐的调侃而已。。。

@monsoon 我也不懂，因为我没做过微服务产品呢

@timbotetsu 1 和 2 是我对微服务最本质的理解，是我总结的关于微服务的“两个凡是”方针，你否定了我的“两个凡是”就等于否定了我

如何在 1 个小时变成大神
如何在 30 秒内学会架构

gitlab 自己搭太难了，coding 吧

@ivmm 没硬伤，而且一直都这么过来了也没啥问题，web 端要的是兼容性，所以根本没人会在 web 端用

gif 没大问题，apng 除了 app 端，web 端不会有人用的

用 cron 系统部署不好搞，就缓存来搞，反正流量不大

能把爬虫的 title 换成搜索引擎工程师么，我越干爬虫越觉得 low

高中就掌握了这些技能说明你有兴趣

真的想读书可以复读，你家里没钱上个专科出来也比较亏

@fengzixu 你逻辑不对

@sagaxu 峰哥在 weibo 上透露腾讯的基于 swoole2.x 的 tsf3.0 （实际名字可能不是叫这个）会在几个月后开源出来，贵厂的方案也很期待。不过 zanphp 已经比较完整了（各种连接池、rpc 协程、服务注册发现、开箱即用的 web 框架），不过 rpc 方式只支持有赞魔改的 thrift 协议 nova 估计比较鸡肋，因为很多厂微服务 rpc 的 server 端已经用 thrift 或者直接 http rest 写的，不过官方表示将会改进允许用户在 zanphp 中自定义 rpc 协议。我个人最想用的是 rpc 的 server 端就是简单的 http rest，然后 rpc 的 client 可以用 tcp 连接池来 http 访问 server 端（也就是 keep alive 的 http ），这样就免去短链接的 http 的 tcp 握手消耗以及 qps 太大可能导致端口不够用的缺陷

有赞的 zan 似乎认为 swoole2.x 的 coroutine 的协程方式比起 yield 的协程方式增加了事件模型的复杂度，所以 zan 基于 swoole1.8 来开发并且短期没有加入 coroutine 的打算，而 phpconf 上海大会代维分享的 php 微服务方案 zanphp （基于 zan ）是目前比较领先和完整的方案。

@ashfinal https://wx4.sinaimg.cn/orj360/63a9e398ly1fgvd6hki28j20u01hcngp.jpg

后来峰哥把这条微博删了，而实际上协议从 apache2 换成 php 协议并没有用

@HanSonJ 有赞的确没 fork，直接 copy 过来还去掉了 git 的 commit 记录从 0 开始，贱兮兮的，但是 apache2.0 协议并没有规定 derivative work 一定要保留 git 的 commit 记录。而峰哥对 youzan 的 zan 不提 pr 到 swoole 却跑去 swoole 拿 commit 来 cherry-pick 到 zan 的指控是站不住脚的，因为 zan 作为 derivative work 已经有很多和 swoole 不一样的地方了没法向 swoole 提 pr，而 swoole 的改进的 commit 的话 zan 完全可以 cherry-pick 过来；同样的，zan 的改进的 commit 的话 swoole 同样可以 cherry-pick 过去。

我个人其实特别欣赏 youzan 这里比较叛逆的挑战 swoole 的工作，这是一股 you can you up 的不服权威的精神，给我枯燥的一天带来了欢乐。

that's how open source works

@sagaxu 峰哥开始微博上说的意思是禁止别人在 swoole 的基础上开展 derivative work，我想吐槽的就是这个，至于别的细节根本不重要，刚刚峰哥意识到这个问题后就把这条微博删了，至于用 php-x 重写 swoole1.x 的微博可以认为是气话了。有赞那边的工作我慢慢看了，也做得很漂亮。

我在逼乎也问了相同的问题： https://www.zhihu.com/question/61422205，舆论一边倒向峰哥，看来 V2EX 上的朋友比较多样化不跟风

@everhythm swoole 作者不可能炒作，而且这事本身对社区不利，两败俱伤的

电脑都是固定维修点，实体店和网上都一样的吧
lz 脑残了