对高并发没有要求的话，那么后端难度还有多少？

• 資深大佬 : kop1989

  没有高并发还有高可用、高性能、高扩展等等。
  关键就是自己要对自己写的代码负责，每个逻辑都要有充足的思考和梳理。

• 資深大佬 : DoctorCat

  技术价值回归于业务。大部分场景下，业务经验的价值高于代码技术经验……

• 資深大佬 : falcon05

  那还要考虑安全，可维护性。每一个都是很大的话题

• 資深大佬 : wr516516

  @kop1989 怎么说呢
  感觉没有高并发的话,其实往往也没有高可用、高性能、高扩展等等。
  要说有也有,但是其实都不是很关键了…毕竟没有高并发往往意味这服务压力小,使用人数少…

  感觉技术上会回归到类似数据安全之类的,或者就是跟着业务闷头走了

• 資深大佬 : kop1989

  @wr516516 #4
  日常确实如此。

  但偶尔还是要给自己一些“工程师情怀”来给自己加戏，激励自己的。

  在 deadline 不紧张的前提下，多问问自己：“这样的代码合理么，有没有优化空间。假如要 xxx 的话，我的代码适合不适合。接下来的业务有可能往哪些方向改，改的话工作量有多少”等等……

  这样有助于保持自己的技术 /业务竞争力。

• 資深大佬 : iamppz

  @wr516516 扩展和并发不是一回事，就我的感受，各种 To B 的平台性产品，如何设计才能满足更多用户的需求（便于扩展而又不破坏逻辑的完整性、组件&逻辑的高复用率），是个比追求高并发更具挑战性的事情

• 資深大佬 : longchen888

  那么基本就剩业务了

• 資深大佬 : wr516516

  @iamppz 拓展确实不是一回事,我偷懒直接复制一的了…不好意思

• 資深大佬 : ZSeptember

  高并发套路比较固定，大家应该都知道，但是真正的实践特别高的并发的确实不多。
  不是高并发，高可用什么的才是真正的技术，这些都是固定解决方案的。
  就算是我觉得比较难达到的高可靠，其实也是有很多解决方案的。

  难的真的是业务，或者说考虑问题的完整性，还有在业务快速演变的拓展性。

• 主 資深大佬 : darknoll

  @falcon05 安全性也不用考虑了，只有内网用户用，外网都访问不到的。唉，真是上班这么多年就只学会了业务，技术啥都没学到啊

• 資深大佬 : murmur

  没了，现在硬件太强了，框架也越来越牛逼，数据库也越来越牛逼了，ssd+cpu 内存升级能解决以前的很多低级优化问题

• 資深大佬 : SjwNo1

  只有我觉得卡点通常在复杂的业务而不是并发吗？

• 資深大佬 : murmur

  @SjwNo1 复杂业务可以拆解，可以分散负载，可以酒桌上简化需求，甚至性能有时候都是可以谈的，比如点一下提交四五秒才出结果，甚至要 10 秒，企业开发你是可以说服用户的

• 資深大佬 : murmur

  表单多、流程多是罗嗦，不复杂，有各种工具解决复杂表单和工作流问题

• 資深大佬 : debuggerx

  说实话，作为伪全栈，以我狭隘的视角和有限的经历看来，真没觉得后端技术上有什么难度，包括三高……开发不难，难的是做好做精，做到超出开发视角的层次

• 資深大佬 : bsg1992

  后端抛开 network 前端抛开 ui 其实差不多。
  剩下的都是共通的

• 資深大佬 : TypeError

  服务拆分 高可用 安全 延迟 还有资源利用率之类

• 資深大佬 : PiersSoCool

  高并发是什么 是阿里双十一那种毛刺 那就没价值
  但是像 facebook 这种公司 时时刻刻都跑着很大的并发 单机无法处理
  只要是多机处理 那必然有高可用、高性能、高扩展
  根据 CAP 定理 这个就很难做到

  话句话说 高并发的模型存在 且必要 不会消失的
  但是阿里双十一那种模型 完全是可以优化掉的 但他非要这么做