郭东白的架构课_10_09法则四为什么要顺应技术的生命周期
你好，我是郭东白。
今天我们来讲第四个生存法则，尊重技术的生命周期，我们人类的各种活动都要符合事物的客观生命周期。
不论是农业社会重点打鱼，还是资本社会投资、创业行动太早或太晚，都会颗粒无收，技术也一样，也有自己的生命周期。
而我们作为架构师，如果看不清技术的生命周期，那么设计的架构就没办法向更有生命力的新技术建立自己的职业生涯也会受限。
那我先来完整描述一下这条法则。
在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。
而在这个选择空间里，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。
因此，对于架构师来说，要看准技术趋势，选择已经有规模优势或者即将有规模优势的技术，而不是选择接近衰老期的技术。
我们先来讲讲，为什么有的人能看准一个技术的生命周期，而有些人做不到找到了根因，我们就知道自己该怎么改变了。
因为见过有的人年复一年，辛苦劳作，但却是一无所成呢。
而有的人似乎没怎么使劲儿，却能飞黄腾达。
似乎大风总是吹向这个猪。
你嫉妒的牙痒痒，心想难道分就不能停下来摔死这头猪吗？有没有想过人家可能是会玩滑翔伞的御分飞行的猪啊，一个新的商业周期开始。
就好像大风周期可以把一个看似不怎么努力的育分之人推向成功。
事实上呢，如果从商业成功这个维度来看，把握好周期远远比努力工作更重要。
就好像很多人的职业不幸是在五年前，甚至是在十年前犯下的致命错误。
他们每天都在忙碌，来去匆匆，甚至没机会仰望星空。
但就是在恍惚之间，斗转星移，错过了一个大的商业和技术生命周期。
结果不论怎么努力永远延慢。
这个时代板牌我其实也是一样的。
我和我身边许多做技术的同学，多数时间都在看小尺度的问题。
日常的工作和注意力呢都是放在需求实现领域建模平台重构中间件升级这些事情上。
所以呢我的思考也被这些工作所主导，很少去思考五年、十年甚至是二十年的技术趋势。
我们不关注，当然也谈不上怎么去利用技术周期了。
其实，技术的生命周期就像是潮水潮来，汹涌澎湃，滔滔不绝，潮去风平浪静，贪图进行人一生中的黄金岁月中，也就是经历几个浪头而已。
就过去的四十年来说，真正的大的技术浪头有个人电脑、互联网、移动互联网AI,差不多呢是每十年一个。
我要在这种技术大浪潮之上，玩好冲浪，就必须看清楚浪头，准确把握好技术方向和入场时机。
如果说错过再等一个新的技术周期，那几年的黄金岁月就都浪费了。
所以接下来的两节课，我给你讲讲怎么看清楚，并且利用好技术的生命周期。
另外我需要特别说明一下，我不认为我自己真正看清楚过这些趋势，我也没能解到浪潮的最大事。
我之所以分享这个观点，是认为这个话题很重要。
我期望能通过我不怎么高明的观点，引发你更多的思考。
我分析我自己做不好的原因，是因为存在着三个人性上的弱点。
第一个弱点，自我麻痹，用繁忙的重复工作来代替深度思考。
第二，畏惧变化最小化改变，来维持自己的心理安全感。
第三，路径依赖，用过去的成功经历来应对未来。
我可能呢比大多数人信用的一点在于很早意识到了自己有这些弱点，所以无时无刻都在提醒自己去抗拒这些弱点。
那么这节课我就来认真分析一下这三个弱点。
只有克服了这些弱点，才有机会看清楚技术的生命周期，把握住新技术。
先看第一个弱点，自我麻痹。
自我麻痹，是指我们用各种方法让自己放弃思考和探索的欲望。
其实，大多数互联网从业者都是精英，从小到大都是学霸，内心不太可能接受自己不思进取。
但是人类进化出了一个自我保护机制，让我们不去天天担心风险，以至于我们常常会忽视自己所处环境的风险，导致我们不能全力探索新的出路。
于是，我们会让自己每天都忙起来，用勤奋来弥补内心的不安。
团队和公司也一样，尤其是一个营收压力特别大的公司，导个公司都忙着加班改代码，生怕老板看不到我们的勤奋。
这个时候没人敢去挑战长期的技术战略，也没有人会关注新的颠覆性的技术。
出现。
这些现象的根源就在于高层管理者和软件架构师。
有的管理者有意无意的把繁忙等同于有产出，于是就让团队持续的做毫无目标的布朗运动。
这实麻痹自己，越久就越难以突破。
越是没有突破，就越是没有勇气去突破这种恶性循环，让团队乃至整个部门一念到头都没有实质性的进步。
我们只有承认和面对现在的风险，才有勇气放弃麻痹自己的行为。
把部分注意力从当前的技术放到更新的更有颠覆性的技术上去，而不是被动的等着其他人告知自己下一步的需求。
接下来呢我将第二个弱点畏惧改变，再将马斯洛的模型我就提到了，每个人都有心理安全感的需求，这就导致我们往往会畏惧改变。
这是人与生俱来的本性，就个实际工作中的例子。
前段时间有位技术人员给我分享他稳定性治理的经验。
他描述了怎么通过一个独立的运维团队，把一组很烂的微服务运维到接近五个九。
我很诧异，他们直到现在竟然还在使用独立与研发的运维团队来保障公司核心系统的稳定性。
所来追问细节才知道这家公司连续几任CTO都没做过互联网高科用架构。
因为这个核心服务是公司营收路径上最重要的一环，所以连续几个CTO都不敢大兴土木，从根本上解决这个服务的稳定性问题，而是通过运维的方式先顶着这一顶就是四年多畏惧诧异，让这个团队从CTO到架构师，再到一线主管，都丧失了稳定性治理的勇气。
直到现在，这家公司还沿用前几年自研的微服务框架，不但没有引入现在服见的spring framework,也没有采用service mesh,从头到尾都是一套年久失修的老系统。
团队里离开的人越多，懂的人越少，就越没有人敢改动。
现在公司只能靠大量的全职运维团队来续命，以至于风险稍大的发布还是要靠运维团队来做。
其实，我们都一样，一旦赌注足够大，就会产生恐惧。
我们率先放弃了改变的勇气，然后会慢慢放弃改变的欲望。
德国强国离新技术趋势越来越远，最后是第三个弱点，路径依赖。
所谓路径依赖，就是你被过去的成功所蒙蔽，以为过去的成功可以复制。
当过去的成功成为你唯一的选择的时候，那你也不会关注，更不会探索新的路径了。
这就是我们小时候学习的守株待兔的故事。
其实你仔细想想，守株待兔这件事情再自然也不过了。
我们的大脑本来就是被不同的世界训练出来的，哪一天一个史诗级的训练样本发过来，正常人的神经元哪里能扛得住呢？再举个基础的成本。
几年前有个同学转岗到我团队，他之前在一个大部门里做基础架构，曾经做过合并部署，就是把几个相关的微服务部署在同一台虚拟机，甚至把几个微服务合并成一个巨式服务，然后部署在同一个JVM上。
其实这么做呢是个反模式，虽然会减少网络开销，提升性能，降低计算成本。
但是实质上这个过程是用长期的运维和人力成本来代替机器成本。
要知道，机器成本和网络带宽在今天还基本符合摩尔定理。
所以通过不断的增加人力维护和迁移成本，去替换每两年就减半的计算成本。
这么做呢其实是不理智的。
事实上，更大的成本是机会成本，这种句式服务会增加升级改造的难度，也就是说会让一个企业很难快速响应新机会和新的竞争。
不过在这个同学之前遇到的场景下，这么做的确可以带来非常实在的短期回报。
所以他之前的团队里就得到了很大认可，而且他也因此得到了晋升。
另外，他也很为自己的成功感到自豪，毕竟合并部署的技术难度非常大，因为越是调用量大的核心服务代码就越年久失修，依赖复杂，正儿包的冲突捡起来也就越棘手，他也是靠真材实选才能完成这个任务的。
所以他像多少有点技术特长的人一样，他也是拿着锤子到处找钉子，只不过他呢更想拿着雷神之锤。
另是我所在的毕业的计算量，远远低于他之前的部门，分值，流量还不到他们的百分之一。
这么一来，虽然开发成本一点儿都不少，但做合并部署的回报却远远少于他之前的工作场景。
而这个时候，cubnenetice已经开始崭露头角了。
Cubonnetis pots加上docker image已经可以完美的解决合并部署能解决的大多数问题了。
但是这位同学呢因为有了之前的成功经验，根本不再想着再探索合并部署之外的解决路径。
结果他项目进行到一半，大家意识到coubnenetice才是更合理的解决方案，所以他的项目也就早早收场了，这就是路径依赖。
如果我们被某个史诗级的训练样本冲击，过都会过度，相信自己过去的成功或者是失败的经验。
这会让我们看不到其他的技术方，能更别说新的技术趋势了。
关于影响我们思考的三个人性弱点，到这里就讲完了。
那么该怎么克服弱点去把握技术趋势呢？我先分享一下我自己的办法，我再重申一下。
我并不觉得自己的办法好在哪里，但我觉得有必要分享自己，克服这些弱点所做的努力算是抛砖引玉了。
首先日常过程呢我也会麻痹自己。
不过我跳出这个状态的办法就是每年会给自己留出两次深度忏悔的时间。
一次呢是在春节后，一次呢是在我生日之后，正好间隔半年左右。
在这个两个时间点，我会放下当前所有事情，回想我过去半年是不是做错了什么，有没有获得什么，本质上的能力提升，没有提升的话，我会很沮丧。
不过我心愿比较大过，两天又恢复正常了。
但是半年后，如果发现自己还是同样的沮丧，那我就会琢磨是不是要逼迫自己找个更有压力，更能成长的事情和环境了。
这就到了第二天，要主动克服内心的恐惧迎接变化。
这一点呢我天生要比很多人好。
虽然在变化来临的那一刻，我还是有会有很大的恐惧。
但是与此同时，我又无时无刻的在期待着变化，不只是在工作中，在生活中也一样随性的探索和意外的惊喜，总会带给我更大的乐趣。
如果说我不恐惧变化，那完全是胡扯。
但是呢我会用对获取惊喜的期待来压制我的恐惧。
这个办法呢对我一直很有效，路径依赖最难破，我的记性还不错，表达能力也很强。
而且呢我经历过很多波折，但直到我后来带团队的时候，我才发现这些特性看起来是优点，其实会放大我的路径依赖。
比如说当我面对一个相对来说经验没那么丰富，表达能力又没那么强的同事，我能够及时招回重点的案例和个人经历，然后再把逻辑准确表述出来。
这时候呢我会更容易说服周围的同事，导致我的建议会更占上风。
这个问题在我刚开始做CTO的时候变得非常严重。
因为大多数参会者是我的下属和同事，他们可能不愿意反驳我，哪怕是我错了，也不一定会纠正。
我意识到这种情况之后呢，我就开始刻意关注那些想法独重或者是经常挑战我观点的人。
比如说下属如果反对我的话，如果我们各自逻辑都很严谨，或仅是假设有些波同。
那我表达观点之后，我会强迫自己放弃自己的立场。
什么做？一来呢可以防止我有路径依赖。
二来呢也是为了培养下属，让他们有足够的决策空间和犯错空间。
这样一来，他们不犯错呢，我就有成长。
他们犯了错，他们自己也就有了成长，两全其美，何乐而不为呢？事实上，这个过程中我发现了非常多的优秀人才，我相信其中很多人的思考和成就必然会超过我。
假设你没有这些弱点，阻碍你的探索趋势，那么我们就可以试图深度理解技术趋势了。
我们先从一个问题讲起，那就是技术的生命周期是什么？我先来介绍一下garner热度曲线，这个曲线对新技术的流行趋势进行了建模。
我们身边大多数技术的发展，其实都基本符合这个曲线。
我把这个曲线放在了文稿里，听完音频你可以去查看，我也再解释一下这张图。
横轴呢是时间数，轴式流行热度。
Garner呢把一个技术周期大致分为五个阶段。
第一个阶段呢是萌芽期，指的是技术被公开，媒体热度陡然上升。
但是还没成型的产品和商业应用场景。
第二段呢是指本期指的是有了一些成功案例，也有了一些失败案例。
不过技术被吹捧到了极致，第三个呢是低谷期，这时候热度回归到了理性，失败案例被放大。
如果产品不能让早期的受众满意，那么技术会在这个阶段消亡。
第四个阶段呢是灵感期，产品呢逐渐找准了它在行业里的价值定位。
二代和三代产品相继出现产品逐渐出现离职的商业用户和成功案例。
第五个阶段呢是产出期，这个阶段呢产品会被主流市场认可和采用。
其实呢我们身边大多数的技术都活不到产出区，其实真正能活到制喷期的技术也寥寥无几。
Docker呢是一个非常符合garner曲线的经典案例。
你要是有兴趣呢可以读一下doctor呢从发家到膨胀，再到群体被打压，最后到了一个相对稳定的定位的过程。
这呢对你理解热度曲线会有很大的帮助。
不过gartner的热度曲线不完全是原创不国的著名社会学家garberel tard最先描述了创新传播的渗透过程，也就是s curve这个曲线的数轴呢是普遍性province,指的呢是一个创新的渗透程度。
就像马斯洛的理论一样，s curve的理论呢也是一个基本理论，可以用来解释很多和创新相关的现象的传播，包括现代企业的生命周期。
在未来的课程里呢，我们还会再次讨论这条曲线。
不论是热度曲线还是s curve都有一些缺陷，那就是没有对竞争技术的干扰做建模，都没有描述创新的衰老期。
事实上在产出期之后，技术呢还有两个状态，一个呢是衰老期，指的是以这个技术为基础的产品已逐渐开始被下一代的新技术所替代，产品的市场范围和利润逐渐被阐释。
另一个呢是退出期指的，是产品，已经完全退出主流市场，仅仅在一些场景契合度和替换成本都非常高的情况下，还在被维护和使用。
那么我们在这两个曲线的描述中能够得到什么结论呢？结论就是所有的技术都像人类的生命一样，也有终结的一天，这是个自然规律。
如果从架构师的角度来理解这句话，那给我们的启示就是一个老去的技术就让它老去快死的架构，不值得投入人力和时间去维护，更不用说去翻修或者是去复用了。
我们在前面讲到马斯洛模型的时候，就提到过，围绕一个旧架构体系的人的利益已经和这个架构深度绑定。
这就导致这个架构就像一个生命体一样，已经有非常强大的力量去延续它的生命了。
举个例子，某个大厂几年里连续三次搭建国际化的底层架构，每次都彻彻底底的失败了，而且每次失败都跟旧的架构体系有关。
搭建国际化体系呢有两种方法，一种呢是改造国内的系统，也就是我们常说的国内技术出海。
另外一种呢是重新构建一套系统。
大厂的架构本来就很老化了，处在技术生命周期的衰老期，甚至第一一次出海的时候还是巨石架构，核心服务一周只能发布两次。
最多的时候呢，有的同学发布几十遍都不成功，而且发布不成功，再等一周的情况也非常常见。
但呢这还不是核心问题，全球像中国这么大的单一市场就只有美国，而且大多数企业出海的第一站并不是美国。
那么把全球第一大单一市场的技术架构搬到一个只有百万或者千万人口的国家来运营，那一下子就水土不服了。
如果从交易体量来算，哪怕是最大的国家，也不到中国的百分之一。
百分之一是个什么概念？你可以换算一下，基本上呢就等于在你家修了一个公共厕所，有二十个吨位，但家哪怕有这个面积，但你能维护的过来吗？虽然大厂里也有反对的声音，但每次的反对声音都被压制了。
因为大家不是不知道自己的系统不合适出海，而谁都想从这个饕餮大餐里分一杯羹，哪怕自己的技术再老，那也要老当益壮，为公司捐躯。
我曾经反复思考过，怎么才能避免要一个老的技术和架构侵入到新的体系里来。
硅谷达人该cver saacki曾经更好的苹果公司的成功功，他认认关键能才能低调加物理隔离。
我觉得这个呢是一个不错的方案，那就是把把新项目目公公司的其他部门分割开。
参与的人少些时间给的宽裕一些。
然后才公公司核心心务务和群群。
我们呢也以用用之前在尊重人性这个法则里提到的用户思维，来引导团队，放弃一个技老技技术。
想想看，曾经再伟大技技术，在用户的面前都是渺小的。
曾了更好的用户体验，切都值得得倒倒重来。
你可会说我们今天讲顺应技术的自然周期，老去的就让它老去。
这个观点呢似乎太悲观了，难道我们就不能抓住一个技术的萌芽和发展机会吗？下节课我们就谈讨论这个话题。
好了，今天的内容呢就是这些。
我来总结一下这节课呢我分享了自己呢是怎么克服弱点来提升追逐新技术周期的能力和勇气的。
我特别想强调的是，当你把自己的思考尺度从三个月到五个月扩大到五年或十年，那么这件事情的价值必然会很大。
这个放大思考尺度的动作，会让你用不同的视角来看待技术。
看一次看不懂，看两次看不懂，但是看多了自然会看出门道来。
从本质上来讲，这是个算法训练的过程。
当你老是用一个小尺度的过本来训练自己的大脑，那你的大脑呢就是一个非常优秀的小尺度决策机。
但呢当你坚持用大尺度的样本来训练自己的大脑，那么你在大尺度问题上的决策质量也必然会得到提升。
这节课呢我还介绍了gartdinner热度曲线所表达的新技术生命周期。
同时呢还指出了热度曲线中缺少的衰老期和退出期。
了解一个技术生命周期的最核心的目的呢就在于利用这个周期为我们的架构活动创造出最大的价值。
作为一个架构师，知天道不够，还有顺天道，我们的架构要符合技术的自然周期。
反之呢，为一个落后的架构注入新生就不符合天道了。
而想抗拒这种行为，就要有从用户思维出发。
为了更好的用户体验，我们要舍得放弃任何曾经伟大过的技术。
最后呢是思考题环节，我们今天的思考题有三道，你可以选择其中一个作答。
第一题，除了我分享的三个弱点外，你觉得还有其他的弱点会影响我们看大尺度问题的规律吗？你是怎么克服这个弱点呢？第二题，你是怎么看待当下比较流行的热词呢？比如说云原生低代码响应式、编程元宇宙等等，你是怎么看这些技术的趋势的？第三题，你或是你周围的人有没有还在维护那些已经在业界垂死的技术呢？你认为这其中的根因是什么？好，谢谢你，我们下节课再见。