• 应用多数是 IO 密集型的。就是大部分时间都花在读写、外部调用上。

    同步框架靠线程在处理并发,线程切换耗费 CPU,线程本身也占资源。

    异步框架,可以解决并发和性能问题。

    但性能的瓶颈,更可能是出现问题的地方是存储。如何设计合理的存储结构才是问题的关键。

    再然后是时间复杂度和空间复杂度。

    现在的项目什么情况应该选择异步框架呢?

    框架首先要能横向扩展,能横向扩展,靠堆机器,可以解决多数问题。绝大多数框架,都可以横向扩展。

    之后是响应速度,速度确实重要。但多数应用对这个要求不高。多数问题,也没出在框架上。github 用 RoR 不是用的也很 happy 吗?

    有的场景,确实有并发压力,比如 IM。多数的 IM 厂商都用 Erlang,但钉钉用 Java 玩的也很 high。而且,就是用了 Erlang,还是有很多问题要解决。

    框架、语言和开发者的关系,就像赛车和车手的关系。想要跑的快,不仅仅要有好的赛车,还要有好的车手。

    应用开发,会出现瓶颈的地方有很多,框架仅仅是其中一个。

    最后,什么情况应该选择异步框架呢?

    短连,同步问题不大。长连,一般用异步处理(连 RoR 的长接模块都是异步的)。

    再就是,机器的钱,真的是需要考虑的因素了,对比人力成本以及运营成本而言。

    再或者,本身对某个异步框架熟悉,或者处于技术好奇(别把喜好包装在各种理由之下,别总单拿性能说事,单说性能,不上量子计算,都有性能问题)。

  • 感谢😀

    我大体明白你们怎么定义 SLA 了。是不是任何一个服务 crash 了,就是不可用?个别 API 500,不认为不可用?

    每日峰值调用能达到 5k qps....我们用 go 改造一些关键服务,顺利的降低了整体负载。

    那就是,使用 go 之后,可以更省内存和 cpu 吗?

    那篇文章,简单扫了下,总结下来就是 ruby 不火了。技术热点转移了,再就是本身的问题。

    本身问题有 3 点:

    1. 并发
    2. 不合适大规模工程开
    3. 不好招人

    并发这个,目前主流还是机器换人力。

    不合适大规模工程开发

    你的回复,好像没有提工程的问题。比较好奇你们实践后得出的结论是什么?

    “不合适大规模工程开发” 这个本身是很模糊的概念。比如 java 被认为更容易大规模开发。但 java 的应用真的就 bug 少了吗?真的就更快了吗?似乎也不见得。

    不好招人

    中级的不好说,高级的感觉都不好招。还有一个问题,一个 ruby 开发可以解决的,用 go 可能要用 3 个。在这个假设下,那就是招 3 个 go 比招一个 ruby 容易。才能说 go 比 ruby 好招人。

    可能整体来说,是更看好 go 的未来,所以想在 go 上多投入一些?

  • 请教下 可用性 具体是怎么计算的?

    还比较好奇为什么换到 go?收益是什么呢?

  • 一文看懂 IO 多路复用 at March 24, 2020

    先理解了线程、阻塞 IO 再到非阻塞 IO,然后再回过头看细节会好些。

  • 群 * + 野战?

  • 单个线程 指的是什么?server 的 scheduler 设置为 1 吗?

  • 直播 -- 弹幕系统简介 at March 09, 2020

    应该是 comet,不是 router,我看到 “有状态”,理解错了,尴尬了。。。

    我们的和 ActionCable 差不多,维护用户连接、router、讨论组和人的关系。

    如果只是存储关系的话,redis 应该就够了。

  • 直播 -- 弹幕系统简介 at March 09, 2020

    恩,有个 timer,一段时间连不上,就胡重连。ActionCable 我记得也是有重连的。

    IM 很多信息,都是走的长连接,长连断了,相当于 app 不可用了。

  • 直播 -- 弹幕系统简介 at March 09, 2020

    没。。。我们组是搞 IM 的,所以对这个比较了解。

    恩,是的。ActionCable 更像个通知推送系统。做实时的东西就很吃力了。

    都会重连,因为有重连、timeout 机制,有的时候会重连多次。

  • 直播 -- 弹幕系统简介 at March 09, 2020

    IM 最蛋疼的模块,就是那个 ~router~ 负责长链的模块

    处理消息的服务有很多方法减压,广播消息不是多吗,那咱就上 cassandra。还可以把写扩散变成度扩散。消费不过来,丢消息队列慢慢来。

    ~router~ 负责长链的模块 却必须广播,创建一条消息广播 n 次。消息队列慢慢消费?不存在的,消费慢了 IM 还不成邮件了。

    也有很多办法,比如限制讨论组大小,据我所知,网易内部 IM,最大群组是限制是 500,微信也限制了群的大小。不过还真不清楚钉钉大群是不是可以随便创建的。

    但大群也还是要搞,就是麻烦,比如钉钉就把大群拆成了若干小群。然后还有限流、限频、服务降级打了一套组合拳。

    恩,还要这玩应是有状态的!

    API 服务是无状态的(有状态的丢给存储),水平扩展,重启大法,玩的六六的。

    重启一台 router?恩,用户要重连的,搞不好还要重连几次的。。。

    ~router~连连服务 就不好这么搞。Phoenix 的 pub/sub 为了水平扩,就把一条消息发给所有服务,然后再有服务转发到对应的链接。

    http 网络抖了,服务器一点感觉也没有。但 ws、tcp 不一样,网络一抖,马上跟着抖,简直是网络质量监控器。