架构设计应顺应技术的生命周期
本文来自我最近正在学习的课程，极客时间郭东白的专栏文章。这篇文章让我在架构悟道上有所觉悟，分享给你，希望对你有所启发，部分内容我作了精简，内容如下。
人类的各种活动都要遵循事物的客观生命周期。不论是农业社会种田打渔，还是资本社会投资创业，行动太早或太晚，都会颗粒无收。技术也一样，也有自己的生命周期。而我们作为架构师，如果看不清技术的生命周期，那么所设计的架构就没法儿向更有生命力的新技术借力，自己的职业生涯也会受限。
在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。
但是啊，有的人能够看准一个技术的生命周期， 而有些人却做不到。为什么？
看准技术趋势为什么难？
我和身边许多做技术的同学，多数时间都在看小尺度的问题，日常工作和注意力都放在需求实现、领域建模、平台重构、中间件升级之上，因此我的思考也被这些工作所主导，很少去思考五年、十年，甚至二十年的技术趋势。我们不关注，当然也谈不上如何利用技术周期了。
技术的生命周期就像是潮水。潮来，汹涌澎湃，绵绵不绝。潮去，风平浪静，滩涂尽显。人一生的黄金岁月中也就是几个浪头而已。就过去 40 年而言，真正大的技术浪头有个人电脑、互联网、移动互联网、AI，差不多是每十年一个。你要在这种技术大浪潮之上玩好冲浪，就必须看清楚浪头，准确把握好技术方向和入场时机。如果错过，再等新的一个技术周期，几年的黄金岁月就浪费了。
我不认为自己真正看准过这些趋势。事实上，我也没能借到浪头的最大势。我分析原因，是因为存在着三个人性上的弱点：
- 自我麻痹，以繁忙的重复工作来代替深度思考；
- 畏惧变化，以最小化改变来维持自己的心理安全感；
- 路径依赖，以过去的成功经历来应对未来案例。
让我们放弃思考的三大弱点
弱点一：自我麻痹
自我麻痹是指我们用各种方法让自己放弃思考和探索的欲望。
对于大部分互联网从业者而言，从小到大都是学霸，内心不太能接受自己不思进取。于是进化出了一个自我保护机制，让自己每天都忙起来，用勤奋来弥补内心的不安。这就导致我们不能全力去探寻新的出路。
其实麻痹自己越久，就越是难以突破。越没有突破，就越是没有去突破的勇气。陷入一种恶性循环。
我们只有承认和面对现在的风险，才有勇气放弃麻痹自己的行为，把部分注意力从当前技术放到更新、更有颠覆性的技术上去。而不是被动地等着他人告知自己下一步需求。
弱点二：畏惧改变
马斯洛模型提到：心理安全感的需求导致我们会畏惧改变，这是我们与生俱来的本性。
前段时间有位技术人员给我分享他稳定性治理的经验，他描述了如何通过一个独立的运维团队，把一组很烂的微服务运维到接近五个九。我很诧异，他们直到现在竟然还在使用独立于研发的运维团队，来保障公司核心系统的稳定性。
后来追问细节才知道，这家公司连续几任 CTO 都没做过互联网高可用架构。因为这个核心服务是公司营收路径上最重要的一环，所以连续几个 CTO 都不敢大兴土木，从根本上解决这个服务的稳定性问题，而是通过运维的方式先顶着。这一顶，就是 4 年多！
畏惧改变，让这个团队从 CTO 到架构师，再到一线主管，都丧失了稳定性治理的勇气。直到现在，这家公司还在沿用几年前自研的微服务框架，而没有引入当下常见的 Spring Framework，也没采用 Service Mesh。从头到尾都是一套年久失修的老系统， 离开的人越多，懂的人越少，就越没有人敢改动。现在，公司只能靠大量的全职运维团队来续命，以至于风险稍大的发布，还是要运维团队来做。
其实我们都一样，一旦赌注足够大，就会产生畏惧。我们率先放弃了改变的勇气，跟着就会放弃改变的欲望。得过且过，离新的技术趋势越来越远。
弱点三：路径依赖
所谓路径依赖，就是你被过去的成功所蒙蔽了，以为过去的成功可以复刻。当过去的成功路径成了你唯一的选择，那么你也不会关注，更不会去探索新的路径了。
几年前有个同学转岗到我团队。他之前在一个大部门里做基础架构，曾经做过合并部署，就是把几个相关的微服务部署在同一台虚拟机，甚至是把几个微服务合并成一个巨石服务，然后部署在同一个 JVM 上。
这么做其实是个反模式，虽然会减少网络开销，提升性能，降低计算成本。但实质上，这个过程是用长期的运维和人力成本来替换机器成本。要知道，机器成本和网络带宽，在今天还基本符合摩尔定律。所以通过不断增加人力、维护和迁移成本，去替换每两年就减半的计算成本，这么做是不理智的。事实上，更大的成本是机会成本，这种巨石服务会增加升级改造的难度。也就是说，会让一个企业，很难快速响应新机会和新的竞争。
不过在他之前遇到的场景下，这样做的确可以带来实实在在的短期回报，所以他在之前的团队得到了很大的认可，也因此得到了晋升。同时，他也为自己的成就感到自豪。但我所在部门的 BU 的计算量，远远低于他之前的大部门，峰值流量还不到他们的百分之一。这么一来，虽然开发成本一点儿没少，但做合并部署的回报却远远小于他之前的工作场景。
而这个时候，Kubernetes 已经开始暂露头角。Kubernetes Pod 加 Docker Image 就已经可以非常完美地解决合并部署能解决的大多数问题了。但这位同学，因为有了之前的成功经验，根本没有去探索合并部署之外的解决路径。结果他的项目进行到一半，大家意识到 K8s 才是更合理的解决方案，所以他的项目也就草草收场了。
这就是路径依赖。如果我们被某个史诗级的训练样本冲击过，都会过度相信自己过去成功或失败的经验。这会让我们看不到其他的技术可能，更别说新的技术趋势了。
如何克服人性的弱点？
先分享一下我的办法。我并不觉得这些办法好在哪里，但有必要分享我在克服这些弱点上所做的努力。
首先，日常工作中我也经常会麻痹自己。不过我跳出这个状态的办法就是，每年会留出两次深度忏悔的时间。我会放下当前所有事情，回想过去半年是不是做错了什么，有没有获得什么本质上的能力提升。半年后，如果发现自己还是同样沮丧，那么我就会琢磨，是不是要逼迫自己找个更有压力、更能成长的事情和环境了。
这就到了第二点，克服内心的恐惧，迎接变化。这一点我天生要比很多人好。虽然在变化来临的那一刻还是会有很大的恐惧，但与此同时，我又无时无刻不在期待着变化。不止在工作中，生活中也是一样。随性的探索和意外的惊喜，总会带给我更大的乐趣。如果说我不恐惧变化，那完全是胡扯。但我会用对获取惊喜的期待，来压制内心的恐惧，这个办法对我一直很有效。
路径依赖最难破。我记性还不错，表达能力也比较强，而且我也经历过很多波折。但到了后来带团队时，就发现这些特性看起来是优点，其实会放大我的路径依赖。
比如面对一个相对来说经验没那么丰富，表达能力没那么强的同事。我能够及时召回重点案例或个人经历，然后把逻辑准确表述出来。这个时候，我会更容易说服周围同事，导致我的建议更占上风。这个问题在我刚开始做 CTO 时变得非常严重。因为大多数参会者是我的下属或同事。他们可能不愿意反驳我，甚至哪怕是我错了，也不一定会纠正我。
我意识到这种情况之后，就开始刻意让自己更关注那些想法独特，或者是经常挑战我观点的人。比如下属反对我的话，如果我们各自的逻辑都很严谨，仅仅是假设有所不同。那么我表达观点之后，就会强迫我放弃自己的立场。
这么做，一来可以防止我有路径依赖，二来也是为了培养下属，让他们有足够的决策空间和犯错空间。这样一来，他们不犯错，我就有成长。他们犯了错，他们自己就有了成长。两全其美，何乐而不为？事实上，在这个过程中，我发现了非常多优秀的人才。我相信他们中间有很多人的思考和成就必然会超越我。
假设没有这些弱点阻碍你探索技术趋势，那么我们就可以试图通过热度曲线来比较客观地分析技术趋势了。
如何通过热度曲线看技术生命周期？
如下图所示，是热度曲线（Gartner Hype Curve）。它是对新技术流行趋势的一个比较不错的建模。我们身边大多数技术的发展，其实都基本符合这个曲线。
如图所示，横轴是时间，竖轴是流行热度。发明者 Gartner 把一个技术的周期大致分为五个阶段，分别是：
- 萌芽期 （Technology Trigger) ：指的是技术被公开，媒体热度陡然上升，还没有成型
的产品和商业应用场景。 - 至捧期 （Peak of Inflated Expectations) ：指的是有了一些成功案例，当然也有失败
案例，技术被吹捧到了极致。 - 低谷期（Trough of Disillusionment）：这个时候，热度回归到理性，失败案例被放
大。如果产品不能让早期受众满意，那么技术就会在这个阶段消亡。 - 灵感期（Slope of Enlightment）：产品逐渐找准在行业的价值定位，二代三代产品出
现，产品逐渐出现理智的商业用户和成功案例。 - 产出期（Plateau of Productivity）：在这个阶段产品被主流市场认可和采用。
其实我们身边大多数的技术，都活不到产出期。其实能活到至捧期的技术，也寥寥无几。Docker 是一个非常符合 Gartner 曲线的经典案例。
在产出期之后，技术还有两个状态：
- 衰老期（Progressive Aging）：以该技术为基础的产品，已经逐渐开始被下一代的新
技术所替代，产品的市场范围和利润逐渐被蚕食。 - 退出期（Fade Out）：产品已经完全退出主流市场，仅仅在一些场景契合度与替换成本
都非常高的情况下，还在被维护和使用。
那么我们从这条曲线的描述中能得到什么结论呢？
结论就是：所有的技术都像人类的生命一样，也有终结的一天。这是个自然规律。从架构师的角度理解这句话就是：一个老去的技术就让他老去，快死的架构不值得投入人力和时间去维护，更不用说去翻修或者是复用了。
我曾经反复思考过，怎样才能避免让一个老的技术和架构侵入到新的体系里来？硅谷达人Guy Kawasaki 曾总结苹果公司 Macintosh 的成功，他认为关键就在于“低调加物理隔离”。我觉得这也应该是这个问题的答案。那就是把这种新的项目和公司其他部门分割开来。参与的人少一些，时间给宽裕一些，尽量远离公司的核心业务和人群。
我们也可以运用之前在尊重人性这个法则里提到的用户思维，来引导团队放弃一个衰老的技术。因为曾经再伟大的技术，在用户的面前都是渺小的。为了更好的用户体验，一切都值得推倒重来。
小结
其中我特别想强调的是，当你把自己的思考尺度从三五个月扩大到五年或十年，那么这件事情的价值必然会很大。这个放大思考尺度的动作，会让你用不一样的视角来看待技术。
看一次看不懂，看两次看不懂，但是看多了，自然会看出门道来。从本质上讲，这是个算法训练的过程。当你老用一个小尺度的样本来训练自己的大脑，那么你的大脑就是一个非常优秀的小尺度决策机。但当你坚持用大尺度的样本来训练自己的大脑，那么你在大尺度问题上的决策质量，也必然会得到提升。
作为一个架构师，知天道不够，还是要顺天道，也就是说我们的架构要符合技术的自然周期。反之，为一个落后的架构注入新生就是不符合天道了。而想要抗拒这种行为，我们就要从用户思维出发。为了更好的用户体验，要舍得放弃任何曾经伟大过的技术。
封面
本文只用作学习交流用途。首发于我的博客，原文链接：https://studeyang.tech/2023/11.html
内容来自我的学习笔记：https://studeyang.tech/technotes。欢迎交流与学习。
架构设计应顺应技术的生命周期
