V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
这是一个专门讨论 idea 的地方。

每个人的时间,资源是有限的,有的时候你或许能够想到很多 idea,但是由于现实的限制,却并不是所有的 idea 都能够成为现实。

那这个时候,不妨可以把那些 idea 分享出来,启发别人。
Jackyxiaoc
V2EX  ›  奇思妙想

很多时候在引用前端库 cdn 的时候,会担心这个前端库什么时候挂掉。想做一个东西,监测并自动寻找最优的前端库。

  •  
  •   Jackyxiaoc · 2019-11-15 11:09:19 +08:00 · 7628 次点击
    这是一个创建于 1596 天前的主题,其中的信息可能已经有所发展或是发生改变。
    最近在做一个项目的时候发现,引用了不同的前端库对网页的速度影响很大。一个不小心前端库挂掉了,所有页面就废了还得冲上去换。

    打算做一个原理是 A 域名—自动跳转—B/C/D……等等前端库地址的。
    自动寻找速度最快的。保证了前端库的高可用和高速。
    如果有这个东西,大家会用吗?
    62 条回复    2019-11-18 17:54:52 +08:00
    jeremaihloo
        1
    jeremaihloo  
       2019-11-15 11:21:01 +08:00
    首先,你要做一个什么?程序?如果是个程序,你这个程序的并发怎么解决?如果你这个程序挂了呢?你是不是要做一个程序监控你这个程序?那如果监控你这个程序的程序挂了呢?

    前端库放在 CDN 上是最靠谱的了吧,CDN 都不靠谱的话,你其他的也更不靠谱了
    lxk11153
        2
    lxk11153  
       2019-11-15 11:21:01 +08:00   ❤️ 8
    前端库挂掉了 和 你做的这个东西挂掉了 有什么区别?
    mcfog
        3
    mcfog  
       2019-11-15 11:22:16 +08:00   ❤️ 1
    这个东西除了天然会慢一次跳转(即使是第二次也不能缓存所以冷热情况下都慢)还有一个具备实用性的前提:你的 A 的基础设施的可用性高于 B/C/D……当中的最大值,地理分布也要优于 B/C/D 或者至少不能差太多,否则相当于为了 0.00 几的不稳定或者跑路的风险而让终端用户每次先绕地球跑过来找你 A 一圈再去 B 或者 C 的当地 CDN

    不如做的简单一点就只做可用性检测、统计和警报就行了,比如订阅 B 这家服务中国大陆不可用超过 5 分钟 /C 这家全球任意地点 TTFB 超过 300 毫秒之类的告警(用于应急处理),以及周或者月频率的可用性和速度评测(用于选择)
    Jackyxiaoc
        4
    Jackyxiaoc  
    OP
       2019-11-15 11:28:40 +08:00
    @jeremaihloo 感谢您的回复。cdn 库的速度也是不一样的 压力大了某个节点挂了很正常
    这个小系统单纯作为转发,压力比 cdn 小得多。不容易挂。


    @lxk11153 感谢您的回复。这个东西承受的压力单纯是一个转发,不承受流量。当然比 cdn 稳吧。

    @mcfog 感谢您的回复。这个东西除了天然会慢一次跳转,确实是这样,但是有的前端库挂了的时候,不稳定的时候,甚至几秒的加载速度。单纯的告警容易出问题,一挂了就得上去改代码了。A 的可靠性确实要高,不然肯定还不如 cdn。
    wunonglin
        5
    wunonglin  
       2019-11-15 11:32:22 +08:00
    没有
    mcfog
        6
    mcfog  
       2019-11-15 11:32:49 +08:00
    @Jackyxiaoc 如果你的检测和告警质量高,别人足够信任你,就可以做自动化收到你的告警自动更换备用前端库,这样可以做到无性能损耗
    stevenkang
        7
    stevenkang  
       2019-11-15 11:35:45 +08:00 via iPhone
    cdn x2 吗?

    可以考虑给各大 cdn 库做镜像,然后公布检测的健康度,让使用者自行选择。

    或者用 DNS 解析(如果可以的话),哪个库稳定你就解析到哪个库上去
    Jackyxiaoc
        8
    Jackyxiaoc  
    OP
       2019-11-15 11:38:44 +08:00
    @mcfog 确实应该从监控一步一步做起。


    @stevenkang 不是,只是一个单纯的跳转。如果 A 公共库挂了,就自动引用 B 公共库。
    Jackyxiaoc
        9
    Jackyxiaoc  
    OP
       2019-11-15 11:39:29 +08:00
    @mcfog https://unpkg.com/[email protected]/lib/vant.min.js 这个链接为例子,有时候加载 500ms 有时候 1.3s 。每一次都不一样。
    wunonglin
        10
    wunonglin  
       2019-11-15 11:47:07 +08:00
    @Jackyxiaoc

    #9 请问如何解决多运营商,多地域的不同性动态引用。。这得需要投资大量服务器吧,你这东西怎么盈利?还是纯公益?如果你这东西没盈利的话,我如何知道你的服务什么时候“挂”,那这样是不是又要所谓的 CDNx3,一套嵌一套,母猪带胸罩
    Jackyxiaoc
        11
    Jackyxiaoc  
    OP
       2019-11-15 12:10:31 +08:00
    @wunonglin 其实原理有点像这个: https://www.superbed.cn/help 单纯的转发并不需要很多服务器...
    antscript
        12
    antscript  
       2019-11-15 12:12:06 +08:00 via iPhone
    虽然这个问题应该是 CDN 供应商考虑的,但提供一个思路供发散,从 DNS 解析入手,域名只用一个,你负责将请求解析到符合要求的 CDN 地址即可,既不需要前端来处理这种情况,也没有缓存的问题。
    wunonglin
        13
    wunonglin  
       2019-11-15 12:13:17 +08:00
    @Jackyxiaoc #11 可是前段库用 cdn 的意义就是要快速呀,你自己 title 都说了“保证了前端库的高可用和高速”,按你这样转发的话,鱼和熊掌是不能兼得的
    ibegyourpardon
        14
    ibegyourpardon  
       2019-11-15 12:13:20 +08:00
    你这个更适合作为一个 npm 包,用于前端在构建打包的时候自动检测,并寻找到合适的替换上去。

    而不是在上线之后再做个检测替换。

    你现在的思路还是不对。
    wunonglin
        15
    wunonglin  
       2019-11-15 12:14:42 +08:00
    @Jackyxiaoc #11 所以说你想做一个高可用的还是要做一个快速的,或者是你有什么好办法可以两者都兼得的?
    Jackyxiaoc
        16
    Jackyxiaoc  
    OP
       2019-11-15 12:27:28 +08:00
    @antscript 感谢,确实是个好办法。

    @wunonglin 感谢回复。其实我个人目前测试的结果是头条的库质量最好,然后后台一个排名综合评分。一旦检测失败了就指过去下一个排名的库。

    @ibegyourpardon 感谢回复。我学习一下。
    wunonglin
        17
    wunonglin  
       2019-11-15 12:36:55 +08:00
    @Jackyxiaoc #16 还有个问题不知道你想没想过,每个用户访问 cdn 的效率都是不太一样的,cdn 每个节点也有质量好坏的时候,你怎么解决这个问题?打比方 cloudflare,国外访问快的一批,国内成渣,如果按你排分系统来使用的话,你怎么判断区分用户 ip 的来源和匹配这个 ip 最快的 cdn 供应商
    Jackyxiaoc
        18
    Jackyxiaoc  
    OP
       2019-11-15 12:46:01 +08:00
    @wunonglin 这个问题是想过的。网站引用的地址是 abc.com/[email protected]/lib/vant.min.js ——unpkg.com/[email protected]/lib/vant.min.js

    我是可以拿到访问这个地址的用户的 ip 的,能区分出国内和国外就好。后台根据一个规则去匹配。当然这个是不能实时判断每个用户的网络情况选最好的 cdn 的,那样做监控的成本太高了。目前这套方案只能保证可用 100%,速度不至于太差。像 www.v2ex.com/t/536934 这种情况出现的时候,不需要满世界改引用。
    wunonglin
        19
    wunonglin  
       2019-11-15 12:49:13 +08:00
    @Jackyxiaoc #16

    我做个假设,0-10 分,10 分最好,0 分最差
    [a.com: 10, b.com: 9, ...]

    返回 a.com ,用户 A 使用了 a.com ,用户的网络是长城,访问 a.com 质量很差,结论:用户 A 觉得评分不准
    返回 a.com ,用户 B 使用了 a.com ,用户的网络是电信,访问 a.com 质量很快,结论:用户 B 觉得评分 ok
    返回 a.com ,用户 C 使用了 a.com ,用户的网络是电信,但是 a.com 分配给用户 C 的 ip 拥挤,访问 a.com 质量很差,结论:用户 C 觉得评分不准
    等等


    如果遇到上面问题的话,你的评分系统如何处理这个状况?假设不能处理的话为什么不直接用 a.com
    jin5354
        20
    jin5354  
       2019-11-15 12:51:15 +08:00
    为什么要用 cdn 方式引入前端库。。?
    难道不是自己把库打入自己的 bundle 么?
    wunonglin
        21
    wunonglin  
       2019-11-15 12:51:28 +08:00
    @Jackyxiaoc #18 所以我一开始就说这个东西肯定需要一定的成本的,不是单单做个跳转就能解决,当然,如果这个东西是自己用的话倒是无所谓,一旦群体大了,你的项目负面情况就暴露出来了
    optional
        22
    optional  
       2019-11-15 12:53:18 +08:00
    script onerror 替换另一个公共 cdn 就好了,,,如果碰到 2 个公共 cdn 挂了,那就是命
    momocraft
        23
    momocraft  
       2019-11-15 12:58:13 +08:00
    作为设施很难做到比正牌 CDN 更稳,比如 cdnjs 是 cloudflare 赞助的。

    国内访问不稳是另一个问题,甚至不是设施稳就能解决。
    jaynos
        24
    jaynos  
       2019-11-15 13:02:41 +08:00
    用一台服务器来检查多个 CDN 的可用性有点不靠谱吧?服务器有自己的线路, 这和用户的线路是不一样的呀.

    服务器在杭州, 用户在深圳. 服务器告诉深圳的用户地址 A 很好, 但是实际上地址 A 在深圳可能已经完全访问不了了.
    hyy1995
        25
    hyy1995  
       2019-11-15 13:03:49 +08:00   ❤️ 1
    用 cdn 本来就有风险,这种优化方式并不可控,所以项目中我从不引入 cdn,没感觉项目到了非要用 cdn 来优化加载速度的地步。不过我也没开发过大型项目,可能认知有偏差吧。
    lhx2008
        26
    lhx2008  
       2019-11-15 13:05:39 +08:00 via Android
    最简单的,做一个网站,输入你的用公共 CDN 和邮箱或者手机,然后我自动监控,挂了马上打电话或者发邮件,不就行了,个人开发者又不讲什么 SLA
    fengbjhqs
        27
    fengbjhqs  
       2019-11-15 14:13:14 +08:00
    我觉得这个东西比较困难,适用价值也不大,

    现在前端基本较少用 cdn 了, 基本是 webpack 打包全部丢上去,

    ui 库或者其他基础库,会有按需分割的需求,

    而且成本较高,
    fengbjhqs
        28
    fengbjhqs  
       2019-11-15 14:16:39 +08:00
    以前用 jq 的时候,我这样处理过,

    放 3+多 jq cdn 地址,每个加载 0.5s ,成功停止,否则继续加载,如果都失败,那基本是用户网络问题

    但 react+webpack 后,没有更好的方案,
    Jackyxiaoc
        29
    Jackyxiaoc  
    OP
       2019-11-15 14:17:45 +08:00
    @wunonglin 其实这个跳转就是为了解决 cdn 直接挂了。您提到的评分的问题,确实不能针对每个用户去调整,除非投入比较多的监测节点。或者在用户端引入一段 js,监测用户的网络质量。再返回合适的公共库。
    @jin5354 可以节约流量,降低成本。
    @optional script onerror 应该是加载到完全加载不出来才引入第二个吧,要某个公共库是真挂了,用户打开的时间估计也要挺久的。
    @momocraft cdn 本身挂的可能是比较大的,但是多了一个稳定的跳转的话,应该稳定一些。
    @jaynos 确实。所以如果是简单的跳转只能解决某个公共库挂掉的问题。
    @hyy1995 是的,确实有风险。但是如果全部用本地的,或者是自己的 cdn,流量成本应该挺高的。
    @lhx2008 对,还是这样比较简单。
    rioshikelong121
        30
    rioshikelong121  
       2019-11-15 14:25:54 +08:00
    那就打到自己的 bundle 里面吧。。这个挂了也就意味你的网站挂了。
    optional
        31
    optional  
       2019-11-15 14:26:39 +08:00
    @Jackyxiaoc 那你把两个 script 都写上,再来个 defer/async,反正大多数 js 加载两次问题不大,
    wysnylc
        32
    wysnylc  
       2019-11-15 14:30:27 +08:00
    哈啊哈最近刚好找到个类似需求的,不过是 dns 最优解
    Jackyxiaoc
        33
    Jackyxiaoc  
    OP
       2019-11-15 14:37:34 +08:00
    @rioshikelong121 emmm 这样自己的服务器压力小大。
    @optional 好办法,下午试试。
    @wysnylc 哈哈具体的解决方案是?
    momocraft
        34
    momocraft  
       2019-11-15 14:46:15 +08:00
    说得直白一点

    CDN 用多少机器多少监视才达到的 uptime 在你嘴里叫 "挂的可能比较大”,用户凭什么觉得你,一个恐怕没有认识到这个难度的人,自己做的东西更 "稳定" ?
    Jackyxiaoc
        35
    Jackyxiaoc  
    OP
       2019-11-15 14:48:11 +08:00
    @momocraft www.v2ex.com/t/494314 这种算不算挂了?避免的就是这种。
    wysnylc
        36
    wysnylc  
       2019-11-15 14:52:19 +08:00
    @Jackyxiaoc #33 叫 dns chooser,我有发帖介绍
    Jackyxiaoc
        37
    Jackyxiaoc  
    OP
       2019-11-15 14:53:15 +08:00
    @wysnylc 感谢。
    watzds
        38
    watzds  
       2019-11-15 14:56:44 +08:00 via Android
    嗯,有时候 CDN 是访问不通,虽然可能不是 CDN 本身问题,页面能打开,部分 js 资源出不来也挺难受的
    myqoo
        39
    myqoo  
       2019-11-15 15:43:42 +08:00
    可以看看这个思路,去中心化 CDN https://github.com/EtherDream/decent-cdn
    liuzhiyong
        40
    liuzhiyong  
       2019-11-15 15:46:58 +08:00 via Android
    我觉得不要“自动跳转”,搞个监控检查就很不错。
    exip
        41
    exip  
       2019-11-15 16:18:32 +08:00 via Android
    service worker 完美解决楼主的问题!
    service worker 能在请求到达浏览器后呈现给用户前,修改响应内容
    exip
        42
    exip  
       2019-11-15 16:21:26 +08:00 via Android
    参考 /t/331086
    lxk11153
        43
    lxk11153  
       2019-11-15 16:32:40 +08:00
    @Jackyxiaoc #11
    1. 试了下 superbed `curl -I https 蟹://pic.superbed.cn/item/5b7153f79dc6d696149d96cb.jpg`
    ```text
    HTTP/2 302
    server: JSP3/2.0.14
    date: Fri, 15 Nov 2019 07:53:05 GMT
    content-type: text/html; charset=UTF-8
    content-length: 0
    location: https 蟹://ae01.alicdn.com/kf/HTB1zHXaXQH0gK0jSZPiq6yvapXa4.jpg
    ```
    2.1 你说的“高可用”可以解决,小范围用用的话你的程序也不会挂
    2.2 “高速”好像不那么容易吧,分两个 2.2.1 用户访问你的程序的高速 2.2.2 location 到哪个 cdn 是用户访问起来最快的
    ---- 然后好像感觉丢失了 cdn 的本意了~
    KENNHI
        44
    KENNHI  
       2019-11-15 18:30:32 +08:00 via Android
    现在问题来了,是 CDN 更可靠还是你这个软件更可靠?
    我比较信赖 CDN 的可靠性哈哈。
    楼上说的很对,靠智能 DNS 才是解决之道。不同的来源(移动 /联通 /电信 /海外)可以解析到不同的 cdn 上,这样可以解决所有问题。
    Jackyxiaoc
        45
    Jackyxiaoc  
    OP
       2019-11-15 18:58:55 +08:00   ❤️ 1
    @watzds 对啊 特别是前端的库经常出问题...
    @myqoo 谢谢
    @myqoo 谢谢
    @liuzhiyong 监控确实没什么问题
    @exip 貌似不行...库挂了和这个没啥关系吧,首次加载还是不行。
    @lxk11153 蹭前端公共库又想稳定...只能这样了...速度只要不比原来的慢,其实就没什么大问题。
    @KENNHI 蹭前端公共库...怎么知道节点的地址...cdn 确实稳定,但前端公共库炸鸡的事情时有发生。这个小玩意的作用是蹭前端公共库的时候,想白吃白喝又能稳定的折中办法...避免类似事故的发生 /t/494314
    exip
        46
    exip  
       2019-11-15 19:10:40 +08:00 via Android
    @Jackyxiaoc 库挂了,可以在 serverworker 里拦截请求失败信息,然后重新请求一个能用的地址再呈现给用户.
    Jackyxiaoc
        47
    Jackyxiaoc  
    OP
       2019-11-15 19:11:16 +08:00
    @exip 哦哦,明白了。
    exip
        48
    exip  
       2019-11-15 19:13:01 +08:00 via Android
    @Jackyxiaoc 用户能可能会感觉到这次加载有点慢,但不会知道你已经更换地址了,也不会出现加载不出来的情况.
    Jackyxiaoc
        49
    Jackyxiaoc  
    OP
       2019-11-15 19:18:29 +08:00
    @exip 微信浏览器还不支持 service worker 的离线访问...
    luoway
        50
    luoway  
       2019-11-15 19:26:34 +08:00
    相当于代理掉客户端请求,那么 service worker 和服务端统一处理都是可以实现。
    问题是,这样的统一代理对服务器压力大。别看处理逻辑简单,每秒处理请求数上去后,排队都能卡一会。
    watzds
        51
    watzds  
       2019-11-15 19:33:21 +08:00 via Android
    不知前端能不能检查到 cdn 不通,不通自动切换,或者刷新页面时切换就行
    blackmirror
        52
    blackmirror  
       2019-11-15 19:45:13 +08:00
    这是个伪需求
    chcx
        53
    chcx  
       2019-11-15 22:19:34 +08:00
    伪需求
    静态资源,CDN 做的是缓存拷贝,只要你源站能提供正确的资源则无问题。
    另外 CDN 架构方面:会做动态健康检查,节点间及同节点资源的负载均衡健康检查,全局的 isp 级别及基于实时服务质量的智能调度。
    当然,CDN 也会出现一些节点及调度问题,这个高可用架构能规避 99%吧,问题存在发生的可能。
    mytsing520
        54
    mytsing520  
       2019-11-15 22:58:32 +08:00
    不同地区 CDN 效果都不同。
    这个“需求”甚至不能称得上是一种需求
    muzuiget
        55
    muzuiget  
       2019-11-15 23:03:13 +08:00
    不就是再加一次 CDN 吗?还是觉得大厂的 CDN 稳定得多了。
    Jackyxiaoc
        56
    Jackyxiaoc  
    OP
       2019-11-15 23:46:12 +08:00
    @blackmirror 我这里说的 cdn 是前端的公共库,还是挂挺多的。
    @chcx 如果是付费的 cdn,那毫无疑问,可靠性很高。我这里说的 cdn 是前端的公共库,还是挂挺多的。
    @mytsing520 如果是付费的 cdn,那毫无疑问,可靠性很高。我这里说的 cdn 是前端的公共库,还是挂挺多的。这个东西是保证挂了以后能切换去能用的。t/536934
    Jackyxiaoc
        57
    Jackyxiaoc  
    OP
       2019-11-15 23:47:13 +08:00
    @blackmirror 我这里说的 cdn 是前端的公共库,还是有挂的概率的。
    @chcx 如果是付费的 cdn,那毫无疑问,可靠性很高。我这里说的 cdn 是前端的公共库,还是有挂的概率的。
    @mytsing520 如果是付费的 cdn,那毫无疑问,可靠性很高。我这里说的 cdn 是前端的公共库,还是有挂的概率的。这个东西是保证挂了以后能切换去能用的。t/536934
    tonylau
        58
    tonylau  
       2019-11-15 23:58:15 +08:00 via Android
    套路云有个叫“全局流量管理”的产品,集成了健康度检查、容灾自动切换方案、流量负载均摊等,跟楼主说的需求有些类似,可以了解下。
    dorothyREN
        59
    dorothyREN  
       2019-11-16 16:48:22 +08:00
    cdn 你是不用担心了,但是你该担心你这个小东西啥时候挂了
    Foxkeh
        60
    Foxkeh  
       2019-11-16 20:31:58 +08:00
    前段时间一个周六 BootCDN 挂了之后,
    前端工程师给出的对策是同时配置多个 CDN 前端库.
    当时很惊讶,但没问实现原理.
    KENNHI
        61
    KENNHI  
       2019-11-17 00:11:06 +08:00 via Android
    @Jackyxiaoc 说实话每次遇到这种能打开网站结果 css/js 没法加载的情况的时候,我都在想干脆直接把这些东西放在源服务器完事了。反正这样一来,能打开网站,js 之类的自然能加载;打不开网站能加载也没用。
    我说智能解析是指你可以把这些库放在不同的(自己的) CDN 上,不同的线路访问不同的 CDN。听说有的 CDN 对移动好,有的对电信好之类的 hhh。其实有了任播或者 BGP,完全不需要依赖 CDN 之类的也可以,直接放源服务器省事了。
    Jackyxiaoc
        62
    Jackyxiaoc  
    OP
       2019-11-18 17:54:52 +08:00
    @dorothyREN 付费的 cdn 是不用担心,公共的前端库还是会挂的。

    @Foxkeh 求大神给点方向。

    @KENNHI 嗯嗯,谢谢。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2793 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 13:31 · PVG 21:31 · LAX 06:31 · JFK 09:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.