做技术的，年龄大了你慌吗？

答案：不慌。

为什么聊这个话题呢？

周末和朋友一起参加了个高并发的线下沙龙，疫情原因，好久没有去线下交流了，找个机会去看看有啥新东西。

我自己做高并发相关系统建设应该是17、18、19年那几年，后来更多做一些横向、跨系统的架构建设工作，解决的是流程、效率、稳定性、工具建设层面的事情。

当时解决了很多高并发场景下的性能、稳定性、高可用问题。也总结出了一套所谓的方法论，解决高并发场景下的问题，无非是从限流、熔断、降级、异步、缓存、分片这几个手段入手。当然不同场景下的具体问题是与其具体场景分不开的，还是要拆解下具体问题。

转眼也四五年了，想看看现在企业解决高并发有什么新的解决方案。

第一个案例是解决查询高并发问题的架构。听下来，无非是做了缓存拆分（垂直拆）、多了多级缓存、多级缓存有gc问题、做压缩、有数据一致性问题、做binlog同步等等。

你看解法还是没逃出上面八股文中的如何用好缓存这件事情。缓存穿透、雪崩、一致性就是做缓存解决方案首先要解决的问题。分享后面列了收益，比如QPS从十几万降到了几万，后续支撑了几十万等。

收益上列QPS这事没啥意思，我看很多晋升ppt里面都写了系统支撑了多少qps，但总体看下来qps高大部分解法就是加机器，要么就是原有解决方案太low了，本来不需要这么高的qps。比如我之前做过一个业务流程的优化，qps降低了50%，机器资源省了一半，听起来是不是收益很大？原因是什么呢？

我发现原来他是通过两次同步rpc分别获取了部分值，然后拼接起来做继续的动作，而且这两个接口qps都非常高。我问他们为什么分成两个小的rpc接口，他说考虑到复用性，接口都是最小化原则的。我的解法就是把两个合在了一个rpc接口上，这样就少了一半的qps调用，对应的资源就节省下来了。

如果我说我降低了一半资源，节省了几十台机器，听起来是不是收益很大？但是我觉得这个收益不值一提，因为并不是我做的多好，而是之前做的太差。

所以我不倾向于听到qps这样的收益，更多希望听到背后的本质改造，就是要脱离现象看本质，本质是调用链路不合理的，再用其他指标与这个收益结合起来。

第二个例子是一个广告系统的优化，怎么做的呢？分片。

没错又回到咱们之前的八股文里面了，这次的主要逻辑是分片。原来大的数据处理流程没做分片，所以数据处理过程非常长，导致数据指标产出延迟。怎么做呢？就分片了。

你看，四五年过去了，其实业界解决高并发方案没啥大的变化，区别只是场景和问题不同。相当于我几年前积累的高并发解决方案目前还是够用的。而且我过去2、3年前做的异地多活解决方案，还没怎么在线下meetup看到过呢？说不定过两年线下聊异地多活，和我之前做的也大差不差。

为什么说这个呢？

因为我们会发现，大家认为的技术飞速变化的逻辑其实是错的，很多逻辑其实没有变。只是不同场景和问题在变，技术的本质没有变。

高并发中的限流、熔断、降级、异步、缓存、分片这些宏观逻辑没有变，其实微观的线程、内存、IO的问题也一直没变，我们解决的还是这些问题。

这两年看了很多云原生解决方案，变了吗？其实也没有什么变化，只是对待研发流程与高可用的视角变了，目标还是更低成本。

DDD火了，但在我看来无非是面向对象的变种。DDD是2003年出来的，为什么最近又火起来了？是因为大家发现业务越来越复杂了？为什么越来越复杂了？因为越来越多的线下逻辑被搬到线上了。

架构是对现实世界逻辑的映射，这个本质依然没变，如果你理解不了现实世界的业务逻辑，你不可能做好业务流程建模，也不可能解决好他的架构复杂度问题，看这个本质其实一直没变。

比如今年搞稳定性专项这事，和很多同学沟通过程中就会发现，他们现在犯的错误，我当年都犯过。

既然前人犯过的错误，后人为什么还会犯呢？人就是这样，很多事情知道不等于做到，该犯的错误还是会犯的。所以有时候看着他们做事，就像看弟弟、妹妹做事一样，看他走着自己过去走过的路。