这是一个创建于 570 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近有个疑问待大家讨论下
目前技术的发展大多是通过加入一个新的组件去实现或者提高整个系统的健壮性，随着技术的发展，不断的去使用新组件，去实现一个高可用的系统，所以我们现在的高可用系统其实是一个高耦合的系统，某个组件一旦出问题，就是故障，通常做法就是继续引入新的组件去确保旧的组件不出问题。😄
想起 15 年前，tb 首页经常会提示凌晨 2 点-6 点升级维护。
移动互联网发展造就了 996 ，7*24 ，服务不可中断，为了实现服务不可中断，引入一堆中间件（系统、网络、架构、框架、运维等等）
 |
1
ReZer0 2023-06-06 09:25:39 +08:00  1
哪里听说过一句话：没有稳定的系统，只有还未踩过的坑。
大致意思是，现在所看到的“稳定”现象“，都是前人踩坑所留下来的经验，缝缝补补，以至于后来人能够不容易掉入前人经历的这些坑中。但不代表坑已经被填完了，只是目前能发现的坑越来越少了。（比如偶尔能看到某些站因为崩溃上热搜） |
 |
3
diagnostics 2023-06-06 09:56:10 +08:00
软件架构不是朝着稳定发展，而是朝着“容忍错误”，提高可用性的方向发展。
昨天瑞幸 WX 小程序全面崩了，App 仍不受影响。 之前 Meituan 天天神券崩了，其他任何页面都是正常。 |
|
4
diagnostics 2023-06-06 09:56:38 +08:00
@diagnostics
Taobao 、Douyin 直播弹幕可以崩，直播推流还是正常，也可以反过来。 最终目的还是为了提高容错，今年（忘记是不是了） B 站崩溃，好像就是网关的问题，这一点很类似你说的引入“单体”来保证微服务的可用性，网关现在就是单体，不过 奈飞 提了一个新的网关架构。 |
|
5
diagnostics 2023-06-06 09:57:14 +08:00
@diagnostics #3 奈～飞不能直接打出来，所以搞了一大堆关键词，最后发现是奈～飞的问题
|
 |
6
opengps 2023-06-06 10:00:42 +08:00
整体可用性，确实可以避免大面积的受灾。
真做了大型系统你会知道，哪怕你后端服务器轮流挂掉，只要对外最终表现是绝大部分人都能正常用，这就已经具备了整体可用性 |
 |
7
C0dEr 2023-06-06 10:04:37 +08:00
写代码就是一个穷举的过程，只不过永远不会把所有情况都穷举出来的
|
 |
8
wxw752 2023-06-06 10:04:47 +08:00
OP 可能有个误区，我觉得就算不引用新组件，崩起来也挺要命的。
昨天去车管所交购置税，系统崩了好几个小时，我在车管所等到下午四点多，销售说遇到很多次了。 |
 |
9
imdong 2023-06-06 10:05:36 +08:00 via iPhone 1
我们系统一致很稳定的不可靠。
|
 |
10
GopherDaily 2023-06-06 10:16:25 +08:00
|
 |
11
pkoukk 2023-06-06 10:24:24 +08:00
有一点你错了，现在的分布式系统其实是低耦合的
每一级组件之间的关系是 Promise 而不是 Depend ，也就是下级系统挂了，对上级系统来说是这部分下级功能不可用，而不会整体挂 我做过传统软件业，就是俗话说的 C 端软件，这是真的高耦合系统，任何一个模块挂都会导致整个软件崩溃。 |
 |
12
Joeith 2023-06-06 10:46:42 +08:00
我以为你说的是，那种「系统」
|
|
14
pkoukk 2023-06-06 14:12:04 +08:00
@GeorgeWai 不能保证啊，所以设计降级策略呗。
如果 etcd 只是用来读配置，那么对它的可用性要求仅限于服务启动阶段，启动之后 etcd 挂了也不影响正在运行的服务。 你还是没懂，搞这么多中间件就是为了控制故障的影响范围，即使有某个组件挂了，故障也不会过度蔓延。 如果说搞了这一套，还是一崩崩全家，只能说学艺不精 |
 |
15
xymeng16 2023-06-06 19:01:50 +08:00 via Android
昨天 Outlook web 就崩了，但不影响 exchange 。还算可靠？
|
 |
16
testcaoy7 2023-06-17 17:30:21 +08:00
系统越复杂，出错的概率越大
高可用服务通过建设冗余来确保 Availability ，但是受制于成本，Blackout 还是时有发生 其实很正常，墨菲定律而已 |
Select Language