想想这么多年,就没怎么处理过高并发的东西,基本上都是工厂内网用的,想到技术上没啥进步,心里感觉非常难受。
1
kop1989 2020-12-31 14:28:21 +08:00
没有高并发还有高可用、高性能、高扩展等等。
关键就是自己要对自己写的代码负责,每个逻辑都要有充足的思考和梳理。 |
2
DoctorCat 2020-12-31 14:31:47 +08:00 2
技术价值回归于业务。大部分场景下,业务经验的价值高于代码技术经验……
|
3
falcon05 2020-12-31 14:31:53 +08:00 via iPhone
那还要考虑安全,可维护性。每一个都是很大的话题
|
4
wr516516 2020-12-31 14:39:33 +08:00
@kop1989 怎么说呢
感觉没有高并发的话,其实往往也没有高可用、高性能、高扩展等等。 要说有也有,但是其实都不是很关键了...毕竟没有高并发往往意味这服务压力小,使用人数少... 感觉技术上会回归到类似数据安全之类的,或者就是跟着业务闷头走了 |
5
kop1989 2020-12-31 14:47:56 +08:00
@wr516516 #4
日常确实如此。 但偶尔还是要给自己一些“工程师情怀”来给自己加戏,激励自己的。 在 deadline 不紧张的前提下,多问问自己:“这样的代码合理么,有没有优化空间。假如要 xxx 的话,我的代码适合不适合。接下来的业务有可能往哪些方向改,改的话工作量有多少”等等…… 这样有助于保持自己的技术 /业务竞争力。 |
6
iamppz 2020-12-31 14:48:24 +08:00 3
@wr516516 扩展和并发不是一回事,就我的感受,各种 To B 的平台性产品,如何设计才能满足更多用户的需求(便于扩展而又不破坏逻辑的完整性、组件&逻辑的高复用率),是个比追求高并发更具挑战性的事情
|
7
longchen888 2020-12-31 14:51:56 +08:00
那么基本就剩业务了
|
9
ZSeptember 2020-12-31 15:20:03 +08:00
高并发套路比较固定,大家应该都知道,但是真正的实践特别高的并发的确实不多。
不是高并发,高可用什么的才是真正的技术,这些都是固定解决方案的。 就算是我觉得比较难达到的高可靠,其实也是有很多解决方案的。 难的真的是业务,或者说考虑问题的完整性,还有在业务快速演变的拓展性。 |
10
darknoll OP @falcon05 安全性也不用考虑了,只有内网用户用,外网都访问不到的。唉,真是上班这么多年就只学会了业务,技术啥都没学到啊
|
11
murmur 2020-12-31 16:13:54 +08:00
没了,现在硬件太强了,框架也越来越牛逼,数据库也越来越牛逼了,ssd+cpu 内存升级能解决以前的很多低级优化问题
|
12
SjwNo1 2020-12-31 16:15:39 +08:00
只有我觉得卡点通常在复杂的业务而不是并发吗?
|
13
murmur 2020-12-31 16:17:32 +08:00
@SjwNo1 复杂业务可以拆解,可以分散负载,可以酒桌上简化需求,甚至性能有时候都是可以谈的,比如点一下提交四五秒才出结果,甚至要 10 秒,企业开发你是可以说服用户的
|
14
murmur 2020-12-31 16:18:12 +08:00
表单多、流程多是罗嗦,不复杂,有各种工具解决复杂表单和工作流问题
|
15
debuggerx 2020-12-31 16:19:44 +08:00
说实话,作为伪全栈,以我狭隘的视角和有限的经历看来,真没觉得后端技术上有什么难度,包括三高……开发不难,难的是做好做精,做到超出开发视角的层次
|
16
bsg1992 2020-12-31 16:23:42 +08:00
后端抛开 network 前端抛开 ui 其实差不多。
剩下的都是共通的 |
17
TypeError 2020-12-31 16:23:54 +08:00 via Android
服务拆分 高可用 安全 延迟 还有资源利用率之类
|
18
PiersSoCool 2020-12-31 16:43:55 +08:00
高并发是什么 是阿里双十一那种毛刺 那就没价值
但是像 facebook 这种公司 时时刻刻都跑着很大的并发 单机无法处理 只要是多机处理 那必然有高可用、高性能、高扩展 根据 CAP 定理 这个就很难做到 话句话说 高并发的模型存在 且必要 不会消失的 但是阿里双十一那种模型 完全是可以优化掉的 但他非要这么做 |