On this page
郭东白的架构课
- 郭东白的架构课
1 建立你的架构师成长战略
你好，我是郭东白，是一个做了 15 年架构师和 6 年 CTO 的人。
我先简单介绍一下自己。我从布朗大学（Brown University）获得博士学位后，在美国甲骨文、微软和亚马逊陆续工作了 15 年，做过研发、研发经理、 产品经理、数据架构师等等。2014 年，我回国加入阿里巴巴。
在阿里，我刚开始是 AliExpress 的首席架构师，后来成为 AliExpress 的 CTO。之后，我又到新加坡的 Lazada 担任集团 CTO。现在呢，我是车好多（即瓜子二手车母公司）集团的 CTO。
之所以详述我过往的经历，并不是想过分强调些什么，而是想要说明我从程序员做起，做过兼职架构师，也做过跨域架构师和总架构师。做过纯技术的 CTO，也做过带产品团队的 CTO。
你会发现，我经历了一个架构师职业发展的完整历程。这也是为什么我会写下这门课，来浓缩我对“架构师”这个职位的理解。我很期望通过这门课，帮助你在架构师这个职业上获得更好、更高的发展。
从我的“偶然成功”经历说起 看我的职业经历，你可能会觉得我很成功。不过，我一直认为自己是一个“偶然的架构师（Architect by chance）”。为什么这么说呢？我发现我性格上有一些成为优秀架构师的必要条件，比如自信和勇气。而我自己的人生经历又使我获取了一些机会，让我在架构师这个职业的发展上，比很多人要幸运那么一点。
我也开始反复思考，我这些所谓的“成功”，真的可以帮助到你吗？
在今天互联网行业这么内卷的大环境下，我过去的行为其实根本没办法保证我的成功可以复刻。但在梳理思路的过程中，我有一个想法越来越强烈：
假设我能有个时光机，回到二十多年前，把我今天写下来的架构方法论和成长建议给到那时的我，那我的人生肯定还会大有不同，绝对比现在幸运十倍甚至百倍。
事实上，我要写下的这些架构方法论并不是独特的发明创造。它们都很朴素、简单。它们在二十年前就已经存在，现在依然存在。它们在我身上适用，在我近距离观察到的其他优秀架构师身上也适用。
但如果不是我自己在一些事情上碰得头破血流，我就完全不会注意到，或者真正理解，更别说运用好这些原则了。这也是我下决心写这个专栏的原因。把我对这些原则思考的路径和推导的过程写出来，以提升你作为架构师的判断力和思考质量。
架构师不仅需要关注当下流行什么，要选择什么方案、用什么开源框架。一个以架构师为职业的人，更需要有战略意图和思考力，比如：
在一个架构活动中到底应该关注什么？干预什么？ 如何通过架构方案为团队或企业创造价值？ 如何在各种资源条件的制约下，去实现架构目标？ 如何通过价值创造让自己变得不可或缺？ 对这些问题的回答，可以让你在架构师的职业成长过程中有一个明确的方法论和取舍，让你对自己的职业成长有更清晰的路径规划，让你少走一些弯路，多一些成功机会。这就是我想交给 20 年前的自己的建议。
通过这门课，我期望能帮助你在架构师的成长这件事情上定义一个战略，提升你做架构师的成功概率。最终我期望达到的程度是：你能够设计出自己的职业成功（Architect career success by design），而不是靠运气得来的职业成功（Career success by chance）。
我也希望把我这些年的经验总结分享给你，让你少走弯路，否则你靠运气赚来的架构机会，也必然会因为你的实力不济而败干净。
建立你的架构师成长战略 刚刚我提到了架构师的成长需要定义一个战略。我为什么这么说呢？为什么你不能像我一样成为一个“偶然的架构师”呢？
我有一个坚信的理念：要想在架构师这个职业上超越别人，你必须要尽早建立好你的架构师成长战略。
我喜欢读史书和人物传记。我在大量的阅读中发现有一类人的成功，比如亚历山大，平常人是无法复制的，因为我们在“拼爹”这个环节就已经失败了。但有一类人，像埃隆·马斯克（Elon Musk）、史蒂夫·乔布斯（Steve Jobs）和蔡志忠，他们的成功经验是有迹可循的，可以拿来学习实践的。
怎么学呢？我借用企管学者哈莫与帕哈拉德（Hamel & Prahalad）在 Strategic Intent 这篇文章里提到的一个概念：“过去 20 年中达到世界顶尖地位的公司，每一家都有战略意图（Strategic Intent）”。
所谓战略意图，就是拥有与其资源和能力极不相称的雄心壮志。你把公司换成马斯克、乔布斯和蔡志忠等人，或者你身上，这句话同样适用。每个想达到顶峰的人，都应该有自己的战略意图。
哈莫与帕哈拉德还特别提到，只有这种极度的不相称性，才会让一个公司愿意突破常规，为自己创造机会，成功挑战不可能。
我想这么来定位我的整个课程：“假设你有做一个全球顶尖架构师的战略意图，那么我可以帮你把这个战略意图设计得更完美一点儿。”注意，重点不是说我是全球顶尖的架构师，而是说假设你在我的思考之上开始你的架构师生涯，我相信你会比不具备这些思考的人更有优势。
在我看来，当前软件行业的大量人才供给和全球范围内的残酷竞争，导致人才胜出更加不易，这也使得战略意图对职业成长产生的价值越来越大。可以说，缺少战略意图，你将很难成长为一名优秀的架构师。
我会怎么设计这门课？ 那么，该怎么培养自己作为架构师的战略意图呢？
我先要给你一个我的答案：靠记忆和技能学习，是成不了一个好架构师的。真正的架构师成长，主要靠思考力的提升。所以，在这门课中，我不会也不能教你所谓的架构技能八法，给你现成的答案。而是会通过三种方法，来培养你的思考习惯，让你和我一起完成关于软件架构方法论和职业成长的思考。
第一，使用演绎法来寻找架构原理，而不是归纳法。
课程里的很多知识听起来都是常识，似乎不需要推导，但我会花很长篇幅去解释背景、引用定律，最后推导出一个行为模式或架构法则。
虽然只学习最终推导出的结论，也可以帮助你成长。但更重要的是，我希望通过深度理解推导细节，锻炼你日常工作中运用演绎法来寻找规律的习惯。
这个过程就好像你和我一起去经历我 20 多年的架构生涯，然后在我的基础上，让你用更好的思考力来逼近真理，放大自己的价值。
需要特别说明的是，我会把我的全部推导逻辑描述出来，所以必然会显示出我思考中不完美的地方。这个时候，更期望你能指出我逻辑中的瑕疵，我们共同提升。因为在帮助我提升的过程中，也会引导你找到你自己的架构哲学和存在价值，就像尼采说的，Find your own way。
第二，我会穿插一些基本的架构方法、思维工具和建模技能，来帮助你提升架构素养。
有两方面原因。首先是浅层次的考虑，架构师的日常工作，就是借助一些常见的思维工具来完成的。但我发现我周围很多架构师由于不思考这些工具背后的意图，很难使用正确。如果使用不当，别人看一眼你的图，下意识就会觉得你缺少架构素养，那么你作为一个架构师的信任度就会被大打折扣。
然后是更深层次的原因。我个人坚信一个理念，就是软件架构虽然需要深度思考，但它更是一门实践的科学，必须学以致用。
整门课看似是理论课，但更是一个架构建模的实战案例。我用架构建模的语言、工具和思维方式写一门教你怎么做架构师的课，输出我体系化的深度思考过程，而你也需要经过一段痛苦的逻辑锻炼，来应用你对架构的思考。这就是“我做你看（Teach by example）”。
第三，课程中会有大量案例，都是根据我的真实经历加工而成的。
之所以需要加工，是因为一个完整的真实案例，会有太多的支线信息。去掉这些，可以帮你理清主线。不过更关键的是，案例只是一种学习手段，启发思考才是学习的目的。案例始终是要服务于课程目标的。
因而当你看到一个似曾相识的案例时，请不要尖叫，也不要试图对号入座，更不要去猜测这个案例是不是跟某人或某公司相关。如有雷同，纯属巧合。
我会怎么帮你设计战略意图？ 这个专栏分为四个模块，覆盖了架构师职业成长的四个不同维度。
模块一：六大生存法则
生存法则，就是你作为架构师必须要尊重的一些原则。如果违背，你指导的架构活动可能会面临巨大的失误，而你作为一个架构师的生存也会受到威胁。
影响架构活动成败的因素，主要有六个，分别是：目标、输入、输出、商业和技术环境、文化环境以及架构活动本身。我根据这些因素，以及我多年的架构实战，提炼出了六条生存法则，帮助你提升架构成功的概率，以及你作为架构师的增量价值。
生存法则的主要内容，如下图所示：
模块二：价值创造
价值创造指的是，从大型架构项目实施层面上考虑，你作为架构师必须要关注和干预一些重要的节点，然后在这个过程中去创造自己的增量价值。
我把架构活动分成八个节点：环境搭建、目标确认、可行性探索、架构规划、项目启动、阶段交付、全面上线和复盘。在每个节点中，你的每一步行动，包括进入条件、准备工作、应对办法等，都会影响架构活动的成功率。这就是你给架构活动带来的真实贡献。
所以我期望通过这个模块的学习，帮助你增长具体的风险识别和应对能力，提升你项目成功的概率。除此之外，也能帮助你学会怎么通过真实的贡献让自己变得不可或缺（Make yourself indispensable by contributing honestly）。我认为，这不只是做架构师的王道，也是做人的王道。
模块三：职业规划与成长
我把架构师的成长分解成五种能力，分别是：单个模块的设计能力、解决横向问题的能力、解决跨领域冲突的能力、全局性技术决策的能力，以及通过技术带来生存优势的能力。
这是一个架构师职业生涯中几个最重要的能力跨越，也代表了你在不同阶段要面临不同的挑战，解决不同复杂度的问题。所以想要跨越到更高的阶段，意味着你要先跨越一个能力障碍，建立全新的能力维度，而不是把现有能力做得更极致。
同时，我也把架构师的成长角色分为四种，分别是兼职架构师、跨域架构师、总架构师和 CTO。我会结合自己在这些角色中的经历和观察总结，提出助你突破障碍、完成能力跃迁的具体建议。
你可能会问：为什么我这么早就要了解那些 CTO 才要面临的障碍呢？答案还是之前那句话：做架构师，战略意图很重要！
模块四：思考力
这是一个接近于手把手传授技能的环节。思考力，在我看来这是一个架构师生存最核心的能力，甚至可以说是未来任何职业的核心能力。
怎么提高思考力呢？我也没有标准答案。我只能提供一些我和团队提升思考质量的方法，包括逻辑思维、批判思维、逆向工程、反思、跨越边界和数据分析。这些概念比较抽象，所以我会通过大大小小的案例来示范我常用的思考路径，提高你的认知。
此外，我们也会讨论中台等热词，带你从宏观视角去审视一个复杂事件，让你拨云见日，看清本质。
开篇寄语 之前在 QCon 做晚场演讲时，我问在场的人为什么想做架构师。不少人给我的答案是架构师挣钱多、有权力。在我看来这种动机是不太对的，因为你可能会想着该怎么通过学习课程来速成，来通过面试。
我想强调的是：架构师没有速成班，架构师的成功主要靠思考力的提升。
所谓的致富速成班是让分享致富秘密的人迅速致富，来收智商税的。就像一些短视频网站收割国人的智商一样，他致富了而你却还在贫穷中幻想着。
这门课不是讲编程或设计工具，你在这里也找不到任何现成的答案。我期望你学习这门课时，先放弃速成的心态，静下心，认认真真地学习一下思维方式和架构原则，只有这样，才能提升你在未知环境中判断和取舍的质量，最终通过架构设计为你所在的团队或企业带来竞争优势。我认为这才是架构师成长中最重要的条件，是架构师的“渔”。
事实上，在写专栏的过程中我也研究了极客时间其他不少专栏的作者，如果说他们只有一个共同点的话，那就是他们都具备优秀的思考力。这也是我期望你能从我的专栏里获得的能力。哪怕你不做架构师，这种能力对你的职业成长也是很有帮助的！
2 分析架构活动
一名软件架构师要为相对复杂的业务制定，并且引导实施一个结构化的软件方案。这个发现最终方案和推动实施的过程，就是架构活动。架构活动是你作为架构师必须要认识清楚的，但同样也是很多架构师所忽略的。
那么我们就从分析架构活动开始，看看我笃信的生存法则，到底可以怎样保障你架构活动的成功。
影响架构活动成败的要素有哪些？ 架构活动就是制定并且交付架构方案的过程。在整个软件架构的活动过程中，我们作为一个架构师，首先要做的就是确定架构设计方案。
这个方案需要和企业目标一致，与商业、软件环境相匹配，并且还需要满足各种资源的约束条件。而你作为一个架构师，要在这些方案中找到那个能够最小化资源和成本，最大化商业价值，以及最大化目标用户满意度的方案。最终，你还要组织技术团队交付这个架构设计方案。
这里我们需要明确一点，在一个企业内，大多数研发任务的交付都与架构师无关。多数时间，研发团队开发的软件解决方案和软件产品是用来服务用户的，不需要架构师的参与。但当面对跨多个团队，或者是大面积的技术改造时，就需要架构师参与到其中，来完成软件研发任务的交付。
如图所示，展示了架构师的全部活动，按照颜色分类，主要包括三个部分。
中间白色部分是架构师的决策领域，包括架构方案和架构活动。
需要强调的是，架构师对研发活动没有完全的决策权。也就是说，架构师无法决定研发项目的选择、优先级、排期、代码实现方式等等。
同样的，其他影响架构活动的因素，也就是图中白色区域以外的部分，架构师也不具备决策权。这些部分包括目标、商业环境、架构活动消耗的资源，以及产出的商业价值。架构师仅仅可以关注、影响和干预这些因素。
黄色部分指架构师的输入和输出部分。
输入不仅指架构活动消耗的资源（商业资源、研发资源等）和成本（时间成本、机会成本等），还指不受架构师所控制的部分研发活动。两者会综合影响架构活动的最终结果。
而输出呢，不仅指架构活动可能带来的短期和长期的商业价值（公司的规模、效率和体验等），还指架构活动为目标用户群体所提供的直接价值。这就意味着我们架构师必须时刻关注自己的输入和输出，它们是保证架构活动成功的前提。
蓝色部分指架构师的工作环境，主要包括企业所处的商业环境，如竞争、市场、监管等；企业内部的技术环境，如交互设备、sensor 网络、计算环境、外部的数据源等；以及企业和团队的文化环境。环境在很大程度上会影响架构方案的选择和实施路径，但同时也是大部分架构师最容易忽略的考量因素。
当我们把架构师的活动归纳总结后，很容易就能清楚到底是什么在影响整个架构活动的成败。我将它们总结归纳为六个要素，分别是：目标、资源、行为、天时、地利以及人和（要素的排列顺序与法则的顺序并不是一一对应的，在这节课的最后我会进行解释）。
第一个要素是目标。事实上，确定目标应该是架构规划的起点，所以深入理解目标对你的架构活动至关重要，但这一步往往会被架构师所忽略。
因此我们生存法则的第一条，就是教你如何去理解和干预这个目标，确保最终的架构活动能够为你所在的团队或企业带来价值。否则目标错了，你的项目永远也没办法成功。
然后是资源。我们所有的活动都要消耗资源且最终要创造价值，就是图中标记为 3 的部分，架构活动当然也不例外。在大多数企业里，甚至包括非盈利型组织，都需要关注有限资源的利用率，以及架构活动最终可以带来的商业回报。
所以我们生存法则的第三条，是关于你应该如何通过架构活动来最大化你所贡献的商业价值的。否则资源不足或者是消耗太快，你的项目也同样无法成功。
有了目标，有了足够资源，如果你还有正确的行为，也就是正确的做事方式，那你就能逐步逼近正确的架构方案，并且指导团队完成它。然而不确定性是互联网大环境的常态，那么身为架构师，你应该在周遭环境发生变化时做出什么样的响应呢？这正是我在第五条生存法则要回答的问题。
做成一件事情，如果周边条件成熟，环境好，那么事情就会进行得很顺利。反过来，如果条件不成熟，或者你逆势而为，那就会很艰难。架构活动也一样，影响它成败的要素也有天时、地利和人和。
先说天时，这里指的是商业环境和技术环境的变化趋势。环境复杂多变，那么看清楚变化趋势的本质，就可以让我们的架构决策顺势而为，借助于环境的变化来成就我们的团队、企业。这正是我们第四个生存法则要覆盖的内容。
再讲地利，就是你作为一个架构师待的地方，你所在企业的文化环境，这是我们作为架构师无法改变的部分。虽然没法改变，但“良禽择木而栖”。那么第六条法则就会帮助你选择最有利于架构师职业发展的文化环境，最大化你的成长。
最后讲人和，在上图中标注为 2，架构活动中涉及的人主要是研发人员和目标用户。在输入端，架构师需要与多个研发团队协作，因而理解研发方的核心诉求就尤为关键。在输出端，架构师产出方案的最终评判即目标用户的长期满意度。因此深度洞察用户的人性就是保证架构活动成功的关键所在。这是我们第二个生存法则要覆盖的内容。
理解了影响架构活动的这些要素，我们很容易就知道应该以什么样的视角来关注和干预这些架构活动。而我根据这些，提炼出了你作为架构师必备的六大生存法则。
如何利用生存法则，最大化架构师的成长？ 简单来说，生存法则指的是我们作为架构师在设计架构方案和组织架构活动时必须要尊重的一些原则。如果违背这些原则，那么作为一个架构师的生存就会受到威胁。
之所以总结提炼这些原则，是因为在我二十多年的职业生涯中，一次又一次地看到我周遭的架构师，包括我自己，在违反这些规则后付出了惨重的代价。所以我会将自己经历的、看到的大量失败案例呈现出来。
我先简单陈述一下这六个法则的核心内容，然后再讲你应该怎么学习和应用这些法则。
第一条，架构师必须保障整个架构活动有且仅有一个正确的目标。这是架构活动的起点，也是甄别架构方案的主要输入，所以架构师有义务影响和干预这个目标，以确保目标本身的正确性。
第二条，架构活动需要尊重和顺应人性。架构活动既要服务用户，也要组织研发人员协同工作。这就意味着架构师必须洞察研发人员和目标用户的人性。从人性角度出发来做决策，才能保障最终面向用户的方案具有长期正确性，以及面向研发同学的实施过程具有可行性。
第三，架构师永远需要在有限资源下最大化商业价值。对于任何一个架构活动来说，架构师的可用资源，包括商业成本、研发成本、时间成本、迁移成本等，都是极其有限的，所以架构活动必须在这些限制条件下，最大化商业价值。
第四，架构选型必须要考虑到所依赖的商业和技术模块的生命周期。在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。那么在这个选择空间内，理解、顺应且利用好商业和技术周期就至关重要。也就是说，架构师要看准技术趋势，一般情况下，要选择已经有规模优势或者是即将有规模优势的技术，而不是选择那些接近衰老期的技术。
第五，架构师需要在架构活动中不断干预活动的目标和内容，以同时保证整个架构活动可以为企业注入外部适应性。这是架构师个人能在架构活动中创造的核心价值，而且也是架构师职业成长的必须，甚至也是架构师的荣耀所依赖。最终正确的架构选型会因为有很强的外部适应性而长期存在。
第六，架构师需要在一个相对安全的文化环境中探索未知, 只有这样，才有希望找到正确的架构方案。文化环境是架构师最难影响的，因而架构师要有足够的判断力，认清自己所在的文化环境是否有利于探索正确的架构方案，不要在一个错误的环境中浪费自己的宝贵生命。
可以看到，这六个法则的顺序跟我们刚才提到的影响架构活动成败的六个要素的顺序不完全一致，原因在于我是依照法则本身的重要性进行排序的，而不是要素的结构。
不过看完这些你可能会问，法则这东西听起来感觉很虚、也很简单啊，难道你讲的法则有什么精妙之处吗？
这些法则确实平淡无奇，原因也很简单。软件架构是人类活动中很小的一个细节，而先哲们老早就总结了人类活动的各种规律，譬如经济学、社会学、心理学、系统科学等等，软件架构这个活动自然也跳不出这些规律。
而我要强调的是，在信息化时代，我们获取这些规律并不难，难的是怎么将这些规律准确地应用到软件架构活动中去。
因为信息泛滥正让我们面临着一个颇为严峻的问题：通过朋友圈、短视频、网课等获取的规律教育，往往是泛泛而谈，甚至和软件架构领域扯不上关系。所以当我们在软件架构领域碰到某个规律可以适用的场景时，不仅很难识别出来，而且也不知道该如何应用。所以我们并不是缺少生存法则，而是不知道什么场景下该应用哪一条规律，也不知道哪一条规律是跟软件架构领域有关的。
比如说我们常说的摩尔定律、康威定律，到底和架构活动的哪个部分有关呢？你做架构的时候该怎么考虑它们呢？
因此，我会花大量的篇幅去说明法则的上下文，从而达到这样一个目标：不是要你记忆法则，而是知道怎么识别某个法则的适用场景，以及出现问题后的干预办法。
所以我期望你用一种完全不同的方式来学习这个模块：请你不要简单地相信或者背诵这些生存法则，而是跟我一起解释到底是什么原因让我把某个规律当成架构师的生存法则。也就是说，当你学习整个模块的时候，你需要试图理解我是如何被我所经历的事件教育的，并由此推断出这些生存法则的适用环境。
打个比方，假设你相信上帝存在，那么你可以认为我被上帝安排了一连串的经历，从而得出了自己坚信的一套生存法则。但是假设某一天你给别人讲这门课，你的经历与我不同；或者是因为你相信了这些生存法则，让你避免经历我的痛，而你自己的痛彻心扉的经历，又会让你总结出另外一套生存法则来。
这样一来，你理解了我的经历，也认同其中的推导逻辑。那么当某一天，你恰巧遭遇了一个类似的场景，可能会迅速思考这个法则是否适用。或许事过境迁，我讲的法则已经不再完全适用，但法则的核心逻辑依旧适用。不论是哪一种情况，只有理解它的背景和推导逻辑，你才能决定是否冒一次有备之险（take a calculated risk）。
这就是我期望你学习这个模块后，最终能达到的理解程度。那，接下来的一讲，我们就开始学习第一个生存法则吧。
3 架构规划中的重要性
你肯定看到过这样的观点：架构设计就是一个迭代的过程，我们要不断发现并且补偿现阶段软件设计的不完美，然后通过各种手段打补丁升级。因此，架构设计永远都是螺旋上升的，没有也不需要目标的指引。
也有人认为定义目标并不是架构师的职责。毕竟目标是架构活动的一个输入，由需求发起方设定，不受架构师控制，所以架构师能做的就是想办法满足这个目标。
然而我要强调的是，在每个架构规划启动之前，应该有且仅有一个正确的目标，这是架构设计的起点。目标不正确，你和你的团队再努力都没办法成功。目标的重要性，就在于它能够一直引导我们走在正确的方向上，同时帮助我们做取舍，在多个备选架构方案中作出最优的选择。
这正是我要讲的架构师的第一条生存法则：所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配，这是你架构设计的起点。否则，系统就会变得复杂和无序，缺少结构性。
架构活动为什么需要目标？ 你可能不太相信为什么架构活动会没有一个正确的目标。这样的案例在现实中有很多，我来分享其中一个。
我们公司目前大多使用 Kafka 来做架构，但有一位架构师认为开源社区里正流行的 Pulsar 的设计理念与云原生趋势十分契合，值得在全公司推广。于是他经过多方调研，搭建了一套系统预研，并针对一些小场景做了测试。测试结果很让人满意，他便整理了一套 PPT 来找我做汇报。
他的 PPT 写得非常好，无论是 Pulsar 的设计亮点还是对我们公司的迁移场景，思考得都很全面，我从中也收获不少。但当我问他：“你这么做的目标是什么？”，他显然没有料到我会问这样一个问题，所以在沉默了一阵子之后才说：“技术先进性？”
事实上，在一个企业里，技术先进性很少会是一个架构活动的正确目标，所以很多人做架构升级都只是为了做而做。
从我过去二十多年的架构经验来看，一半以上的架构活动在发起之前都没有明确的目标。这种架构活动执行到最后，多个协同模块之间必然是一个散乱的结构，如下图所示。
如果在初期就有一个明确的目标，那么做到最后，子模块和初期目标就会是大致对齐的，同时也会最大化对目标的贡献。
目标缺失是由多种原因造成的，刚才我们讲的情形只是其中一种表现。接下来，我就来讲讲目标缺失具体有哪些根因。下节课，再来提供你作为一个架构师的具体应对思路。
目标缺失的两大根因 关于目标缺失的根因，我们可以从技术和业务两个维度来寻找。
技术上：目标缺少全局视角 由于技术原因导致的目标缺失往往有个非常积极正面的出发点：那就是技术同学对于先进技术的强烈好奇心。
很多同学会经常在社区内互相讨论新技术新趋势。当好奇心转变成行动，也就意味着我们已经从一个深受技术理念影响的评价者转变成了追随者。正是这种内在的驱动力，在推动着公司、行业乃至整个社会的技术发展。
探索新技术是一种积极正面的力量，我非常鼓励团队中的同学这么去做。
不过就像我前面提到的案例，从探索新技术变成漫无目的的架构尝试，中间缺失的就是全局思维：架构师没有从全局视角去思考架构活动的回报，以及它对企业整体复杂性的影响。
技术尝试跟业务和产品尝试一样，每一次尝试都是在耗费企业的机会成本。如果是一个正处于创新期和成长期的企业，那么每次尝试还会耗费相关同学的心力。心力是一个极其有限且宝贵的资源，一旦尝试失败，耗尽心力的同学很有可能会选择离开，加剧整个企业心力的损失。
除此之外，每次尝试都会给原有系统注入新的复杂性，从而导致整个系统的复杂和无序，这就是墒增的过程。
看到这儿你可能要问我了，如果我新起一个项目，是不是就可以引入新技术了呢？一个公司当然要引入新技术，不过还是那句话，关键在于要有一个明确的目标，而不是以一种漫无目的、浅尝辄止的态度去做技术尝试。
我曾在一个不到 700 人的研发团队里，看到过 8 个自动化 BI 报表工具、5 套 UI 组件、十多套工作流引擎。对于日常运维、软件升级、安全、合规和审计而言，这简直就是灾难。我相信在这些技术设计之初，从开发同学的视角来看，或多或少都有一些技术先进性的理由。但同时我也可以断定，引入这些技术时很少有人思考过全局复杂性。这就导致整个企业的软件从一个同构的系统迅速衰变成一个混乱无章的大杂烩。
值得注意的是，在这些令人吃惊的数字后面，其实还有一个不太光彩的原因，那就是开发者的个人利益。举个极端的例子，这个团队曾经有个做大数据的负责人，匆忙引入了开源领域的一个新框架，并在会议上作了个演讲。但是讲完之后没多久就提了离职，留下个做了一半的烂尾项目。
也就是说，开发者的个人喜好、技术能力，甚至与其他开发者的关系，也会影响到自己是否会引入一个新系统。
在技术层面上，还有另外一个常见的原因，就是信息沟通不畅。因为层级低的技术同学很少做跨团队跨部门沟通，一些小范围的架构改造也找不到一个官方版本可以借用，而且从头开始的时候，总觉得别人的设计太复杂，有过度设计的嫌疑，所以都是自己去新写一个版本。而一旦业务逐渐增长，小工具长成了大工具，就变成了一个新的变种。
这里我给你分享一个案例。当年微软内部有不少人骂微软的浏览器内核性能差，说某某开源方案很好使。团队后来就请这些持反对声音的人一起去做一个内部项目，请他们在开源的基础上做起，但是要求必须支持所有的测试场景，包括向后兼容的部分。
开始的时候，开源的版本性能是好，但是等杂七杂八的需求全部堆积上去之后，性能反而变差了，没过多久项目就叫停了。
这个案例告诉我们，一方面，做业务和做产品的同学要有正确的取舍，不能见什么功能就要什么功能。
另一方面，我们做技术的同学也不要动不动就认为别人的东西过度设计了，认为我的场景简单，就应该定制自己的技术。往往你的场景简单，仅仅是因为你的业务还没做起来。等业务做大之后，会发现业务根本不是你想象得那么简单。我见到过太多所谓的“极简设计”了, 事实证明，大多数的极简设计，要么早早夭折，要么越做越复杂。到头来还是得用专业版设计进行替换。
总结来说，从技术维度去思考目标缺失的根因，就在于缺少全局视角，主要有三方面的表现：技术同学对于先进技术的强烈好奇心，开发者的个人利益，以及信息沟通不畅。
业务上：目标太多、不明确
比技术原因更常见的是业务原因，主要表现在：目标太多、目标不明确或者是目标摇摆不定。
比如业务 leader 有一个极具创意的方案，但业务压力大，市场调研的准确度也很难判断，所以多数时间需要靠 A/B 测试来决定这个方案是否要推广。可以看到，业务同学连需求之间的一致性和相容性都没搞清楚，就把需求一个接一个地转给技术同学。在这种大量 A/B 测试的背景下，业务逻辑层层累积，系统变得越来越臃肿，老代码谁都不敢删。
还有一种情形在大公司里比较常见。有的 CEO 喜欢高举高打，上任之后先大搞运动。我曾经见过一个 CEO，他在一个季度里同时启动 10 个项目，目标五花八门。几乎是把整个部门分成了十个子公司，让他们各自为战。在巨大的交付压力之下，团队根本来不及做统一规划，每个项目各自为战，整个季度几乎全员 997。
结果呢？3 个月后项目完工，业务仍然在原地踏步，CEO 挑出个别数据指标上有亮点的项目做了个表彰大会，就万事大吉了。运动虽然失败了。但漫无目的的、随机大撒 CEO 项目的玩法，却被完美保留下来发扬光大，然后演变成董事长项目、集团项目、BU 项目、必保项目等新名目。
这种混乱对技术架构伤害很大，不过倒也不致命，是有技术解的，下节课中我会专门来讲。只是这种行为对团队技术文化的伤害非常大，一般来说，那些追求极客精神和科学决策的同学，往往非常反感这种随机探索的管理方式，所以大都会选择离开。
还有一种情形不太常见，但却极端致命，值得我们重视。那就是一个公司有两个明确的目标，这有点像华山派的剑宗和气宗之争。
举个例子，在一个做电商的公司中，剑宗会认为做业务要像自营一样对整个供应链做强管控，这样会有更好的用户体验，以获取更多的市场份额；气宗则认为道法自然，做业务就要走开放的平台模式，最大化平台的丰富度，由用户选择来淘汰落后的商家。
两派自然是互不服气。如果剑宗上位，公司就大兴剑宗玩法，一切设计都走供应链路线。如果剑宗连续折戟，那么气宗上位，之前的一切设计都推倒重来，全走平台模式。当然，任何时候气宗里都会有喜欢练剑法的，剑宗里面也有运气自如的。但公司内部不论是练气还是练剑，目标从来都不统一，那么在商业竞争中，结果只能是比剑输剑，比气输气。
事实上这种情形根本没有技术解。如果一个公司在战略上不断摇摆，就表明这家公司干脆没有战略意图，那么我更建议你另谋高就。
至此，我们已经把目标缺失的两大根因介绍完了。那么我们该如何应对呢？这正是我们下节课要讨论的内容。
小结
这节课我们讲了架构师的第一条生存法则，那就是每个架构规划启动之前，都应该有且仅有一个正确的目标。而你作为一个架构师，必须要搞清楚架构设计的目标到底是什么。只有找到了这个问题的答案，才能在多个方案中作出正确的取舍。
不幸的是，我们多数的研发需求和架构规划在发起前都没有明确的目标，最常见的就是竞争对手这么做了，要不我们也照搬一下做个 A/B 试一试？不论是业务产品还是技术尝试，除了耗费大家的心力，还会给原有系统注入新的复杂性，导致整个系统的无序。因此我们需要做架构治理，剔除无序的元素，让系统重新回到结构化的状态。
这也是为什么我一再强调，架构规划必须始于唯一且正确的目标，并且这个目标还应该和公司的战略意图相匹配。
思考题
在每节课的思考题环节，我都会留三道题。建议你任选其中一道作答，目的不是做得全，而是思考得深，让你自己有所得。
- 由于业务压力，我们经常会面临各种各样的重点项目。那么，你是怎么判断一个项目的重要性呢？怎么决定自己思考力的分配呢？注意，这里指的不是你被上级领导分配的写代码的时间，而是你发自内心觉得某件事情很重要，你主动花大量功夫去思考的过程。也就是说，你自主决策的个人注意力分配的算法是什么？
- 你或者你周围人是否曾建造过一个非常精巧的轮子，但是随着时间的推移，变成了诸多要被清理的破轮子？当时发明者有没有意识到这个轮子会增加系统的复杂性呢？为什么？
- 在你参与过的架构活动中，最让你感到兴奋的一个目标是什么呢？为什么？
4 第一个生存法则:如何寻找正确的架构目标
你好，我是郭东白。上节课我们讲了目标在架构规划中的重要性，也明确了目标缺失的两大根因。那么这节课，我们就来聊聊该如何寻找正确的架构目标，以及如果目标制定错误，该如何挽回。
如何寻找正确的架构目标？ 主要分为三种情况，我们来分别讨论。
确认一个正确目标，且要试图逼近它 一般来说，我们相信达尔文的进化论是普遍适用的，那么企业的所有活动都应该指向一个终极目标：它们要能够为企业带来长期的生存优势。架构活动作为企业活动的一种，自然也逃不出这个终极目标的五指山。
但这个终极目标太难验证了。怎么知道我们的架构设计会对公司产生什么深远的影响呢？我不就是设计一个 50 人日的评价体系或流量归因的服务吗？不至于还要在架构设计文档里评估对企业的生存优势吧？再说了，就算我想做，也不知道怎么评估啊！
你肯定会有这么一连串的疑问，而标准答案是什么，其实我也不知道。不过在做架构设计之前，我永远都会问自己这样一个问题：这个架构规划为什么可以给企业带来生存优势？
对这个问题的回答，其实渗透了你对几个价值创造维度的理解，包括：促进企业规模化；加速企业模式探索；提高企业效率；提升用户体验的理解。当然，最理想的情况下，你还应该把一系列可以量化的指标作为架构方案的预期产出。然后你就可以用评分卡的方式，对架构方案有个全局的产出度量。
当然，在现实项目中，这些产出很难量化到业务指标上，尤其是由技术主导的项目中，比如说数据模型标准化、网关统一、框架升级，那就更难了。那么对这个项目必要性的论证，就需要有更直接的量化工具。
就像我作为一个 CTO 去赞助一个项目，我一般期望项目在半年内的回报要大于投入。也就是说，你投入 100 人日做一个技术项目，那你半年内就要省出 100 个人日来。除非有其他的动力因素存在，比如说审计、合规、安全等，否则我就不做该项目的赞助人（Sponsor）。
显然，未来充满不确定性，终极目标很难验证，但通过反复问自己这个问题，我们就可以不断逼近这个唯一且正确的架构目标。正如人生意义这种终极问题一样，很多哲学家也没法给出一个确定的答案，但正是对问题的讨论，让我们一直保持在逼近真理的路上。
如果你稍稍留心就会发现，很少有人会在架构设计中问自己这个问题，而这恰恰就是架构设计的万恶之源。
事实上，在中国的互联网行业，架构师往往不是在两个最大化生存优势的选项中做选择。更多时候，是在一个不能带来太多优势和一个甚至会带来劣势的、画蛇添足的方案中做选择。
为什么我特别强调中国的互联网行业呢？因为在过去十年，中国的互联网公司有着比全球任何国家更多的资金和人才供给，甚至是供大于需的。我们有千团大战、共享经济大战、新零售大战、社区团购大战，几乎每个流行热词背后都是不惜一切代价的资金和人才投入。
在这种背景之下，许多架构设计都是以饱和攻击的方式全方位最大化投入的。或许参战各方都在想，先用尽一切手段活到明天再说。
但当我们去研究各个大战的最后胜出者时会发现，他们都不是靠全程饱和攻击取胜的，而是靠对阶段性精确目标的最大化投入从而在惨烈竞争中胜出的。架构其实也一模一样。
那么你作为一个架构师，怎么判断一个目标是不是正确的呢？我的建议如下：
首先，要用企业的战略意图去鉴定架构活动目标的正确性。 接着，如果目标与战略意图不匹配，那么你要试图影响甚至是改变这个目标。你可以与架构项目的发起人反复沟通，陈述你的理由，建议他去寻找另一个更接近战略意图的目标。 如果目标与战略意图匹配，那你要看看是否存在一个更合理的目标，可以让企业能够更快地逼近战略意图。 如果你能保持这么做，哪怕你不知道终极目标，但是你已经在不断逼近了。而且能做到这一点，你就已经超越大多数架构师了。因为你不断检验目标的过程，也是你判断力不断提升的过程。
不过这里还有两个关键问题。第一，什么才叫匹配呢？我应该用什么样的一个标准来衡量匹配度呢？
我认为所谓的一个架构活动目标和企业战略意图相匹配，指的是架构活动对一组 KPI 的贡献，需要与对表达企业战略意图的 KPI 形成增强关系。简单来说，就是你的 KPI 对战略意图是有正向贡献的。
举个例子，大多数公司的战略里都对“客户第一”有着某种形式的表达。假设你的架构活动有一个作用是提升性能，比如说减少用户交互过程中的延迟和等待。那么你的架构活动在这一点上，对战略意图的贡献就是正向的。反过来，假设你的架构活动需要用户做强制性的安全身份验证，那么用户的正常体验就会被打断，这个时候，你的架构活动对战略意图的贡献就是负向的。
第二，如果发现目标不正确，那该怎么办呢？
一般来说，一个架构活动的发起如果有比较充分的理由和论证，那么架构活动的目标往往就会是正确的。但你肯定会遇到目标不正确的架构活动，这个时候，你作为一个架构师就要有义务指出来。
然而很多架构师在这时是畏缩的，因为在一个架构活动中，架构师的角色往往要低于项目赞助者和技术资源提供方的角色。甚至对你而言，好不容易拿到了这个机会，哪怕方向错了也要硬着头皮冲上去。
在这种情况下，我期望你有良知，同时也要有勇气阻止企业犯错。我自己曾经因为三次阻止一个顶级项目，而在职业发展上受到了不小的伤害。但也正是因为我这样做了，使得我能够从容地面对自己的良心。更为重要的是，之后事实证明我的判断是对的，这让我自己的决策自信心得到了大幅的提升。
这， 也就是决策自信心，才是一个架构师从架构活动中获得的最宝贵的礼物：在多个比你资深，并且比你权力更大的人面前，你坚持了不同于他人的正确判断。
当然，多数时候不是对与错的判断，而是判断架构目标是不是最优。那么在这种情况下，你作为一个架构师该如何影响架构目标呢？我们接下来就从技术和业务两个维度来分析。
关于技术驱动的目标 技术人员往往缺少全局视角。在这种情形下，你可以通过引导的方式，帮他找到一个更好的方案，让他从战略角度去思考一个架构方案对公司的终极价值。 最终，找到能够最大化公司长期价值，并且成本合理可控的方案。
就拿上节课讲的在公司引入新技术方案的情形来说。在公司引入新技术，我们也提到了虽然这么做有个人利益驱动的缘由，不过绝大多数研发人员还是有着非常积极正面的出发点的。所以在处理这些方案时，你首先做的不是全盘否定，而是站在他的视角，看到、并理解他的出发点的正确部分是什么。
接着，在彻底理解新方案的价值之后，你就可以比较客观地思考这么六个问题：
新方案的实现成本有多少？ 新方案上线后带来的短期价值有多大？ 这个新方案是否可以全面替代现有方案？ 全面替代的实施成本有多少？ 全面替代之后，这个新方案带来的长期价值是什么？ 如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？ 事实上，大多数人在看一个新方案时，只是思考了前两个问题，然后就匆忙做了判断。要知道，这完全不能让建议者看到他的方案对全局的影响。
毕竟许多方案根本不具备全面替代性，或者全面替代的实施成本太大，根本无法完成。一旦新方案被通过，虽然能暂时提升局部的效率，而从长远来看，仍会损失整体架构的合理性。
但如果拿出的方案可以完整回答上述六个问题，那就值得你去做长期规划并认真投入了。就拿我们在上节课提到的引入 Pulsar 的案例来说，要在公司内全面替代 Kafka 的成本巨大，短期内的回报完全不合理，所以提出这个方案的同学最后也觉得不合适。
除此之外，在实际工作中，我们更需要考虑的问题是：对于不具备长期价值的项目，我们该怎么拒绝，并且还不伤害建议者的积极性。
后四个问题这时就又要发挥作用了。你可以引导建议者去思考这些替代和实施的成本，也可以帮助他去寻找这些问题的最优答案，让他理解你作出决策的出发点和正确性。
你甚至可以把最困难的事情交给他，比如说让他去负责调研全面替代的成本。这样他才能从你的视角看到问题，从而得出和你相同的判断。这样一来，不仅他的判断力可以得到成长，你也能多一个帮手，而不是对立者。
所以你看，哪怕我们作出了正确的决策，但考虑到人才的成长和团队的稳定性，在执行过程中也要关注研发同学的心理感受。顺便说一句，这个案例也同样适用于调和局部架构和全局架构的冲突。
总结一下，通过这个案例我更想强调的是：关于架构目标的决策，对于一个人或一个团队的影响是巨大的。所以当你有了一个正确的关于架构目标的决策，要知道这只是一个起点。你还要认真思考这个决策的实施路径，让大家团结在正确的架构目标上，而不是你自己一个人举着架构目标，变成孤家寡人。
关于业务项目的目标 现在我们谈另外一种情况，业务目标太多或者是不明确，从而导致架构活动目标缺失的话，你该怎么办？
作为架构师，在业务目标的确定上我们往往没有最终话语权。那么这个时候，我们面临的问题就变成了：在没有权利改变业务目标的情况下，该怎么做才能最大化公司的生存呢？
我们先看一个比较棘手的案例，假设碰到上节课讲的业务方大搞运动的情形，作为架构师你该怎么办呢？
这里我们要引入两个概念：决策者和取舍权。决策权决定要什么，取舍权决定保留什么。一个决策者，必须要行使自己的取舍权，在自己的决策领域内做取舍。
那种天天叫嚷着既要、也要、还要的人，其实就是不知道客户要什么。他们行使了自己的决策权，做了全部都要的决定。但也放弃了自己的取舍权，用全方位搜索来代替自己的思考无能。做技术管理、做产品、做业务，都一样，我们必须要有且仅有一个明确的目标。
这里我要强调一下，我们不是说一个项目不能同时优化多于一个 KPI。但如果这么做，你必须要给出权重。比如说做电商可以同时优化 GMV 和成交客户的满意度，那么决策者就需要在这两个目标之间给出一个权重，做联合的多目标优化。这么做的本质，其实是把两个 KPI 合成一个，最大化高满意度的 GMV。这个时候，其实你还是只有一个明确的目标。
事实上，取舍权是一个决策者最重要的权限，这个权力决定了别人说是既要、也要、还要的目标，到底哪个必须要，哪个可以暂先舍弃。
很不幸的是，这个权限却经常被不明不白地下放了。原因就在于决策者不是在目标上做取舍，而是选择向团队做无度的索求，制定一个又一个目标。然而无度的索求是不可能被完全满足的，这就导致取舍权被分散给了执行者。
举例来说，假设决策者要求在三天之内上线一个新的商业模式。在这种情况下，团队肯定会给你上线一个模式，但究竟是不是你想象中的商业模式，那很难说。至于稳定性就不用提了，因为决策者完全没有给团队留出做稳定变更的可能。
我特别要强调一下，这里所说的决策者不一定是顶层管理者，而是任何一个层级上能做决策的人。这意味着在你的决策范围内，如果你不做取舍，那么就只能让别人来替你做取舍。
很显然，在充分竞争环境下胜出的公司，几乎没有任何一个是通过大范围的搜索商业模式去寻找增长的。战术上的勤劳永远都没办法补救战略上的错误。这里面有非常多的经典商业案例：比如柯达、DEC、Sun Microsystems，都是非常典型的由于战略错误导致公司最终被淘汰的例子。
很遗憾，放弃决策权的事情在一个企业内可以说是每时每刻都在发生。那么我们能做的是什么呢？
至少有四件事情你可以做，注意，这是一个 Fail-over 的过程。
首先，想办法反馈这个情形，耐心解释给当初的决策者，请他来做取舍。这个本来应该是第一步也应该是唯一的一步。但是就像隔壁老王说的：“你永远也叫不醒装睡的人”。所以这个办法往往不管用。
其次，你自己做个取舍优先级，想办法通知到决策者。你可以用评分卡模型对项目的优先级做个判断。如果你自己不确定，也可以邀请资深的同学给项目打分，但是注意要排除掉与他利益密切相关的项目。通过这种方式，你应该能做出相对正确的取舍了。另外我想强调一下，通知是个非常有挑战的事情，我就见到过坚决不接受取舍的 CEO。但哪怕是这样的 CEO，他一般也会接受你给出的上线顺序。
接下来是，如果上面的方法还是不管用怎么办？这个时候你可以尝试自己拿下取舍权。你需要清晰表达你取舍背后的思考逻辑，并邀请相关的利益方参与辩论。如果他们的输入合理，那么你可以调整取舍。如果输入不合理，那么你可以选择拒绝他们的要求。
当然这么做有个前提条件，就是你与真正的决策者之间有足够信任，并且你也足够资深。如果不是的话，那你这么做可能会受到惩罚，尤其是在最终业务结果不理想的情况下。
最后，也是最常出现的情况，是你上述这些努力都失败了。这个时候，你可以通过技术手段来做延迟或者是隔离决策。这个办法对业务目标不明确的场景也同样适用。
比如你可以采用类似设计模式中的策略模式，把一个或多个业务尝试隔离在策略实现中。每次业务尝试对主流程不产生影响，每个尝试逻辑都封装在单个策略中。这样一来，业务尝试失败后，你可以迅速下线策略，而主流程的架构则可以保持整洁。这是一个最小化爆炸半径的方案。
如果目标太过超前怎么办？ 最后还想举一个比较极端的情形，那就是企业有一个非常明确的目标，并且与公司的战略意图相匹配。但对于企业现下的发展状况而言，目标太过超前，无法实现。
这种情况下，说明公司对一个领域的技术价值的判断是正确的，如果能够实现出来，必然会给企业带来巨大的生存优势。但这也意味着企业将会面临巨大的挑战。那么我们作为架构师该怎么办呢？
举个我自己的例子。2010 年我在微软美国参与了一个医疗领域的大数据智能产品的开发工作。技术方案的提出是基于这样一个想法：大量语义化的、实时的、来自不同部门的医疗图像和文本数据，在同一个地方实时聚合之后，将帮助科研人员和管理者发现之前被忽视的创新和提效机会。事实上，这个论断是成立的，而且被证实有成功案例，但当时的产品和技术架构却是失败的，后来被卖给了 GE，多年后又卖给了另外一家公司。
你可能想说，你是不是在劝我遇到这种情况应该放弃呢？其实我不是这个意思。如果你喜欢研究初创企业的成功故事，你会发现很多企业就是在这种战略意图和自身能力极不匹配的情形下一点一点成长起来的。
就像这个情形，其实当时公司的战略路径完全正确，那么哪怕烧钱慢一些，最初的团队也完全可以坚持到现在。如果真的坚持到现在，公司使用的关键技术，大数据、人工智能、实时处理等，都已经非常成熟。这十几年的行业积累，肯定也会带来非常大的竞争优势。
所以在这种情况下，你可能改变世界，也有可能一败涂地。我没办法给你一个坚持还是放弃（to be or not to be）的建议。如果你相信这家公司的使命，那就坚持下去。如果不相信，也可以毅然决然地离开。
在最后提到的医疗项目，它对我的架构决策还产生了另一个重要的影响，那就是让我意识到无论在什么时候，都要有勇气去做正确的架构决策。
为啥呢？我想你在做架构设计和技术选型时，肯定想不到“人命关天”这四个字。
但是就是上面这个医疗项目，让我意识到一个架构师必须要有良知，因为一个普通软件的决策可能是关系到一个人的生命。
美国的医疗行业比较喜欢拥抱新技术，但美国医疗行业又是各个科室完全独立，采购任何软件完全由医生说了算，所以一个大医院的 CIO 根本没什么话语权。
想想看，一个相当于我们国内三甲医院大小的地方，就能有近百套不同的系统。这么多完全封闭的系统其实把病人的档案信息都碎片化了，这样一来，就连发现病人药物反应这么简单的应用，都需要投入大量资金和人日才能保证上线。
从某种角度来说，这些部门到处都是局部最优的医疗软件选型决策。但从整体上来看，起到的却是适得其反的效果。这些部门医疗软件的错误选型其实等同于杀人，让本来技术实现相对容易的实时药物反应报警，成了一个几乎不可逾越的技术障碍。你可以查一下学术报道，2018 年美国统计直接因为药物反应的致死率占所有死亡病人的 0.34%，而在急救场景下更是高达 10%。
我们所在的领域可能没有美国医疗这么极端，但更常见的是情况就是我们作为架构师天天执着于灭火，头疼医头脚疼医脚，忘了去追逐公司战略层面的正确目标。
你肯定听说过这样的例子：一次黑客攻击，领导认为安全不够，要求团队三天内解决问题。团队发现唯一能在三天内实现的方案就是提升登录注册的身份验证安全等级。于是，团队三下五除二上线了复杂的风控和身份验证方案，安全问题虽然在三天内解决了，但是紧跟着新用户的注册成功率下降 5%。
假设你这么做了，那么虽然不是在杀人，但其实是在杀公司。你只是机械地执行任务，你的决策不仅没有把公司带到离正确目标更近的地方，反而在间接地浪费着你周边人的心力和生命。
甚至有更极端的，就是故意迎合领导，主动支持错误决策的架构师。我唯一的建议就是远离这种架构师以及任用他的人，因为他们是蘸着研发人员的人血馒头饱腹的人。
小结 我需要再重申一遍今天所讲的架构生存法则：架构师必须尽量保障整个架构活动有且仅有一个正确的目标，且这个目标必须和公司的战略意图相匹配。这是架构活动的起点，也是甄别架构方案的主要输入，所以架构师有义务影响和干预这个目标，以确保目标本身的正确性。
如果这个架构原则能起什么作用的话，我想就是在你最需要勇气的时候帮助你。
这个原则让你能够找到现有方案的弱点，看到这个目标和公司大目标不匹配的地方，然后让你有勇气站出来敢讲真话。讲真话的时候，不是你在反对你的上级，而是你在用一个架构原则来判断另外一个人的决策质量。
思考题 三个题目， 任选你最有共鸣的一个回答：
请你思考一下，你参与过的某个现在看起来不太合理的架构方案，你回想一下你当时有没有思考过那个方案是否“为企业创造生存优势”？如果你思考过了，是这个原则不适用于你的案例吗？如果你没有思考过，你可以试图用这个原则检验一下这个架构方案吗，你能得出和过去不一样的结论吗？如果你发现无法使用这个原则或者不影响你的结论，你可以跟大家分享一下为什么。 你做过的一个宏伟的为企业带来生存优势的技术项目吗？这个项目为什么会失败或成功了？这中间最核心的因素是什么？ 你有没有成功劝阻过一个目标错误的架构活动呢？结果是什么呢？
5 第二个生存法则:架构活动需要尊重和顺应人性。
自从学习计算机专业的那一天起，我们似乎就走入了一个简单直接的机器世界，一个完全靠逻辑和数字主宰的世界。于是我们总不自觉地认为凭借计算机就可以解决所有的问题。也许正是计算机的作用被过分夸大，使得我们在软件研发过程中走进了思维盲区，忽略了软件研发归根结底是一项人类活动这个事实。
毫无疑问，在架构设计中如果能尊重和顺应人性，也就是人的基本感受和合理需求，那么我们也会拥有另一个解决问题的视角，辩证思考我们正在从事的架构工作。
反过来，忽略人性可能给软件架构带来致命的失误。到现在我见过最昂贵的一个架构失误，大概超过几十亿美金，就是因为设计者对人性的忽略而造成的。
提起人性，马斯洛需求层次模型是绕不过去的理论。但由于信息的传播，导致我们现在理解的马斯洛理论是有偏差的、不完整的。
所以今天这节课，我会从源头来萃取马斯洛的理论，并结合一些简单的例子，看看我们在架构工作中应该如何理解人性。然后在之后的两节课，再结合真实案例，来看看人性是如何给予我们另一个解决架构问题的视角的。
如何理解马斯洛的理论？ 我们生活在一个信息唾手可得的时代。大多数人，包括我自己在内，经常会满足于在一个信息聚合类网站浅度寻找来获取知识。不幸的是，很多网站、书籍对信息源的抽象概括不够准确，导致我们往往被一个曲解过的理论和它的衍生品所蒙蔽。
马斯洛理论就是如此。在上世纪 40 年代，它被认为是心理学上的一个巨大突破，原因就在于这个模型很好地概括了人性。一般的网络文章会把马斯洛的理论解释为需求层次模型，认为高层次需求建立在低层次需求之上，低层次需求的满足是高层次需求出现的前提。
而如果我们从源头来萃取马斯洛理论，去追本溯源的话，会发现这种表述不完全正确，这就导致我们没法很好地利用这个理论来指导实际工作。
如果从源头来萃取马斯洛理论，可以得到什么样关于人性的理解呢？这里有两个重点，首先是动机有优先级。
不是需求有层次，而是动机有优先级 我先解释一下马斯洛这个研究的背景。马斯洛是在研究动机（Motivation）时提出需求层次的。所谓动机，就是人类的行为到底是由什么驱动，其实是对人类行为的当下原动力，区别于过去、未来或者是有可能起作用的动力。
“需求（need）”这个词，马斯洛在文章里也反复提到。这个词的翻译是准确的。
但是把“需求”和“层次”这两个词合在一起，就是一个非常糟糕的翻译。因为它并没有完全表达出马斯洛理论的实质。
马斯洛认为，人类的动机以抢占顺序依次排列（Being arranged in a hierarchy of prepotency）。马斯洛用“prepotency”这个词，特指人类的动机是依次独占人类的全部意识的。也就是说，一旦一个动机进入了这个状态，那么这个动机会召唤人的全部意识、行为去满足这个动机。我们把这个动机称作主导动机（Prepotent motivation）。
举个例子来解释说明一下，比如马斯洛动机层次的最底层，也就是生理需求动机。当一个人在生理上长期处于饥饿状态，那么这个以饱腹为目的的动机，就是他的主导动机。我特别强调一下，这个饥饿与没吃早饭那种饥饿不同，这是一种由自然灾难带来的长期的食物匮乏，是一种因为饥饿而导致死亡的、严重缺乏食物的生理状态。
在这种情形下，你整个人，包括你的视觉、听觉、嗅觉，你的思考、记忆、行为等等，都只有一个目的，那就是满足你填饱肚子这个生理需求。而这个生理动机是你所有感官、意识、行为的组织者和决策者。这时候其他的动机都不重要，你甚至都不能感受到其他动机的存在。
只有这个动机背后的需求被满足了，而且是长期被满足了，那么由更高层次需求所诱发的动机才会被解锁。因而当这个新动机开始作用的时候，它又像之前的生理动机一样，抢占你所有的意识和行为，并且压制更高层次的动机，直到它背后的需求得到完全满足。
动机抢占意识的整个过程，如下图所示：
如上图所示，假设一个人同时存在 5 个需求，需求 1 和需求 2 已经被满足了，那么这两个需求就不会再诱发动机。而需求 3、4 和 5 没有被满足，它们会同时诱发各自的动机。但由于需求 4 和 5 诱发的动机被需求 3 所压制，因而最终是需求 3 诱发的动机，在组织和驱动这个人整体的意识和行为。
到这里，我们来总结一下马斯洛理论的第一个重点。马斯洛理论的本意是：我们可能同时并行存在着多个需求，这些需求之间并不存在依赖或层次关系。如果这些需求得不到满足，那么它们各自会诱发动机。但动机有优先级，且具备抢占性质。所以任何时候，只有一个动机在主导着整个人的意识和行为。
到这里你就会明白，马斯洛强调的不是需求有层次，而是动机有优先级。从某种程度上来说，诱发这些动机的需求也被传递了同样的优先级。所以把马斯洛理论翻译为需求层次理论，虽然不能说完全错误，但却没有完整传递马斯洛理论的核心观点，甚至是部分曲解了马斯洛的理论。
动机跃迁 接下来是第二个重点，那就是动机是跃迁的。
其实我们学计算机的应该很容易理解马斯洛的理论，它跟硬件中断的机制几乎完全相同。计算机的各种外围设备在并行着工作。当它们需要抢占 CPU 的时候，就会发出中断请求。而人类的各种需求，就相当于并行运作的外设。需求诱发的动机，就相当于对系统的中断请求。而动机就像中断请求一样，各自有自己的优先级。高优先级的中断请求，则会抢占低优先级的中断请求。
想象一下，你身体和大脑中的需求是客观存在的，当这些需求得不到满足的时候，我们体内的相关传感器就会发出中断请求，也就是动机。但人是一个完整的机体，任何时候只能由一个动机来主导。那么在这种工作环境下，自然会对不同的动机有个优先级排序。
所以马斯洛认为，人的行为在单一时刻不是面向多目标做优化，而是面向单一目标做优化。一旦某个动机抢占了人的意识，那么它就抢占了这个人的全部意识，此时整个生命的所有思考、行为等，都在为满足这个动机而工作。那些帮不上忙的器官和能力，就被放置在后台运行了。可以说，在马斯洛模型下，主导我们人类整体意识和行为的工作机制是单线程的。
到这里，我们就可以把马斯洛理论的实质总结出来了：一般来说，人有且只有一个主导动机。这个动机由人的内在需求所驱动，并独占且主导这个人当前的一切意识和行为。直到这个动机背后的需求被完全满足之后，更高层次的动机才可能进入主导位置。
此外，马斯洛所讲的动机不仅是有优先级的，而且是跃迁的，对人的行为的组织和驱动而言是独占的。不幸的是，这个理论中更为核心的理念——动机独占和跃迁，都在信息传播中被遗失了。反倒是对这个理论表达不怎么准确，但是非常易于传播的需求层次模型，变得家喻户晓。
这就是你从源头深度探索一个理论时，能得到的别人得不到的东西。要知道，马斯洛理论并不是特例。我们会发现大量被传播的内容，往往是被极度简化过的，或者是以传播为目的而修剪过的。我们要认清楚一点，网站的目的是增长和盈利，不是最大化你的知识获取。因而在这个信息失控的时代，我们有必要重新回到信息源头，来获取真实的第一手数据和理论。
不信的话，你可以去网上搜索一下。每个架构师都引用的朗朗上口的康威定律，看看有几个翻译是和康威自己的表达是一致的？
动机抢占 接下来我们解读一下马斯洛的需求分类，之后的课程会用到这部分内容，所以精确地理解很重要。我这里还是把重点放在被网络媒体所歪曲解释的部分。
在生理需求之下是心理安全感。在最底层的生理需求得到满足之后，心理安全感这一需求诱发的动机就会成为主导人意识的主要动机。
很多信息聚合网站没有区分安全和安全感。我们这里说的安全感是心理上的诉求，不等于人身安全。安全是生理上的，仍属于刚才提到的生理需求的一部分。
心理安全感，在广义上指的是人们试图寻找的生活中的安全和稳定性，表现为更倾向于熟悉的、常规的、有结构的、可控的、已知的、可预测的和安全的事物。
马斯洛认为心理安全感的获得主要来自于一个人的成长过程。一个人从出生起，父母会为孩子就会提供熟悉、常规和有结构的日常生活。这种安全感也在随后的成长中逐渐扩展到了相对可控的、已知的、可预测的，以及相对安全的生活和工作环境中。
一旦我们处在一个特殊处境下，比如面临战争、瘟疫等灾难，哪怕我们没有受到直接的威胁，那安全感也会丧失。在这个时候，我们生命体所有的意识和行为都在为寻找安全感这个动机而工作。你可以回想一下新冠肺炎刚刚宣布时候人们的行为，全球大小商场里的口罩和手纸都被一抢而光。
接下来是自尊和被尊重的需求。自尊在马斯洛这里强调的是“有底气的自尊”（Firmly based self-esteem），也就是说，这种自尊来源于真实的能力、成就，以及其他人发自内心的尊重。
这是个非常有意思的定义。我们常常把有底气的自尊和较高的社会或企业地位划等号，其实不然。有些财务自由且身居高位的人也缺乏这种有底气的自尊。而在这些人的周围工作，是一件非常麻烦的事情，因为他们会把意见的不一致简单理解为对他本人的不尊重。这种工作环境对架构师来说简直就是噩梦。我建议你尽量避免让自己陷入到这样的环境中。
换个角度来说，对于一个员工而言，如果一家企业能满足他的自尊，让他感觉到自己是被需求的、被认可的，也会给他带来自信、成就感和工作的高度投入。
讲到这里，你有没有发现马斯洛提出的这些需求有什么共同特征？
是的，这些需求都是内在的，是源自一个人自身的，而不是由周围人强加给他，或是由环境、文化的压力而产生的。这也就意味着由这些需求而诱发的动机是内在的，有强大的驱动力。
站在马斯洛的理论上来看，许多企业经常挂在口上的“拥抱变化”的价值观，其实是反人性的。这个价值观要求员工去接受一个他们本来认为是不连续的、不安全的、不一致的，甚至有可能是不公平的处境。有些企业认为文化宣讲频繁了，员工就会接受了，但至少马斯洛不是这么认为的。马斯洛认为除非这种内在的需求被长期满足了，才不再成为主导动机。靠外在的宣传，是没有用的。
有底气的自尊也一样，这是发自内心的需求，不是说大家认为你应该有自尊你就有自尊了。而是你内心认为自己具备这种自尊，那你才会真的具备。
最后是自我实现，马斯洛讲发自内心的需求指的是自己真正想要的，而不是别人眼里的成功。你可能觉得某个大人物已经完成自我实现了，也可能觉得某个小人物都不具备自我实现的条件，更别说完成了。但事实可能刚好和你的猜测相反。自我实现不是来自于他人的某种排序，而是一个人发自内心的诉求。
当然马斯洛后来还添加了其他的需求。 比如说审美（Aesthetic）和超越（Transcendence）。 不过这些需求在软件行业中不怎么出现，我们就暂时不讲了。
马动机跃迁理论的核心描述和具体应用 总结来说，马斯洛认为人的动机是内在的。这些动机来自人的不同心理需求，从最基本的生理上的需求，到心理安全感，再到群体认同感，然后是内在有底气的自尊，最后到最大化的自我实现。
如果这些需求没有被满足，它们就会刺激出人的动机，去满足这些需求。但这些动机并非同时生效，因为任何时候都只有一个主导动机在支配着我们整个人的感官、意识和行为。这些动机依次出现的顺序，如图所示：
当生理需求得不到满足，那么源于生理需求的动机 1 就会处于主导地位，并且会屏蔽其他动机。只有生理需求得到满足了，那么处于生理需求之下的、未满足的安全感，才能诱发以获取心理安全感为目标的动机，然后成为主导动机。以此类推。
我们这是一个架构课，但今天花了这么长时间来研究这个理论，就是因为它对软件研发和架构活动具有实际的指导作用。软件是由人类所构造的一个虚拟的存在，而这个构造过程，是靠一组研发人员共同协作完成的。既然马斯洛的模型适用于一切人类活动，那么这个模型当然也可适用于与软件构造相关的架构活动。
而你作为一个架构师，以马斯洛的理论来指导架构方案的设计和组织架构活动，会让你的设计尊重和顺应人性，避免因忽略人性而带来巨大的失误，甚至可以帮助你找到一个突破性的解决问题的视角。
为了帮助你更深刻地理解，我来给你分享个经典案例——儿童的 MRI 扫描问题的解决，来看看我们可以怎样通过顺应人性来解决一个具体的问题。
MRI 的扫描过程非常慢，通常会持续半个小时，而且还要求患者必须保持一动不动的姿势。对于儿童来说，这肯定很难做到，所以给儿童做扫描的前提就是先做全身麻醉，这就让本来一个相对安全的诊断设备变得非常危险。
后来 GE 的设计师 Doug Dietz 做了一个非常巧妙的设计，他把 MRI 机器改装成海盗船的模样，并告诉孩子说你要进海盗的船了，必须一动不动保持 30 分钟，直到我们救你出来。如果动弹，就会被海盗抓走。
结果呢？孩子们非常配合。就这样，在对 MRI 成像机制和扫描流程没有做任何技术更改的情况下，全麻率从之前的 80%降低到了 10%。
这个案例在当时非常轰动，甚至引发了一次文化浪潮。从本质上来说，这个案例就考虑了患者的人性，体现了设计思维。
很显然，把 MRI 机器改装成海盗船模样这个解决方案与硬件设计毫无关系，甚至和技术也不沾边，但它却完美地解决了 MRI 设备所面临的问题。
这种从共情出发，深度理解和尊重用户的做法，就是设计思维的精髓所在。之所以能提出这个方案，主要在于我们拥有了另一种看待问题的视角：
到底是被动地迭代方案，执着于填补设计的漏洞； 还是从共情用户的角度出发，脱离现有技术方案的束缚。同时忘记现有的技术方案的强大，把关注点放在深度理解用户、解决用户的痛点上，进而拓展技术设计空间，找到更完美的技术路径。 答案不言自明。
到这里，在架构活动中考虑和顺应人性的必要性和重要性，相信你已经很清楚了。那么接下来一个更为重要的问题就是：在软件架构活动中该如何顺应和考虑人性呢？接下来两节课，我们会着重来讨论。
小结 把马斯洛的理论翻译成“需求层次理论”，虽然没有错，但却没有完整传递马斯洛的理论，甚至是部分曲解了马斯洛的理论。不幸的是，这个理论中间比较核心的理念动机独占和跃迁，都在信息的传播中被遗失了。倒是对这个理论表达不怎么准确，但却非常易于传播的需求层次模型，反而变得广为人知。这就是你从源头去深度探索一个理论时，能得到别人得不到的东西。
很多原理如果不是从源头萃取而来，而是通过信息类网站浅度浏览获取的，那么似乎你也很难把这个原理运用好。没有费力获取，那么你也很难深度理解。我不知道这里面是否有普遍适用的认知科学的原理在，不过至少对于我自己来说，通过阅读原著作来获取知识，是运用好一个原理的大前提。
因而我也可以说，在这个信息过载的时代，超越他人的一个行之有效的办法，就是从源头来获取知识，从而掌握他人所看不到的规律，获得超出常人的理解，帮助指导架构工作，甚至是帮助我们实现超越性的突破。
思考题 三个思考题，任选一个：
在马斯洛的理论中，自我实现是个内在的目标，是由个人决定的，但这个内在目标会影响整个社会的产出。假设社会存在某种有效的手段可以干预这个目标的话，你认为社会应该干预吗？举个例子，假设达芬奇不花那么多时间作画，他有可能成为一个更伟大的科学家。或者他不花那么多时间去研究科学，他有可能成为一个更伟大的艺术家。如果社会能干预达芬奇的选择，你认为社会应该干预吗？你介意被他人干预吗？
能否举一个在你身边发生的、违反了马斯洛理论的例子？它为什么会发生呢？
大胆假设一下，在后人工智能时代，如果我们人类（被）进化成了机器与人的混合体，其中机器也有它的需求（比如没电了要充电），那么你能想象一下，这种混合体会有什么样的需求呢？我们该怎么设置这些需求的优先级呢？
6 利用马斯洛理论去指导架构设计
上节课我们学习了马斯洛关于人性的理论，那么这节课我们就利用这个理论来看看我们在架构活动中应该注意些什么。
架构设计必须符合人性，而在架构活动中，与“人”相关的主要就是研发人员和目标用户。那么今天这节课我们就先从研发人员讲起。
想想看，如果架构设计忽略或剥夺了研发人员的人性，会怎样呢？再一个，如果架构活动中尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？这正是我们接下来要讨论的内容。
研发人员为什么需要安全感？ 环顾四周，你会发现研发人员对安全感的需求很是强烈。内卷、35 岁危机、996，各种流行关键词似乎都指向了安全感的缺失。为什么会这样呢？
我们刚刚学习的马斯洛理论这时候就可以回答了：因为我们都吃得太饱穿得太暖了！我们的生理需求得到了充分的满足！这么一来，心理安全感的需求就赤裸裸地暴露在那里，等待着被满足。
这个答案是半开玩笑的。不过一般情况下，大多数研发人员的生理需求的确不在架构师的考虑范围之内。顺便说一句，有极少数公司会利用人的生理需求来获益，比较阴暗。我唯一的建议就是，远离做这种尝试的公司，在这个时代你有更好的选择。
好了，言归正传。研发人员的生理需求是能够在软件架构考虑范围之外得到充分满足的，那么根据马斯洛的理论，如果一个研发团队，本来是具备心理安全感的，但是突然间却被剥夺了，这会导致什么问题呢？
没有人性的技术架构，就没有生存空间 接下来，我们就通过一个案例来演示一下，研发人员的心理安全感被破坏之后会造成什么损失。
案例背景 我曾受邀给一个在行业内处于垄断地位的大企业做架构规划的外部评审。这家企业的技术在自己所处领域内领先全球，加上资金雄厚，因而他们开始在海外做布局，投资了一家同领域的初创公司。
本来小公司有自己的研发人员，且初步建设了自己的技术体系，基本可以支持本国的业务。但在大企业看来，这家小公司的技术落后自己几年，而且研发人员的能力也有限。
在这个背景下，大企业的国际化团队提出了一个架构设计，如下图所示：
这张图略去了很多细节，不过完全保留了这个架构设计的本质。
投资前，小公司有自己的完整技术栈，如图中左边部分所示。但投资之后，大企业期望小公司能把他们的技术迁移到一个由自己开发的技术平台上去，这样大企业的部分技术就可以通过平台输出给这家小公司了。
这个技术平台主要包含两部分：
一部分是全球业务网络和支持这个业务网络运作的全球技术平台，也就是图中的最底层部分。 另一部分是一个通用的本地技术平台，由大企业开发，全球通用。这是图中右侧位于全球网络上面的部分。 如果将小公司的技术迁移到本地技术平台之后，他们的研发团队就可以集中关注怎么在本地技术平台上开发自己国家的解决方案。这样一来，之前做本地平台功能的研发人员可以减少很多。而且由于对本地解决方案开发者的技能要求相对更低，这样的研发人员很容易找到，那么用人成本也低。
此外，这样做还有几个附加的好处。首先，大企业开发的本地技术平台基于全球最先进、业务体量最大的中国市场的技术建设，所以不但技术先进，而且附带了很多海外同行们还没有开发出来的业务能力。
其次，本地技术平台和大企业的全球业务网络是打通的，所以小公司一旦接入本地技术平台，那跟它就和全球业务网络一下子就完全打通了。额外的生意滚滚而来，成本又少了很多，何乐而不为呢？
但结果呢？
一年后，大企业投入几千人终于建成了这个庞大的系统，也大幅扩招了在海外的投资版图，但能接受这个方案的小公司却寥寥无几。第二年， 大企业又做了一次全面的技术升级，放宽合作条件，增加对部分小公司的投资占比，但技术方案的推进和被投资业务的增长都不尽如人意。又过了一年，这个方案最终被取消了。
四年后，行业蓬勃发展，但大企业投资的小公司完全没有像期望的那样复制了大企业在国内的成功。不算小公司侧的研发损失，仅大企业损失的研发资源就达到了 1.5 万到 2 万人年，再加上直接投资，损失高达几十亿美金。这还不算浪费掉的机会成本。
忽略研发人性的架构设计，会怎样呢？ 为什么会造成如此惨重的结果呢？
因为这个架构设计完全忽略了人性。具体来说，就是这个架构方案完全忽视了小公司里研发团队的心理安全感需求。
想想看，如果你在小公司任职，你研发了第一代技术，让公司被一个资金雄厚的国际化大企业看中。但随之而来的就是把你辛苦开发的代码全部下线。紧接着，你的日常工作就变成了跟第三方供应商做系统对接，与核心技术失去了接触。这个方案一旦采用， 那么一夜之间，从 CTO 到一线研发，每个技术人的安全感都被一扫而光。这个时候你还会安心地留在公司吗？
或许你会说，如果小公司被大企业收购，肯定会签约保留老员工，用股权机制拴住他们。这样一来，他们肯定可以完成技术迁移，不是吗？
正如我们在上节课所讲的，依照马斯洛模型，心理安全感是一个人的内在需求，只有这个内在的需求被完全满足了，它所诱发的动机才会消失，否则这种动机将持续被诱发。所以, 虽然外部激励的确会诱导员工的行为，但却不能从本质上满足已经被剥夺的心理安全感。在这个软件开发人员相对能够保障衣食无忧的年代，没有比获取心理安全感更高的动机了。
让我们再来回忆一下上节课讲的马斯洛的动机跃迁模型：
一个动机一旦进入了主导状态，那么这个动机就会召唤一个人的全部能力去满足这个动机。在这种情形之下，你整个人，包括你的视觉、听觉、嗅觉，你的思考、记忆、行为等等，都只有一个目的，那就是满足这个动机。
现在你应该知道了，获取心理安全感必然会成为小公司研发人员的主导动机。假设你在小公司工作，在拿到技术方案后，你的第一优先级会是去完成技术迁移吗？哪怕有股权和激励诱导你这么做，你会全身心地投入其中，保障迁移迅速完成吗？ 至少马斯洛不这么认为。
如果把这些被投资的海外小公司的研发团队比作一个人的话，那么我们在“案例背景”部分看到的那张架构设计图，无疑是断了他的生路。在这种新架构之下，研发团队根本没法创造出任何可以让自己长期被企业依赖，也就是保障自己生存的长期价值。我们甚至可以继续推演一下，当一个小公司的非研发人员发现自己公司被收购之后，所有的核心研发人员都开始陆续离职，那么他们自己的心理安全感还是硬杠杠的吗？
虽然从技术角度来看，这是个非常有价值的架构方案，但这却是一个完全没有人性的架构。一个完全忽略了研发视角的设计，不但没有从共情出发，甚至是践踏了人性。那么这个架构在海外屡战屡败的事实也就不证自明了。
因而这个例子告诉我们，你作为一个架构师，设计的方案必须要尊重研发同学的人性，一个完全忽略人性的架构是没有生存空间的。
再回到这家国内的垄断大企业，你可能会好奇了，为什么这种没有人性架构竟然能够横空出世？为什么这种方案在屡战屡败的情况下竟然还被整整实施了两年多呢？
为什么会有人设计没有人性的架构？ 在邀请我去做架构评审的时候，这家大企业的研发已经有五千多人了。而拿到那次架构评审会议上的项目，也就不到十个。那么每个项目动辄就是数百甚至上千人参与。
这个国际化技术平台的项目，也有好几百人研发人员的参与。虽然是项目评审，但是拿到会上的时候，项目已经启动了。不只是架构师，各方参与人员早已排列整齐，甚至部分研发工作已经启动了。
在架构评审会上，我曾经极力劝阻这个项目的架构师和相关的研发主管，期望他们能放弃这个设计。但最终没能说服他们。
为什么要劝他们放弃呢？因为马斯洛的理论也在这个时候起作用了！
所有已经在这个项目里的人，他们的升职、团队招聘、晋升、年终奖、股票都已经和这个项目牢牢绑定。对于他们而言，任何动摇这个项目稳定性或者是削弱这个项目价值的言论，必然会伤害到他们的自身利益和心理安全感。
同样，在这个时候，他们获取心理安全感的动机也会主导他们所有的感官、意识和行为。所以项目里的人会拼命维护他们的立场，就像小公司里的研发人员一样，他们都在为获取自己的心理安全感投入全身心的努力！
结果就是项目评审会并没有对项目的状态产生什么本质影响。项目启动之后，在国外的接连挫败也没能让参与者们从根本上改变这个架构，因为他们就是这个国际技术平台下的一个衍生物种，让他们去破坏自己赖以生存的空间，完全不可能。更现实的是，越到项目后期，大家的利益和平台绑定得就越深，越是难以阻止。
也就是说，在那次评审会上，这个项目因为前期投入太大，参与的人太多，项目已经不是箭在弦上、不得不发的状态，而是离弦之箭，驷马难追。单靠一个项目评审会，很难把这个项目拉回来。
你看看，马斯洛的理论是多么美妙，又是多么对称的一个理论啊！这个理论不但解释了受迫害一方的行为，而且也完美解释了施虐方的行为。这是个多么讽刺的场景啊！
现在让我们再次强调一下今天讲的生存法则：架构活动需要尊重和顺应人性。架构师必须洞察研发人员的人性，在方案设计和架构活动组织中充分考虑研发的人性，才能保障方案的正确性，以及方案的高效实施。
如果说我们还能从这个案例中能得到什么额外认知的话，那就是：越是大型的架构方案，就越要在早期去讨论它的方案可行性，而且要尽量试图要从批判和否定的眼光去看待它。这种讨论越早越好，涉及的利益方也越少越好，而不是放在详细规划已经完成之后，甚至是项目已经了启动一小半了才做评审。
那么你可能会问我，但是为啥要这么长的时间大家才意识到这个方案是不可行的呢？难道不能上线半年内就终止，减少损失吗？
从某种层面上讲，当一个架构方案有数千人参与，那么这个方案随着时间已经逐渐演变成了一个运动。一个运动，由这个运动自身而产生的惯性，已经不受一两个决策者控制，大量的参与者已经为这个运动注入了持续的生命力。
这个惯性是非常令人恐惧的。而惯性的根源就在于马斯洛的人性理论中的生理需求和心理安全感，这是一种参与者哪怕有认知都很难抗拒的心理。在参与者人数足够大的时候，这种内在的驱动里就很难从外部被影响。这也是为什么我认为人类历史上有一个又一个从悲惨的开局一直持续演到悲惨的结尾的长剧。
当然，马斯洛理论的应用还不止这些。如果架构活动尊重和顺应了人性，那么又能给我们架构师一个怎样不同的解决问题的视野呢？
如何设计微服务的粒度？ 微服务有个永恒的话题，就是微服务的粒度到底该怎么定。一个人应该分到几个微服务，还是几个人一起维护一个微服务呢？
对于这个问题，我想你肯定听到过各式各样的答案。有讲 3 个人维护一个的，也有说应该两个人维护一个的，还有说一个人维护一个的。那么现在让我们来假设一下，如果是马斯洛马老师，他会怎么设计微服务的粒度呢？
“根据您的理论，同时考虑到现实情况，微服务应该不能只满足研发人员的生理需求，对吧？” 我断言道。
“是的，所以安全感对一个研发人员就很重要了。那么我们应该怎么划分微服务，才能让每个研发拥有最大的安全感呢？”马老师问我。
我想了想，回答道：“每人至少一个，而且还得是核心服务”。
“为什么呢？”马老师继续问。
“这样每个研发都不用担心他的工作安全，因为没有人能够轻易取代他。”我老实回答。
“还不止这些好处。如果这么划分，也会给予每个研发以自尊，因为他们对自己的微服务拥有完全决策的自由，这相当于给了他们自信和勇气。此外，他们能从服务他人的过程中感觉到自己是被需要的，这就又给了他们成就感。自尊和成就感，这两者都是有底气的自尊的源泉。更进一步讲，如果说他们的微服务能帮助一家公司更好地服务社会，那么他们甚至能在自己的微服务中找到自我实现的价值！”
“想不到马老师对微服务这么有研究啊！” 我的敬仰如滔滔江水。
“哪里哪里，我只是看透人性罢了。”马老师谦虚地回答我。
当然，划分微服务的粒度不仅需要考虑研发的人性，还要考虑服务本身的原子性、团队大小、团队人员的稳定性、服务的高可靠性要求等等。不过单从人性角度思考，如果你独立负责一个核心微服务的话，那么你的安全感和自尊都是最大化的。
举个现实中的案例，我们来验证一下。在阿里时，我们部门的人均服务数是 1.5 个左右，而淘宝是不到 0.3 个。我们团队的人均代码产出是淘宝同学的三倍，代码质量指标千行代码的缺陷率是淘宝的一半，人均日发布次数是淘宝的 7 倍多，发布成功率和淘宝持平。
当然，两个业务的体量和复杂度完全不能相提并论，而且稳定性要求也不一样。所以直接推导出人均服务数越多越好的结论也不合理。
这是从研发 ROI 的角度来思考微服务粒度的问题，我们还可以从微服务本身的设计出发来思考。微服务的核心价值在于以下几点：
粒度小，单个服务可以紧贴业务快速迭代； 去中心化组织和部署结构，减少不必要的协同； 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的一致性； 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务； 服务本身的独立部署能力使得容错和容量弹性最大化； 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。 其中第 1、2、3 项是人越少越高效的，最高效的状态就是一个人。想想看，你自己对业务有深度理解，能够和业务同频率迭代。你什么时候想改代码就改代码，不需要协同，改好了就上线。你自己一个人改自己的商业逻辑和数据模型，根本不需要担心其他人祸害。
在这种状态下，你的速度绝对是最快的。而且就你个人的能力为极限，也是协同越少，你能产出代码的质量越高。所以从这个角度来说，让多名研发维护一个微服务的配置是不合理的。
唯一能够支持多名研发维护同一个服务的理由，就是服务本身对公司的价值太大，它上面承载的业务量，对稳定性的要求，对服务连续性的要求，大到可以忽略研发资源的成本的时候；或者是从性能角度来看，服务无法拆分，它得复杂度大到可以支持多个研发维护的时候。在这种情况下，多个研发维护同一个服务的布局才是合理的。
这种布局在年交易额超过万亿美金的淘宝平台，其实是说得过去的，尤其在中国这种互联网研发人员供给相对充沛的环境之下。
但是，我们大多数人所在的公司并不是像阿里腾讯这样处于垄断地位的互联网公司，甚至哪怕你在阿里和腾讯，你也很可能不在公司最主流的现金流业务中，那么多个人维护一个服务的配置，我认为就不合理。
当然，有些人认为一个服务上只有一名研发会有稳定性风险，我觉得这个理由不成立。微服务的隔离性和有分布式架构带来的稳定性，是能抗住个别同学离职的压力的。而且服务粒度越小，这种承受能力越大。
我曾经经历过一家公司一个月内有 15%的研发人员离职的情况，而且这家公司的服务数和研发人员数之比远大于一。但即使是在这种情况下，最终也没有发生稳定性大崩盘的情况。所以以稳定性为由来扩充研发人员，我不认为这是一种好的策略。事实上，比这好的提升稳定性的办法有的是。
其实我一直认为做微服务就像农民耕耘自己的土地一样。无论是古罗马，还是中国封建社会的历朝历代，再或是美国，开国之初都有过开荒屯田的政策，每个农民都可以分到一块属于自己的土地，国家也因此得到了飞速的发展。
对于我们今天这些进城的互联网民工来说，微服务就是咱们的土地。有了自己的地，我们肯定会拼命劳作，想办法从土地里找到致富的希望，不是吗？ 但是如果大家都在一个大锅盛饭吃，而且总是僧多粥少，曾经挨过饿的互联网民工们能不担心吗？
小结 通过今天讲的这两个案例，我想你不仅知道该如何理解马斯洛的人性理论，而且还知道该如何应用了。正如我反复强调的那样，或许你学完这些法则会觉得内容太过简单，但就是这些最基本的原理，其实对结果的影响和对效率的撬动才越大。你用对了这样基本的理论，就可以带来成倍效果提升；而用错了，或者忽略了，则会带来灾难性的损失。
所以越是一个看似简单的道理，其实越需要你运用这个道理去深度思考自己身边发生的事情，从而看清事物的本质。听说过原理不等于懂，懂得原理而不会用，就等于入宝山而空手归。而原理用得多了，事情的本质也会看得更清楚。
那么下节课，我们将从用户的角度来继续探讨人性。
思考题 三个作业，任选一道：
在第一个案例中，我还听到过这样一种说法：大企业的 CEO 肯定会支持这个项目，那么我们派进去的人进场完成迁移就好了。真的可以这样吗？你能否从 CEO 的视角来看，这种说法违反了马斯洛理论的什么动机和需求层次？如果你是 CEO，你会从内心里接受这个架构方案吗？为什么？
从安全感的角度来看，许多企业经常把“拥抱变化”的价值观挂在口上，但这其实是反人性的。拥抱变化，也就是在变相要求员工去接受一个他们不连续的、不安全的、不一致的，甚至有可能是不公平的处境。你是怎么看待这个问题的呢？这个观点正确的部分在哪里？错误的地方又在哪里呢？在什么情况下，拥抱变化是能够成为员工发自内心所认同的价值观呢？
影响微服务粒度的决策还有不少其他因素，你如果有其他的理由或者完全不同的角度来得出你的结论，也欢迎你把你的想法分享给大家。
7 如何考虑和顺应研发人员的人性
上节课我们学习了怎么利用马斯洛理论去指导架构设计，尤其是该如何考虑和顺应研发人员的人性。
我们都知道，软件这个虚拟的存在最终是要服务于用户的，所以在软件设计的过程中也要考虑用户的人性。也就是说，一个架构师要站在用户的角度去思考架构的规划和设计。
你可能要问了，用户需求往往是产品经理要考虑的事情，我作为一个架构师去考虑用户的人性有什么用呢？
为什么不呢？
你可能是一家手机厂商中极具极客精神的工程师，你研究电池、显示屏、操作系统、应用商店、摄像头，但你离自己的用户太远了。因为用户真正做购买决策时，一个女性可能更看重它的美颜效果，一个年轻男性可能更在乎手游的体验。试问，有哪个买手机的人是在买手机零部件呢？
事实上，把注意力放在用户身上，已经有无数案例证明是可以带来重大商业和技术突破的。最好的例子，可能就是乔布斯在 PC、iTunes、Apple Store 这一系列产品设计和用户体验上的突破。另外，我们在第五节课最后讲解的儿童 MRI 的案例也是这样。
仔细想想，这些案例中存在什么共性呢？我们就通过电商巨头淘宝和拼多多对用户心智洞察的案例，来开始今天的学习。
从人性看拼多多是怎么赶超阿里的 拼多多的出现，可以说是颠覆了互联网人的认知。
2015 年前后，阿里巴巴占据了整个互联网电商几乎全部的流量优势。在万能的淘宝，有 20 亿商品可以覆盖人们生活方方面面的需求；在品质生活的天猫，提供了世界几乎所有的品牌。可以说，阿里把电商全品类渗透率不断提升，也把电商多快好省的心智几乎做到了极致。然而就是在这种形势下，拼多多一步步完成了一个不可能的颠覆。
拼多多究竟是怎么做到这一点的呢？
这里面有很多因素，比如说线上支付、微信流量。但其中至少有一个关键因素和马斯洛的人性理论有关：拼多多对用户人性的理解，远远超越了其他同时期的电商玩家。
拼多多创始人黄峥在《财经》杂志的采访中说了这个洞察：“我们的核心不是便宜，而是满足用户占便宜的感觉”。顺便一提，这篇采访是我迄今为止看到对电商理解最为深刻的一篇，没有之一。
你可能要问了，阿里不是已经把“省钱”的心智做到极致了吗？而且，“占便宜”不就是省钱吗？其实不然，“省钱”和“占便宜”是两种截然不同的心智。
我先举个标准的占便宜的例子，你感受一下：
一款 Sony ¥499 的耳机，我看很久了。一天，搜索结果中突然冒出一个 ¥4.99 的价格，还是正品。
你的感觉是什么？你的瞳孔是不是放大了？你的心跳是不是加速了？你是不是像疯了一样，试图以不可能的速度去完成下一步操作？点击支付确认的时候，你的手是不是都在颤抖？
我再重复一下第四节课讲的马斯洛关于主导动机的描述：
一旦一个动机进入了这个状态，那么这个动机会召唤一个人的全部能力去满足这个动机。这时候这个动机就是主导动机。
那么在拼多多这个例子中，占便宜的心智就会诱发具备抢占性的主导动机。
但省钱是不会的，省钱是个非常理性的心智。你在单价、物流、服务、质量、功能等诸多维度上进行比较，这是个理智的决策。如果这时候邻居王太太叫你打麻将，出于群体认同的动机，你还可以放下这个省钱动作。但我相信，你绝对不会对那款 ¥4.99 的耳机不管不顾的。
我们也可以把占便宜理解为一种欲望，它不完全等同于人性中贪婪的欲望，而是更接近人性中获取不对称生存优势的欲望。
什么是不对称生存优势呢？我们用动物世界来举个例子。假设在一块狮群占据的领地上，除了一般狮群领地上都具备的水源外，还有一个盐滩。这个盐滩上呢，恰好有羚牛所需要的盐，所以有些羚牛就会去盐滩上舔食。在舔食的时候，羚牛放松警惕的时间会更长一些，也就更容易被狮群捕获。
因此，相比其他领地上的狮群，这块领地上的狮群就有了一个不对称的生存优势。这个优势乍看上去一点儿都不明显，但是随着时间积累，就会变成这个狮群繁衍壮大的一个本质因素。
在我看来，这种获取不对称生存优势的欲望，应该是动物的一个根本欲望。因为你需要更有效地获取自己生存所必需的资源，那么这个欲望，就会诱发你的动机，并占据主导地位。
从这个视角来看，人性中占便宜的需求，在马斯洛的需求层次中应该更接近生理需求层次。也就是说，一旦这个需求被触发，它将抢占其他一切动机，成为主导。而你的所有意识、行为都是在满足这个主导动机。
所以这时候，你已经不是单纯地在购物了，你是在为自己获取不对称的生存优势，你是在薅互联网投机者的羊毛为自己的未来打下更坚实的基础。
我认为这就是拼多多在人性上的一个本质洞察，它洞察到了目标人群及其心智。
从用户心智到增长飞轮 那么你作为一个架构师，理解这个人性有什么意义呢？
从我的观察来看，很多创业公司，从初创到倒闭，都没搞清楚自己的目标人群和心智。如果一个公司，能锁定目标人群及其心智，那么对于软件架构师而言，你就有了一个确切的技术问题和研究方向。这可能是一个架构师最梦寐以求的工作处境。
我们先来看下面这张图：
图中的每条连线上都有一个角标，“+”号表示一个前项因素的增长，箭头指向后项。如果前项的增长会带来后项增长，那么箭头上也用“+”号表示。你会看到整张图上都只有“+”号，这就代表整个平台机制形成了正循环。也就是说，随着时间的推移，价值在不断放大。这是系统论的正反馈循环，也就是大家经常提到的飞轮效应。
循环的具体流程如下：
通过放大占便宜的心智，拼多多省下了巨大的营销成本，获得了大量的免费流量。 这些免费流量加入到已有的具备相同心智的用户中。 这些用户的需求变成了订单。 大量的订单变成了供给端的集中采购优势。 这个采购优势也吸引了大量能提供更高性价比的供应商。 这些供应商和现有供应商在平台不断提升性价比的平台机制之下，为用户提供了大量极致性价比的商品。 这些商品能够更好地满足用户占便宜的心智，所以也会持续帮助平台获取更多的免费流量。 图里的绿色部分有点复杂，我来着重解释一下。这是平台机制模块，有两个输入和一个输出。其中一个输入是集中采购，也就是拼多多在逐渐培养放大的 C2M 模式，是有规模效应的新商家的代表。另一个是普通的平台商家，是平台老商家的代表。而平台机制模块决定什么样的商家将被激励和选择性放大，最终会输出什么样的商品。也就是说，平台机制模块的设计决定了整个平台是否能够维持增长。
一般来说，一个平台现有的商户和新加入的商户形成竞争，两者是互相抑制的关系，而不是互相促进增长的关系。
但是拼多多的平台心智非常清晰，所以他们的平台机制模块能够以放大用户占便宜的动机作为商家被激励的唯一目标。有时候具有规模效应的 C2M 商家会被激励，有时候老商家会被激励，一切以用户的行为为准绳。在这种机制下，那么更多的新老商家只会带来更多极致性价比的商品。所以在两个输入都为“+”的情况下，最终输出的效果只会是“+”。
我认为这个就是拼多多的飞轮效应。简单来说就是：一个平台的定位，也就是满足用户占便宜的心智，反向选择了用户人群。然后在这些人群的共性需求中建设了自己的供应链，从而形成正反馈闭环。这就是为什么拼多多的日活跃人数 DAU 和订单量能够同时飞速增长的原因。
看到这里你可能又要问了。我把占便宜的心智换成“品质生活”，那不就是天猫吗？我把占便宜的心智换成“万能”，那不就是淘宝吗？再说了，聚划算不就是能满足用户占便宜的心智吗？
是啊，没错，可以满足！但是把这三块业务放在同一个平台机制下，也就是图中的白色部分，我们该如何选择呢？
淘宝无所不能的心智带来了大量的猎奇和浏览者，但是平台却是靠天猫的品牌，获取了大量利润、金融收入和资本市场的认可。聚划算和拼多多的心智相同，也自带流量，但是一个以占便宜心智为主导的用户，大多是不愿意花更多的钱在品牌溢价上的。所以，平台到底是要刺激哪一种心智呢？
事实上，这几种心智是互不兼容的。聚划算要追逐极致性价比的商户，那么产品的稀缺性就会降低，就不会帮助到淘宝。而且所谓的极致性价比，在某些质量维度上，必须要打折扣，那么你也就不能维持天猫“品质生活”的保障了。
对其他“心智+商家组合”进行分析，你也可以得出类似的结论。那么我们可以说，这个平台机制模块是不可能对这三种心智同时产生“+”的正向刺激的。也就是说，它们三个没办法形成飞轮效应。
拼多多这种心智的定位完全不同于淘宝、天猫的定位。虽然拼多多跟聚划算的定位类似，但是因为聚划算的用户心智与淘宝、天猫这两种主流心智的业务不匹配，那么心智的冲突必然会导致平台机制的冲突，这件事情是无解的。
阿里也不会为了打拼多多，而放弃有更大利润空间的品质天猫和有更多流量效应的万能淘宝。所以最终阿里也还是没有能够完全抑制拼多多，现在没有做到，未来也很难做到。
当然，不是说拼多多未来不会进入同样的追逐利润最大化的时代，事实上这一天迟早会到来。这一点，我们在之后的课程中会有详细解释。只是过去相当长的一段时间内，相比淘宝天猫来说，拼多多有着更清晰准确的平台心智。这就意味着拼多多的用户运营、平台运营、产品、研发等所有职能，会集中精力把一个心智打到极致。
在这种环境下，每个岗位上的员工，都会跟随这种心智。而每个环节，比如流量获取、导购、曝光分配、营销、订单、推荐、供应链、商家增长、转推荐，也会不断放大这种心智的技术可能。
那么你作为一个软件架构师，就要思考该如何通过技术放大以占便宜心智为主的马太效应。这就回到了我们上节课讲的设计思维，你既要脱离现有技术方案的束缚，同时也要忘记现有技术方案的强大，在更大的空间搜索这种技术突破。
比如说，如果你要关注如何通过技术充分放大马太效应，那你更多的注意力就要放在系统的弹性设计上，放在头部商品和尾部商品的分层管理上、CDN 分发机制上，也要放在订单管理和供应链效率优化上，甚至是整个平台的事件流的管理、分析和可视化上。
从技术的长期战略上，这种从流量到用户需求、到订单、到供应链的优势，也都需要不断提升数据、分析、算法的效率，从而保障头部商家的生存，以及保障用户的体验。
从更长远来看，这种单一用户心智所溢出的流量、需求，以及订单如何最大化转化，也是个非常值得长期投入的技术方向。
我不为拼多多工作，也没太关注过拼多多的技术，我的分析也不可能与黄峥所分析的完全一致，但通过这个案例我想传递的核心是：一个架构师，如果你能尽早看懂看透你公司的用户心智，那么你就可以在技术上提前布局，从用户思维出发，扩大你的技术搜索空间，最终为公司创造更大的价值。
案例番外篇 缩短认知差距 很遗憾，我没有像黄峥那样看透用户心智，这是一项非常了不起的能力。我自己也还在学习。
黄峥出来接受采访的时候，我当时已经在 AliExpress 做了快三年的 CTO 了。
AliExpress 是一个从中国卖向全球的跨境网站，当时我们几乎很少做营销投入，但是当时 AliExpress 有一批商品，对流量的吸引力非常大。比如说手机壳，AliExpress 能做到 99 美分包邮，而且这个品类的复购非常好。原因也很简单，国外很多地方，一个手机壳要卖到 10 美元甚至 20 美元。
不过在前面几年里，我们一直想不出 AliExpress 的准确心智定位，我们有段时间会总结成“新奇特”，有段时间会总结成“高性价比”，有段时间会总结成“好货不贵”，最后一段时间还总结成了“跨境长尾轻小件”。
而我在注意到拼多多的高速发展之后，也试图去逆向理解拼多多成功的原因。我下载了拼多多 App，买了一些商品，很多东西的确不咋地，没办法用。不过我本来就是研究它的，所以也不在乎。不过我后来发现，在研究的过程中我竟然也上瘾了，开始复购某些品类了。但当时的我还是没琢磨明白拼多多的心智定位。
直到黄峥的评论出来，我才意识到满足用户占便宜的心智，是手机壳这类商品在 AliExpress 上大卖的原因。也就是说大多数人能够在一个不知名的跨境网站上直接下单，内心都有一个欲望：万一我占到了这个便宜呢？
回头再看我们的定位词，新奇特、高性价比、好货不贵、跨境长尾轻小件，这些都不是心智，而只是一个心智带来的商品属性。搞不清楚心智，心智必然来回变动，肯定会影响 AliExpress 的发展。
这就是认知的差距啊！
远离邪恶的心智 我之所以举拼多多的例子，是因为我认为这个心智是可以持续的，而且有足够的供应链、技术和算法支持，最终能够达到一个可以相对维持和有足够竞争壁垒的状态。这种场景对于技术来说，相对而言就是个比较好的环境。
不过也有一些心智，相对来说就非常阴暗，也就是在利用人性的弱点去发财。比如说有些公司专门散布流言蜚语，有些公司专门引诱肮脏的交易，甚至有些公司在诱导未成年人犯错。如果你误入到这样一家公司工作，我强烈建议你尽早离开。
因为一个公司的心智定位一旦成型，是很难改变的。它会不断深入且放大这个心智。同样，你在这个环境中也会被马斯洛的理论所约束，因为你会通过一切手段最大化你在这个环境的生存。尤其是一个架构师，你的工作过程，其实也是对你的能力集合不断训练的过程。
就像我们今天讲的，拼多多的心智也反向选择了供应链、供应商和用户人群，最终也选择了能够最大化这种心智的一群技术人。
所谓一入江湖，身不由已。你在暗黑生意中练就的生存技能，或许在光明心智下就不具备竞争力了。你进了黑道，如果再洗白，这个过程同样也是要付出巨大的成本。想换个行业，不是金盆洗手那么简单的。
所以，我强烈建议你远离邪恶的心智。
小结 通过第 4-6 这三节课，我们深度学习并应用了马斯洛的人性理论。借由这个理论，我们理解了该怎么尊重和顺应研发人员的人性，以及如何从用户思维出发，扩大你的技术搜索空间，最终为公司创造更大的价值。
学到这里，我期望你能对我们这个模块的传递理念有一些深入的体会，比如认知。
我在 AliExpress 意识到自己在用户心智上的认知能力有欠缺之后，就下决心去寻找突破口，因此我认真研究了心理学，找到了马斯洛的理论。当我逐步把马斯洛的理论应用到实际中时，才意识到这个理论的强大之处。
我回头再看网上关于阿里与拼多多竞争分析的文章，感觉都没有找到一个第一性的出发点。解释的逻辑非常复杂，而且也没能完整解释这些年来两个企业之间竞争态势的变化。这也是我为什么会用一整节课来介绍马斯洛的理论，然后再从两个不同的维度讲解该怎么应用它。
除此之外，具体到拼多多的案例，我也想让你看到演绎法这一逻辑思维的强大之处。
所以这节课的学习目标不是为了让你看懂拼多多和淘宝天猫，而是为了让你通过这些案例学习到马斯洛理论的精髓，学习到演绎法的精髓，学习到从一个看似简单的理论之中看到未来的能力。
其实关于拼多多的分析结论，我三年前就得出了。三年过去了，两家企业依然在进行残酷的竞争。在我看来，这个结论依然有效，因为分析过程中引用的因素都还没有改变。
这个过程让我也意识到了一点，我对用户心智的洞察，与黄铮这样的顶尖高手相比是有认知差距的。有认知差距不可怕，可怕的是不去通过系统性的学习，主动去缩短这个认知差距。在努力缩短差距的过程中，我在管理和商业判断上也有了非常大的提升。所以我期望你能在日常的工作学习中不断寻找自己的认知差距，并且不断弥补它。这是你提升自己的不二法门。
那么下节课，我们就进入到第三条生存法则的学习。
思考题 三个思考题，任选其一：
设计思维其实无处不在，我认为 Hive 其实也是一个设计思维的好案例，你能理解我为什么这么认为吗？除了 Hive，你能举出其他可以体现设计思维的好例子吗？ 到这节课为止，我们已经完成了对马斯洛人性理论的学习。你能够举出你身边或者是观察到的一些好例子吗？通过这三节课的学习，你有没有什么新的启发？ 你有没有发现你与身边某些人存在一些明显的认知差距？你是用什么手段缩短这个差距的呢？
8 架构活动中对商业价值的考量
今天我们来聊聊架构活动中对商业价值的考量。
今天我们要讲的是架构师的第三个生存法则：作为一个架构师，必须要在有限的资源下最大化架构活动所带来的商业价值。对于任何一个架构活动而言，架构师的可用资源，包括商业成本、研发成本、时间成本、迁移成本等等，都是非常有限的。但架构活动就是要在这些限制条件之下，将商业价值最大化。
你可能还处在职业生涯的初期，不太关注商业价值，不知道我们的工作最终能为公司带来什么样的商业收入。我刚工作时，也从来没想过我的工资是从哪里来的；公司凭什么会在明天、明年甚至十年后还会给我发工资；更别说思考我为社会创造的价值了。
但随着在职业上的不断成长，我越来越深刻地意识到，必须要为自己所在的企业创造出可度量的商业价值，这是我们获得有质量的长期收入的重要前提。
要了解商业价值，我们就要先了解商业模式。所以在正式讲解第三条法则之前，我先来对商业模式与商业价值做一个简单的区分。
什么是商业模式？什么是商业价值？ 商业模式（Business model) 就是讲一个企业是以什么样的方式赚钱的，比如电商行业，有自营和平台两种不同的商业模式。
商业价值 (Business value) 呢，就是从现金收入的视角看价值创造的过程。你每天忙碌的工作，从企业的收入上来说，可以为公司带来什么样的短期和长期现金和其他收入，那么对这部分收入的量化，就是你创造的商业价值。简单来说，商业价值就是帮助公司获取商业收入。
那么作为一个技术人员，本来是写代码做架构设计的，那你是怎么为公司创造商业价值的呢？从创造商业价值视角来看，你的代码和设计有三个作用：
实现一个商业模式； 提升一个商业模式的效率； 加速一个商业模式的收敛速度。 也就是说，你作为一个程序员，主要通过上面这三个路径为公司赚钱。
举个例子来说，你写代码实现一个电商平台的一部分功能，最终电商平台可以获取交易收入。或者是你实现一个算法，提升了买家转换率，从而提升了电商平台这个商业模式的效率。你也可以通过 A/B 实验的平台、数据仿真的功能等等，加速一个公司的商业模式收敛速度。这些都是为公司增加收入的办法，所以公司多赚的这部分钱就可以归因到你，也就是你为公司创造了商业价值。
或许你是一家企业里做软件基础设施的，比如说写云平台、自动化测试平台、财务系统和数据平台。那么当你通过企业内部用户来间接创造商业价值，通过提升用户的日常工作效率、产品质量、运营效率、决策质量和商业洞察的质量，这个时候，你同样也为企业创造了商业价值。
我会把第三条生存法则分为五个部分来讲：
理解你所在的企业或团队的商业模式； 理解你在自己所处环境中创造的商业价值； 保障架构活动的长期商业价值； 在架构规划中寻找扩大收入的机会； 在架构规划中寻找减少成本的机会。 这节课我们先来讲前三个部分，下节课再来学习后面两个。
理解一个企业或团队的商业模式 我们先来看第一个话题，理解一家企业或团队的商业模式。
我发现，在一个领域做了很多年的研发人员、架构师，甚至是团队主管，都不太清楚自己开发的模块和所在领域的商业模式是什么。这很危险，不知道商业模式，就没法主动创造商业价值，你的日常工作很可能只是不断被动实现需求。这时候，你的成长也会是缓而慢的。
一家企业必须要有收入，虽然这个收入不一定来自当下，但它肯定会有一个可持续的商业模式。也就是从长期来看，有稳定且健康的收入，以及可控的成本，并且最终要做到盈利。这个商业模式，就是我们主动创造商业价值的突破口。
一个商业模式的技术表达公式 作为技术人，我们可以把自己领域的商业模式用一个公式来表达；然后学会在这个公式中，寻找并创造自己的价值。
这个公式，其实就是对所在行业的商业逻辑的数学表达，也就是我们常说的 KPI 的逻辑。
比如说天猫这个电商平台，它的主要收入来自于交易抽成：
总收入= GMV * Commission
网站的交易额越大，抽成就越多。网站规模越大，总收入就越多。
但到了不同的细分领域，每个领域的商业模式，就会分解成不一样公式了。比如说你负责天猫平台的一个由算法驱动的购物频道，那么你们的商业模式可能是这样的：
GMV= 流量 转化率 平均订单金额
对于你们整个团队而言，入口流量是一定的，那么你可以通过优化算法，来获得更高的转化率和更高的平均订单金额。
如果你负责天猫平台某个垂直行业的招商团队，那么你们的商业模式可能是这样：
GMV= 日均动销店铺数*店铺日均销售额
假设每个店铺的销售额差不多，那么你的目标就是让平台上有越来越多的店铺。显然，这种商业模式不同于上节课讲的放大马太效应的拼多多模式。你需要发现更多的玩家，努力扩大你的基盘。所以这种商业模式就特别适合用于像履约范围和能力都有限的场景，比如外卖、社区团购或便利店。
如果你负责某个垂直行业的大商户运营团队，那么你们的商业模式可能是这样：
GMV= 活动参与次数 平均计划销售额 计划达成率
你需要说服平台的大商户来参加平台活动。而且每场活动，大商户和平台双方都要达成一个计划销售额，保障双方可以投入足够的流量和营销资源，确保销售计划达成率到 100%。很显然，这种商业模式需要双方的深度配合，来确保营销活动的成功。
如果你负责商品团队，那么你们的商业模式可能是这样的：
GMV= 动销商品数 订单数 每订单件数 * 件单价
那么你们团队的商业模式需要找到更多受用户欢迎的商品，来提升动销商品数；通过撬动更多的商家参与营销活动，来提升动销商品数和订单数；通过满多件打折等营销方式，来提升每个订单的商品件数；通过更多的功能和商品的可选配置，来提升每件商品的单价。
刚才讲的这些公式里，有些术语你可能不太懂，没关系，因为我想表达的是：哪怕大家是在为同一家公司工作，但如果各自所在的领域不同，那么为公司创造商业价值的方法也有所不同。
对于一个架构师而言，你必须深入理解自己所在公司和团队的商业模式，并且想尽一切办法去最大化这个商业模式的成功概率。这样你才能通过工作为公司创造商业价值，同时也为你自己创造长期的商业价值。
还是那个简单的道理，我们的工资和各种收入，都来自于公司的商业收入和融资。
当然，并非每一家公司的商业模式都是绝对清晰和稳定的。大多数公司往往处在商业模式的探索期，有的团队连自己的 KPI 是什么都不知道。但无论如何，至少要理解你的团队为什么存在，你的工资收入从哪里来。
有句话叫做“良禽择木而栖”，就是说你要选择能够最大化自身成长的工作环境。那么接下来，我就通过一个例子教你怎么从创造商业价值的视角看一个部门， 帮你“择木”。
理解自己所处的工作环境 在一个企业里，从 CEO 到一线员工，大多数人的行为和决策都是基于资金的流转逻辑而来的。对此，我们的老祖宗有一句精辟的总结：“有钱能使鬼推磨”。
一位朋友曾给我讲过这么一个有意思的现象。在一家大企业里，只要是公司大力推动的项目，没有一个存活的。反倒是不怎么受公司高层待见的，由具备创业心态的员工自己发起的项目，最后都很成功。
在我认真思考，也近距离观察了这个过程后，我认为自己理解了这种现象的本质。我们还是通过一个真实的案例来说明。
一个大企业的独立核算部门，之前一直保持着高增长，也做到了盈利。但公司高层不满意现在的下滑增速，认为团队的人才构成、营销方法、运营能力有问题。而且认为部门的管理层自以为是，给的建议也不怎么听。于是公司高层就更换了部门的管理层。
新管理层到岗后，按照高层的指点，把之前的精细化运营方式，换成了高举高打的靠营销和大量模式探索投入来获取高增长的模式。很快，该部门的营销和运营成本一飞冲天，增速却变慢了。虽然业绩一塌糊涂，不过团队上下反倒天天颂扬公司高层的英明决策。仿佛自己受领导重视了，日子也就越来越有盼头了。尝试了两年下来，统计指标越来越玄虚，越来越难看懂，增速也一落千丈。
增速为什么会这样呢？新管理层是高层指派的，按理说双方有绝对的信任，应该是有一说一啊。但是仔细想一想，在新的环境下，公司高层的任何发言都变成了圣旨，别说是抗旨不遵，哪怕稍稍让领导觉得你缺乏信心和激情的表情都不会有。
对比之下，反倒是部门前管理团队一直坚持“客户第一”的原则和市场规律，对公司高层的不合理建议会据理力争。
为什么会有这种截然不同的行为呢？答案很简单：部门的资金来源逆向选择了人才及其行为。
部门重组后，成本一下子膨胀了很多倍，完全没有办法养活自己。这时整个部门都要靠公司高层调拨的预算来求生存。公司高层选择了言听计从的乖乖虎，那么这个乖乖虎就会以他最擅长的方式来获取部门赖以生存的收入，也就是公司的拨款。所以他们只有一条路，就是无时无刻讨取高层的欢心。
然而一个以客户为导向的团队，他们的首要目的不是听从上司的声音，而是去倾听客户的声音，从客户的需求中寻找自己能够创造商业价值的地方。所以这样的团队，绝不会靠公司的拨款过日子，他们的收入必须源自为客户创造的真实的商业价值。
这就是为什么越是受公司大力赞助的项目就越难存活的道理。
我们研究一家公司的商业模式，就是希望你认真理解自己所处的工作环境。
如果你活在一个靠公司拨款而生存的部门，那么你学习到的能力是有限的，因为你们部门从上到下都不是在求生，也不是为客户创造价值，所以你也学不到真正的生存技能。
或许短期内，你作为一个一线技术人员可以不必担忧。但是你越资深，待的时间越长，你对公司的依赖性就越大，那么你的风险也会越大。因为公司遇到困难必然会收缩资金，公司真的到了生死存亡的时刻，就只能依靠自力更生的部门了。想想看，这种靠拨款才能生存的部门，还会有保留价值吗？
总结来说，对于一个业务部门而言，存在不一定合理，只有提供稳定商业价值的存在才是合理的。
每个人都要有自己的商业模式 我们刚才讲了，你应该对自己所处环境的商业模式有一个深刻的理解，而且你最好能在一个可持续的商业模式下工作。
现在我还要给你讲另一个理念，就是每个人都要有自己的商业模式。意思是说，你必须在工作环境中找到创造价值的方式，这样才能保障自己一直被需要，也能保障未来的收入。
具体怎么做呢？那就是你要为公司、部门或团队提供可量化的增量价值。
这里面有两个关键元素。第一是增量价值，就是你通过工作所创造的价值，是在社会提供的平均价值之上的。
举个例子。2010 年之前，如果你是一个做微服务框架的高手，那你的增量价值就非常大，一个人能顶十个甚至一百个研发。因为那时候开源的微服务框架还不够成熟。但到了今天，如果你还是单兵作战，擅长写微服务框架，那跟开源的 Spring Framework 相比，你提供的增量价值可能就是一个负数了。因为团队剩下的同学还要花时间来学习、使用和维护你写的框架，公司也要为这些同学付出工资成本。
虽然你的工作没有变，但社会提供的开源解决方案的价值增加了，那你的增量价值相应地就会减少，甚至不存在。
第二个是可度量性。有些做技术的人会秉持这样一种态度，似乎他创造的价值极其普适，普适到像空气一样，以至于不能量化成商业价值，甚至谈度量就是对他工作的一种侮辱。
这个态度我觉得无异于自毁前程。
对于我们软件行业的从业者来说，价值创造永远是个衰减的过程，因为我们的经验会在信息扩散中迅速贬值。如果你不度量自己的增量价值，那就无法确保自己处在价值创造的前沿。你也不知道应该朝什么方向努力，才能最大化你未来的增量价值，更不能在一个相对未知的环境下扩大你的增值空间。
所以现在的问题就是，该怎么度量自己的增量价值呢？
答案是，把自己的工作放到我们刚才讲的公式里去。假设你是做商品相关的技术，那么：
GMV= 动销商品数订单数每订单件数*件单价
你需要度量的是，你的工作对公式中的某一项或某几项会起到什么促进作用。
比如说，你实现了一个需求分层的功能，使得不同需求层次的人群更容易发现自己所喜爱的商品，那么结果就是动销商品数在上线之后明显增加。同时，A/B 测试显示与之前相比，动销商品数增加了 15%，那么这 15%就是你所创造的直接增量价值。
事实上，你还创造了其他的增量价值。比如动销的商家数肯定也有所增加。此外，用户维度的转化率也会有提升。相应地，用户满意度和回购率也应该提升。
有了这些度量，你就会不断调整自己的知识和技能，不断搜索新的突破口，最终为公司创造源源不断的价值。而你的这个能力，会被周围人以及领导注意到，也会因此获得更多可以施展才能的机会与场景。
再进一步，随着时间的推移，你不仅能得到马斯洛所讲的有底气的自尊，还能得到从目标到实现手段的完整闭环。这个时候，这个技能就会成为你的一个核心技能。
架构师如何创造自己的增量价值？ 如果你已经是一个架构师了，你可能发现刚才讲的这两种方法已经不够用了。因为架构师需要做的是，在一个相对复杂的问题上引导实施一个结构化的解决方案。这个方案的参与者是一群人，所以架构师的产出不完全靠自己，而是靠撬动一群人来完成架构目标。
在这种情况下，一个架构师想要创造长期的商业价值，就必须同时满足三个条件：
确保最终架构方案的可行性。 确保参与方达成一个合理的实施路径，最终能够完成实施。 确保设计方案可以最大化解决方案的结构性。 事实上，这三个条件很难被同时满足。架构师之所以参与一个方案，往往有这么几个原因：已经有现成的方案，但比较复杂；参与团队众多，但各个团队的优先级不一样；公司压力大，能够投入到现存方案的人力资源有限。这就意味着你作为一个架构师，需要在资源有限的条件下做取舍。
举个例子。假设你们已经有一套在一些核心系统上使用的老网关，之后又开发了新系统，却发现老网关落后，于是就把老网关迁移到了 Spring Cloud Gateway 上去。但是最近你们发现，出于公司整体安全的要求，还需要在网关层上开发安全功能。这个时候，你作为一个架构师至少有三种不同的选择路径：
一种是在现有的两种网关上各自加安全功能； 一种是迁移和整合现有的网关，然后再加安全功能； 一种是在这两个网关之外再加一层安全网关，之后再想办法把现有的网关能力都迁移上去。 在不同的交付时间、需求压力、现有系统复杂度和研发人员能力的组合之下， 这三种方案都可能是最好的方案。但作为架构师，就要在兼顾方案可行性和实施路径合理性的同时，寻找一个最合理的结构化方案。所谓最合理的结构，就是从长期看，网关层不是越来越复杂，而是全公司统一、易维护和高可用。
如果相关方都能接受长期规划，那么构建第三个网关，然后逐渐把现有网关的功能都迁移上去，可能就是最结构的方案。反之，如果你的迁移项目烂尾了，那么两个网关变成三个网关，而且在迁移到一半的情况下，安全和网关逻辑散落在各处。那就是一个糟糕透顶的设计。
所以架构师在这个过程中创造的增量价值就在于能够审时度势，在企业内部各种资源限制和现实条件下，找到合理可行，并且能够最大化企业长期价值的架构方案。
事实上，除了一些现金流极度充足的大公司，大多数的创业公司都是要在平衡中逐渐迭代升级。我们在第三节课提到了，做架构和做业务一样，都不能靠饱和攻击取胜，而是靠对阶段性精确目标的最大化投入来取得进步。
那么下节课，我就来介绍一个我自己的案例，讲讲架构师到底该如何靠对阶段性精确目标的最大化投入而最大化自己的增量价值的。
小结 这节课我们介绍了架构师的第三个生存法则，那就是必须要在有限的资源下最大化架构活动所带来的商业价值。
不同的团队在以不同的方式为企业创造着商业价值。对于一个架构师而言，你要为公司、部门或团队提供可量化的增量价值，这样才能让自己处于价值创造的前沿，保障自己的长期收入。同时，这也是你增长技能、获取自尊的最佳路径。
那么在这种情况下，架构师创造自己的增量价值，就必须同时满足三个条件：
确保最终架构方案的可行性。 确保参与方达成一个合理的实施路径，最终能够完成实施。 确保设计方案可以最大化解决方案的结构性。 事实上，这三个条件很可能是互相冲突的，很难被同时满足。于是，靠对阶段性精确目标的最大化投入去取得成功，就成了实施架构活动的重点。这个我们下节课再深入讨论。
思考题 三个思考题，任选一个：
你理解自己所在公司或团队的商业模式吗？你知道自己在其中创造的价值是什么吗？这个价值能够长期维持吗？如果你有担心，为什么呢？ 你身边有存在一些不合理的现象吗？为什么呢？ 你有没有见到过一些架构方案，虽然可以满足我们所提到的三个条件，但是最终却失败了。这是怎么回事呢？你有个合理的解释吗？
9 如何为你的公司、部门或团队提供可量化的增量价值
上节课我们讲了架构活动中需要重视对商业价值的考量。作为一个架构师，必须要创造足够的商业价值，才能保障自己职业的长期。
那么你作为架构师，该如何为你的公司、部门或团队提供可量化的增量价值呢？主要有扩大收入与减少成本两种路径。今天这节课，我们就结合几个真实的案例来具体分析一下。
如何寻找扩大收入的机会？ 有的架构师不关注软件之外的事情，比如很少关心公司或部门的收入。这种性格虽然可以让他专注于软件工作，但从长期来看，如果不去思考如何通过技术为公司创造商业价值，那就很难保持或扩大自己在团队的影响力，职业发展也可能受挫。
所以哪怕没有人向你施加为企业增加营收的压力，你也要主动思考，你或你的部门，该怎么为公司创造更多的营收。
那么我们该从哪里寻找扩大营收的机会呢？除了之前提到的深度理解用户心智和商业模式，以及我们经常遇到的不同的横向问题，比如稳定性、安全、可测试性、可维护性之外，还有其他方法吗？
你可能听说过“在小数据里看大机会，在大数据里看小机会”这句话，这其实适用于我们所有技术人。
前半句指的是从个性需求中抽象出共性的机会。也就是从解决一个具体问题的过程中得到启发，并从中找到一个可以规模化应用的机会。比如做用户调研时，你发现有一个用户总是截图之后再通过微信把商品发给另一个人。那么你就会意识到，可以开发一个分享工具，通过小程序和 DeepLink 来获得更多的社交裂变。
后半句指的是靠数据来打磨用户体验。也就是通过数据分析找到机会点，然后通过产品和技术的改进，不断提升转化减少损失。这是算法和数字化运营的常见办法。比如淘宝 App 的首页跳出率是 2%，就是通过数据分析和打磨而不断提升的。
我特别强调一下前半句。事实上，很多著名的开源框架都是这么来的。离我们最近的一个例子就是 Docker。
虽然现在的 Docker 已经没有它如日中天时那么辉煌了，但毫不夸张地说，今天整个云原生生态的存在，引爆点就是 Docker。但谁能想到，Docker 最初只是为了解决一个环境打包问题呢！回想一下，从你进入计算机领域以来，你见过几个程序员会把心思放在运行环境打包上呢？
这个案例给我的启发就是，很多非常成功的技术人，他们往往就是看到了别人忽略的小痛点，或者在别人不去排查的小异常上执着探索，才最终跨越了现实的障碍。
举一个我们团队的例子。我们曾在海外做社交裂变，玩法与拼多多的拉好友砍价类似。但刚开始时，业务逻辑出了一个 Bug，用户没有达到提现条件（比如说拉到 20 个好友下载 App）我们就让用户提了现。当然这个 Bug 造成了一定的资金损失。
我想既然钱已经损失了，那么分析一下用户行为也是好的。比如到底是哪些人比较喜欢薅羊毛呢？这些人薅了羊毛之后会对我们的产品产生情感连接，提高忠诚度吗？
于是我们通过用户标签做了简单的行为分析，然后惊奇地发现：小城市里的年轻女性非常特殊，她们发现了这个提现存在漏洞后，就做了大量的分享行为，主动拉新。在她们的分享推荐下，很多人都下载了 App，而且这些人还没有加入裂变来薅羊毛。
更让我们兴奋的是，在我们修复了这个 Bug 之后，这些年轻女性的分享拉新行为依旧没有停止，而且她们拉来的用户的留存和购买率，竟然和大盘的拉新、留存差不多。也就是说，我们激活的这些年轻女性，是能够为平台带来大量用户增长的超级分享者。换句话说，对这个小 Bug 的执着，最终帮助我们找到了超级分享者。
后来我们就放大了这个玩法，故意放出“薅羊毛”的机会随机发给某些用户，尤其是年轻女性，并在其中寻找超级分享者。
接着，我们通过用户画像中召回与超级分享者最相似的人群，再用增强学习的方法放大这个人群的拉新效果。这样一来，这个小发现就能被大量复制了。
通过这个方法，我们发现前 100 万新增用户所用的拉新成本，连之前十分之一都不到，而且增长的空间也很大。这个方法玩了半年，让这个国家的互联网买家渗透率增加了 7%。
所以你看，在别人容易忽视的痛点和异常点上，深度挖掘可能大规模复制的机会，不失为扩大收入的好方法。
如何寻找减少成本的机会？ 能赚钱固然好，但省钱对于一个公司，尤其是成熟公司来说，也同样重要。
先分享一个故事。Robert Scott 是一位伟大的探险家，他是人类第二支到达南极的队伍的队长。令人遗憾的是，他与他的四位队友都死在了从南极返回的途中。原因很复杂，但一个颇为重要的原因就是食物不足。他们只带了够 4 个人吃的食物，而队里却有 5 个人[1]。
这跟软件开发有什么关系呢？
一个公司在做商业模式探索的过程中，跟一个人要向前冲刺是一样的，都需要消耗能量。只不过对于一个公司而言，这个能量是钱。一旦钱耗尽，公司就饿死了。当然你可能会说，我家不缺钱。可以，难道你不缺时间吗？
所以作为一线的架构师，哪怕你不清楚公司的财务状况，但你的任何架构动作，都要考虑公司的研发成本，确保团队的规模在公司财务状况的允许限度之内。这也是经济学中所说的成本观念。
其实这种成本观念公司上下每个人都要有。对于一个公司而言，一切有限资源上的消耗都是公司在架构活动中要付出的成本，比如时间成本、人力成本、机会成本、计算成本等。
拿人力成本来说。很多做技术的人都有官本位思想，认为下属多多益善。似乎下属多了，他的管理水平就高了。相应地，工资和层级会更高。所以就会故意夸大和消耗更多的人力成本来换取自己的晋升。事实上，一个真正有经验的管理者很容易就能鉴别这种中饱私囊的蛀虫。面对这种情况，我的建议是，无论如何也不要参与到这种行为中去。
分享一个我的经历。08 年美国发生次贷危机之前，我从耶鲁大学招了一个满分毕业的计算机系硕士生。他工作勤奋，产出也很好。但没过多久，公司就因为营收压力要强制裁员。由于他的入职时间最短，最终决定只能裁他。
他出生在印度一个普通家庭，从印度理工计算机系毕业后，又考到全球顶尖学府，这一路的艰辛可想而知。然而现实就是，在美国全职工作是拿绿卡留在美国的前提，我们一旦终止合同，那他只有几天时间去找工作。在经济危机发生的时候，这几乎是完全不可能的事情。
那两天公司上下都在裁员，当我叫他进办公室时，他已经预感到要发生什么，整个人都快虚脱了。他苦苦哀求，我都不知道该怎么回复他，只能沉默以对。这么多年了，我现在一闭上眼，还能想起他那一刻流露出的绝望眼神。
我分享这个故事，就是期望你知道，控制成本不是为了老板，而是为了我们自己。假设你总是以又大又笨重的系统去应对，那么在公司出现困境、经济出现低谷的时候，你的团队或企业可能就不复存在。相应地，架构师创造的软件也就不复存在，个人收入也会受影响。
从更理想化的角度来说，这么做也是为了自己的良心。我虽然无法预测未来，但在面对印度同事那一刻，内心还是非常自责。既然我不能给他一个稳定的任职机会，为什么还要让他加入？我的团队如果大幅盈利，那我不但不用裁员，说不定还可以收留其他员工。说到底还是我没做好。
我只是讲了人力成本的例子，其实时间成本、机会成本，包括技术的迁移成本，都是一样的。你作为一个架构师，要能省则省。
有些人会过分强调极客精神，事事追求完美。我觉得出发点是好的。但在一个企业中，追求完美必须以成本可控为前提。
性能优化案例串讲 关于第三条生存法则的内容我们就讲这么多，接下来分享一个我经历的性能优化的案例，来帮助你学以致用。
案例背景与分析 很多研发在做性能优化的时候，都会说“某个性能参数之前的 TP95 是多少秒，经过我优化之后，降低了多少秒”，以此来凸显自己的厉害。但这种玩法会让一个人逐渐忘记目标，只一心追逐性能上的极致。这就违反了我们今天讲的以商业价值为导向的架构原则。
我刚去 AliExpress 时，负责公司的全站架构。那时全站的性能非常差，但大家不知道这个差到底意味着什么，也不知道做性能优化到底要付出多大成本，又能带来多大回报。
当时我们已经有了全站的埋点。也就是说，我们有办法获取任意一个页面上跳出率和加载时长的关系，有办法获取任意一个页面上流量分布和加载时长之间的关系。我们也知道如果针对一个页面做优化，比如 JavaScript 优化、内容的静态化、图片压缩、动态加载等，都可以用来提升页面性能。
但问题就在于，如果针对每个页面的优化都要做投入。再加上维持这些优化效果，就要对页面的变更做限制和性能监控，那么付出的成本会非常高昂。
要知道，AliExpress 是个跨境电商网站，当时有 14 个站点，每个站点的前端代码都有微小的差异。一到大促，就要根据国家和语言一次性发布数千个页面。如果按部就班一个一个页面去优化，哪怕配十几个全职研发，从头到尾做一年也跟不上发布的速度。
但结果呢？
我们只用了 6 个同学，兼职干了不到半年，就把全站的订单数提升了 10.5%。这是怎么做到的呢？
我发明了一个方法，能够准确度量性能优化后每个页面的预期产出。而我们要做的，就是按预期产出除以预期投入成本，也就是预期回报的 ROI 来排序，再依次做优化。
具体的公式比较长，我就不在这里展开了。这个算法的核心原理展示在这张图里[2]：
如图所示，我们根据每个页面转化率分布的直方图，以及预期的性能优化后的结果，预测出如果不做性能优化而损失的该页面的转化率。我们把这个预测值叫做页面的性能损耗 Lpage。
因为我们有全链路的转化漏斗和流量统计，所以如果优化某个页面，把性能损耗追回之后，那么这个优化对下游，以及对订单和 GMV 的预测，就可以通过大数据统计提前算出来。
所以我们就以优化订单数为目标做了架构规划，然后统筹我们可以做的一切优化动作。
如下图所示，本来完全不等价的优化动作，有的在网络层，有的前端，有的在后端。这下子就可以在一个指标上做比较了，因为我们的每一个优化动作最终都能被归因成了订单贡献。
之后我和团队把它做成了一个基于性能损耗的度量系统，共申请了 13 项专利。而这个理念也从最开始的指导架构规划，变成了性能归因、性能监控、转化分析和准实时的转化排查工具，并从 AliExpress 的一个部门逐步推广到阿里巴巴的其他部门。
我是如何践行生存法则的？ 这个架构项目成功的关键，也正是我一直在遵照我这两节课介绍的生存法则。现在让我们一起通过这个性能优化的案例来检验一下，看看我如何用生存法则来指导架构活动。
另外，我们通过案例检验的过程，会重新总结并强调我们这两节课传递的一些核心观点。
第一，你作为一个架构师，在架构设计中要追求商业价值。
我们做性能优化时，不是单纯做性能指标的优化，而是一上来就以提升商业价值为目标。因此我们的优化目标是订单数，而不是一个技术指标。
第二，想要创造商业价值，就必须不断度量你创造的增量价值，这样才能确保自己处在价值创造的前沿。并且能够在一个相对未知的环境下，不断寻找自己的增值空间。
从这个项目的开始，我们就没想过要做全站的性能优化，而是发现了回报最大的单点，做针对性的优化。
为了做到这一点，我发明了准确度量性能损耗的公式，找到了部门层面的单一优化目标（订单数）。并把我们所有可能的优化动作，全部归因到这个单一的优化目标上去。
有了这个可度量的价值，我们就不再做地毯式的性能优化，而是做具有针对性的、回报最高的性能优化动作。
此外，我们也没有越做越宽。当发现性能优化的回报不够大了，我们就不再做性能优化了。而是换个赛道去创造价值：做现有网络的性能监控。
最好的证明就是当时我们和全球研究实力最强、监控能力最完善的 Akamai 合作。而且我们发现，我们对 CDN 网络的监控能力，在很多国家要远远胜过 Akamai。甚至到后来，我们干脆请 Akamai 的运维人员接了我们的部分报警。在此之后，我们又把应用方向再次扩大到业务转化问题排查等等。
第三，作为一个架构师，要最小化整个架构活动的成本。你要做的是：
确保最终方案的可行性； 寻找最优的实施路径，确保最终能够完成实施； 试图最大化最终解决方案的结构性，以最小成本放大你的产出。 我刚加入 AliExpress 时还没有很强的号召力，能调用的资源也极为有限。但当我发现性能优化是个突破口之后，就立即制定了一个可行的方案，而不是一个宏大的方案。
我当时仅仅把上面这个理念解释给了几个同学，然后我们就靠手算找到了回报率最大的几个页面，并且凭经验找到了投入产出比最大的优化点。这就确保了我们整个项目有非常强的可行性，同时也给了我们信心。
紧接着，我们迅速搭建了刚才提到的性能损耗的度量工具，验证了从工具中发现的优化点到订单回报的全流程。这样一来，不到一个月，整个项目的可行性就得到了验证。
但还是遵从同样的原则，为了确保投入最小化，我们仅仅升级了从优化点到订单的 A/B 能力。这样的话，我们的实施成本少，实施路径明确，所以项目可行性和合理性的风险就非常小。
最后，我还做了设计方案的结构性规划：先把相关理论和公式做了完整的推导，确保所有参与到项目的同学，都知道未来这个系统能给部门带来的核心技术价值，以及它对我们业务的支柱性作用。再把这些公式变成性能监控和性能损耗度量的工具。
这种结构化的思维方式使得我们在推广中的投入成本非常低，而且所有参与者都可以调用同样的工具来监控和度量性能的优化，以及实际产出。
可以看到，所有的核心能力，包括括数据链路、监控、A/B 能力等等，在建设时都没有打折扣。虽然我们没有打算一上来就把整个系统构造完整，但我们还是为将来的扩展做了足够的考虑。这也是为什么我们的系统后来能够演变出新的能力的原因。
第四，做架构和做业务一样，都不能靠饱和攻击取胜，而要靠对阶段性精确目标的最大化投入来取得进步。
我们的系统虽然后来演变出了很多能力，包括保障业务稳定性、系统监控、业务问题和性能问题排查等等。但是在这个过程中，任何一个时期我们都只有一个目标。尤其是最开始，我的目标非常窄，就是通过性能优化带来订单量提升。我们甚至都不考虑优化带来的服务器成本降低。因为前者是放大收入，后者是节省成本，我们出手第一步只考虑放大收入，没有考虑节省成本这个附带目标。
第五，不断寻找通过技术手段扩大收入的机会。
这一点非常明显，整个案例都是通过纯技术手段带来订单增长的玩法。
第六，不断寻找通过技术手段缩减成本。
这一点要着重解释一下。这个案例并没有缩减成本，而是通过对性能的投入来获得商业回报的。
但我们案例执行中的每一步，都试图最小化我们在性能优化过程中的人力和时间成本，同时最大化商业回报。我们是怎么通过技术手段做到的呢？
在案例中，我们走的每一步都试图以最小成本去放大收入，技术上我们在不断计算性能损耗，在寻找最大的性能损耗和技术人日投入之间的比值来选择我们下一个优化点。
我们这个架构项目没有以节省成本为目标，是因为对于一个处在成长期的企业而言，挣钱永远比省钱更重要。我在 AliExpress 任职总架构师和 CTO 的前三年里，很少把注意力放在节省成本的手段上。
一个业务在高速增长的过程中，目标用户群体和用户心智，以及商业模式、供应链和运营手段，都在不断迭代。那么我们在快速奔跑的时候，最高优先级就是保障增长。哪怕增速慢下来，我们的优先级也依然是探索加速模式，重回高增长。而当一个业务到了成熟甚至是衰老期的时候，那就需要通过节省成本来扩大利润了。
故事的番外 你肯定想问我最后那个被裁的印度同事怎么样了。当他走出我的办公室后，我整个人都要崩溃了。我在我们整个楼跑上跑下，挨个敲每个研发管理者的门，告诉他们这个同事有多优秀，裁员对他来说打击会有多大。我跑了一下午，没有得到任何回复，原本都绝望了。
但是下班前有个主管来找我，说他团队里有个同事知道来龙去脉后，决定在那天下午提前退休，把自己的位置让给印度同事。这位印度同事后来在这个团队工作了很多年，我们也一直保持着友好的朋友关系。
这个世界还是有很多善良的人的，我期望你能记住这个故事，善待你周围的人。
小结 这两节课我分享了一个新的架构师生存原则：你作为一个架构师，必须要创造足够的商业价值，这样才能保障你在企业长期存在的意义。
为整个企业创造商业价值，说得更直白一点，就是你要为企业赚到钱。
拉长时间来看，我们每个人，都会被我们所在的企业以商业价值的视角来审视。与其让别人审视你，还不如自己审视自己，在日常的每一天都去看自己的不足，从商业价值视角上看到自己可以提升的地方。这就是我们这两节课反复强调的事情。
因此，在日常的架构工作中，就要从创造商业价值出发，理解自己所在团队或企业的商业模式，理解自己为企业创造的增量价值。然后通过技术手段，最大化自己或团队的商业价值创造。
具体怎么做，其实我们不可能在两节课里穷尽所有的办法，但我们的确穷尽了所有的路径，那就是寻找扩大收入和减少成本的机会这两种。前者需要你不断探索、度量你的增量价值。而后者则需要你关注成本，平时能省则省，看准了机会之后再对精确目标做最大化投入，以取得最大的回报。而最终能做好这两点，还是要靠你日常养成的习惯。
思考题 能否分享一个你经历过的通过技术创造商业价值的案例呢？请注意，在分享这个案例的过程中，我建议你多强调这个技术突破点是怎么被发现的，具体的技术细节反倒可以讲得概括一些。
10 第四条生存法则：尊重技术的生命周期
今天我们来讲架构师的第四条生存法则，那就是尊重技术的生命周期。
人类的各种活动都要遵循事物的客观生命周期。不论是农业社会种田打渔，还是资本社会投资创业，行动太早或太晚，都会颗粒无收。技术也一样，也有自己的生命周期。而我们作为架构师，如果看不清技术的生命周期，那么所设计的架构就没法儿向更有生命力的新技术借力，自己的职业生涯也会受限。
那么我先来完整描述一下这条法则：在架构设计的过程中，架构师会有一个相对确定的商业和技术选择空间。在这个选择的空间内，架构师做技术选型的时候，必须要考虑到所依赖的商业和技术模块的生命周期。这个时候，我们就需要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。
我们先来讲讲，为什么有的人能够看准一个技术的生命周期， 而有些人却做不到。找到了根因，也就知道自己该怎么改变了。
把握时机 你有没有见过有的人年复一年辛苦劳作，却一无所成。而有些人似乎没怎么使劲儿，却能飞黄腾达。似乎大风总是吹向这个猪。你嫉妒地牙痒痒，心想，难道风就不能停下来，摔死这头猪？
你有没有想过，人家可能是会玩滑翔伞御风而行的猪啊！一个新的商业周期开始，就像是大风骤起，可以把一个看似不怎么努力的御风之人推向成功。事实上，如果从商业维度看，把握好周期远远要比努力工作更重要。
就像很多人职业不幸，是在五年前甚至是十年前犯下了致命错误。他们每天都在忙碌，来去匆匆，甚至都没有机会仰望星空。但就在恍惚之间，斗转星移，错过了一个大的商业和技术生命周期。结果是不论怎么努力，永远都慢这个时代半拍。
我也一样。我和身边许多做技术的同学，多数时间都在看小尺度的问题，日常工作和注意力都放在需求实现、领域建模、平台重构、中间件升级之上，因此我的思考也被这些工作所主导，很少去思考五年、十年，甚至二十年的技术趋势。我们不关注，当然也谈不上如何利用技术周期了。
技术的生命周期就像是潮水。潮来，汹涌澎湃，绵绵不绝。潮去，风平浪静，滩涂尽显。人一生的黄金岁月中也就是几个浪头而已。就过去 40 年而言，真正大的技术浪头有个人电脑、互联网、移动互联网、AI，差不多是每十年一个。你要在这种技术大浪潮之上玩好冲浪，就必须看清楚浪头，准确把握好技术方向和入场时机。如果错过，再等新的一个技术周期，几年的黄金岁月就浪费了。
所以在接下来两节课，我会给你讲讲怎么看清楚并利用好技术的生命周期。另外，我需要特别说明一下，我不认为自己真正看准过这些趋势。事实上，我也没能借到浪头的最大势。
我分析原因，是因为存在着三个人性上的弱点：
自我麻痹，以繁忙的重复工作来代替深度思考； 畏惧变化，以最小化改变来维持自己的心理安全感； 路径依赖，以过去的成功经历来应对未来案例。 我可能比大多数人幸运一点的地方在于，我很早意识到了自己有这些弱点，所以无时无刻都在提醒自己，去抗拒这些弱点。
那么接下来，我们先认真分析一下这三个弱点。只有克服了这些弱点，才有机会看清楚技术的生命周期，把握住新技术。
让我们放弃思考的三大弱点 弱点一：自我麻痹 自我麻痹是指我们用各种方法让自己放弃思考和探索的欲望。
其实大多数互联网从业者都是精英，从小到大都是学霸，内心不太能接受自己不思进取。但是人类进化出了一个自我保护机制，让我们不去天天担心风险。以至于我们常常会忽视自己现处环境的风险，导致我们不能全力探寻新的出路。于是我们会让自己每天都忙起来，用勤奋来弥补内心的不安。
团队和公司也是一样。尤其是一个营收压力特别大的公司，整个公司都忙着加班改代码，生怕老板看不到我们的勤奋。这个时候，没有人敢去挑战长期技术战略，也没有人关注新的颠覆性技术。
出现这种现象的根源，就在于高层管理者和软件架构师。有的管理者有意无意地把工作繁忙等同于有产出，于是让团队持续做毫无目标的布朗运动。其实麻痹自己越久，就越是难以突破。越没有突破，就越是没有去突破的勇气。这种恶性循环，让团队乃至整个部门，一年到头都没有实质性的进步。
我们只有承认和面对现在的风险，才有勇气放弃麻痹自己的行为，把部分注意力从当前技术放到更新、更有颠覆性的技术上去。而不是被动地等着他人告知自己下一步需求。
弱点二：畏惧改变 在讲马斯洛模型的时候就提到了，心理安全感的需求导致我们会畏惧改变，这是我们与生俱来的本性。
举个实际工作中的例子。前段时间有位技术人员给我分享他稳定性治理的经验，他描述了如何通过一个独立的运维团队，把一组很烂的微服务运维到接近五个九。我很诧异，他们直到现在竟然还在使用独立于研发的运维团队，来保障公司核心系统的稳定性。
后来追问细节才知道，这家公司连续几任 CTO 都没做过互联网高可用架构。因为这个核心服务是公司营收路径上最重要的一环，所以连续几个 CTO 都不敢大兴土木，从根本上解决这个服务的稳定性问题，而是通过运维的方式先顶着。这一顶，就是 4 年多！
畏惧改变，让这个团队从 CTO 到架构师，再到一线主管，都丧失了稳定性治理的勇气。直到现在，这家公司还在沿用几年前自研的微服务框架，而没有引入当下常见的 Spring Framework，也没采用 Service Mesh。从头到尾都是一套年久失修的老系统， 离开的人越多，懂的人越少，就越没有人敢改动。现在，公司只能靠大量的全职运维团队来续命，以至于风险稍大的发布，还是要运维团队来做。
其实我们都一样，一旦赌注足够大，就会产生畏惧。我们率先放弃了改变的勇气，跟着就会放弃改变的欲望。得过且过，离新的技术趋势越来越远。
弱点三：路径依赖 所谓路径依赖，就是你被过去的成功所蒙蔽了，以为过去的成功可以复刻。当过去的成功路径成了你唯一的选择，那么你也不会关注，更不会去探索新的路径了。
这就是我们儿时学习的守株待兔的故事。其实细想一下，守株待兔这件事再自然不过了。我们的大脑本来就是被不同事件训练出来的。哪天一个史诗级的训练样本发过来，正常人的神经元哪能扛得住？
还是举一个技术的案例。几年前有个同学转岗到我团队。他之前在一个大部门里做基础架构，曾经做过合并部署，就是把几个相关的微服务部署在同一台虚拟机，甚至是把几个微服务合并成一个巨石服务，然后部署在同一个 JVM 上。
这么做其实是个反模式，虽然会减少网络开销，提升性能，降低计算成本。但实质上，这个过程是用长期的运维和人力成本来替换机器成本。要知道，机器成本和网络带宽，在今天还基本符合摩尔定律。所以通过不断增加人力、维护和迁移成本，去替换每两年就减半的计算成本，这么做是不理智的。事实上，更大的成本是机会成本，这种巨石服务会增加升级改造的难度。也就是说，会让一个企业，很难快速响应新机会和新的竞争。
不过在他之前遇到的场景下，这样做的确可以带来实实在在的短期回报，所以他在之前的团队得到了很大的认可，也因此得到了晋升。同时，他也为自己的成就感到自豪。毕竟合并部署的技术难度非常大，因为越是调用量大的核心服务，代码往往越是年久失修、依赖复杂，jar 包冲突解决起来就越棘手。所以就像多少有点儿特长的技术人一样，他也是拿着锤子到处找钉子。只不过，他更像是拿着雷神之锤。
但我所在部门的 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 曲线的经典案例。你要是有兴趣，可以读一下 Docker 从发家到膨胀，再到被群起打压，最后到一个相对稳定的定位的过程。这对你理解热度曲线会有极大的裨益。
其实 Gartner 的热度曲线不完全是原创。法国著名社会学家 Gabriel Tarde 最先描述了创新传播的渗透过程，也就是 S-Curve。它的竖轴是“prevalence”，指一个创新的渗透程度。就像马斯洛的理论一样，Gabriel Tarde 的 S-Curve 理论同样也是一个基本的理论，可以用来解释很多与创新相关的现象的传播，包括现代企业的生命周期。未来课程里，我们还会再次深入讨论这条曲线。
不过不论是 S-Curve 还是 Hype Curve，它们都有一些缺陷，那就是没有对竞争技术的干扰做建模，所以这两条曲线都没有描述创新的衰老期。可以说，在产出期之后，技术还有两个状态：
衰老期（Progressive Aging）：以该技术为基础的产品，已经逐渐开始被下一代的新技术所替代，产品的市场范围和利润逐渐被蚕食。 退出期（Fade Out）：产品已经完全退出主流市场，仅仅在一些场景契合度与替换成本都非常高的情况下，还在被维护和使用。 那么我们从这两条曲线的描述中能得到什么结论呢？
结论就是：所有的技术都像人类的生命一样，也有终结的一天。这是个自然规律。
怎么从架构师的角度理解这句话呢？一个老去的技术就让他老去，快死的架构不值得投入人力和时间去维护，更不用说去翻修或者是复用了。
我们在前面在讲马斯洛模型的时候就提到过，围绕一个旧架构体系的人的利益，已经和这个架构深度绑定，这就导致这个架构就像一个生命体一样，已经有自己非常强大的力量去延续它的生命。
举个例子。某个大厂，几年间连续三次搭建国际化底层架构。每一次都彻彻底底地失败了。而且每次失败，都跟旧的架构体系有关。
搭建国际化体系的方法有两种。一种是改造国内的系统，也就是我们常说的国内技术出海；另一种是重新构建一套系统。
大厂的架构本来已经非常老化了，处于技术生命周期的衰老期。甚至第一次出海的时候还是巨石架构，核心服务一周只能发布两次。最多的时候有同学发布几十遍都不成功。而发布不成功再等一周的情况也非常常见。
但这还不是核心问题，全球像中国这么大的单一市场就只有美国，而大多数国内企业也出海的第一站又不是美国。那么把全球第一大单一市场的技术架构，搬到一个百万或者千万人口的国家来运营，就一下子水土不服了。
如果从交易体量来算，哪怕是最大的国家，也不到中国的百分之一。百分之一是什么概念呢？你可以换算一下，这个基本上等于在你们家里修了一个有 20 个蹲位的公共卫生间。哪怕你家有那个面积，但你能维护得过来吗？
虽然大厂里也有反对的声音，但每次反对的声音都被压制了。因为大家不是不知道自己的系统不合适出海，而是谁都想从这个饕餮大餐里分一杯羹。哪怕自己的技术再老，那也要老当益壮，为公司捐躯。
我曾经反复思考过，怎样才能避免让一个老的技术和架构侵入到新的体系里来？硅谷达人 Guy Kawasaki 曾总结苹果公司 Macintosh 的成功，他认为关键就在于“低调加物理隔离”。我觉得这也应该是这个问题的答案。那就是把这种新的项目和公司其他部门分割开来。参与的人少一些，时间给宽裕一些，尽量远离公司的核心业务和人群。
我们也可以运用之前在尊重人性这个法则里提到的用户思维，来引导团队放弃一个衰老的技术。因为曾经再伟大的技术，在用户的面前都是渺小的。为了更好的用户体验，一切都值得推倒重来。
你可能会说，我们今天讲顺应技术的自然周期，老去的就让它老去。这个观点似乎太悲观了，难道我们就不能抓住一个技术萌芽和发展的机会吗？下节课，我们就来讨论一下这个问题。
小结 这节课我分享了自己如何克服弱点，来提升追逐新技术周期的能力和勇气。其中我特别想强调的是，当你把自己的思考尺度从三五个月扩大到五年或十年，那么这件事情的价值必然会很大。这个放大思考尺度的动作，会让你用不一样的视角来看待技术。
看一次看不懂，看两次看不懂，但是看多了，自然会看出门道来。从本质上讲，这是个算法训练的过程。当你老用一个小尺度的样本来训练自己的大脑，那么你的大脑就是一个非常优秀的小尺度决策机。但当你坚持用大尺度的样本来训练自己的大脑，那么你在大尺度问题上的决策质量，也必然会得到提升。
在这节课，我还介绍了 Gartner 的热度曲线所表达的新技术生命周期，以及热度曲线中缺少的衰老期和退出期。了解一个技术生命周期的最核心目的，就在于利用这个周期为我们的架构活动创造出最大的价值。
作为一个架构师，知天道不够，还是要顺天道，也就是说我们的架构要符合技术的自然周期。反之，为一个落后的架构注入新生就是不符合天道了。而想要抗拒这种行为，我们就要从用户思维出发。为了更好的用户体验，要舍得放弃任何曾经伟大过的技术。
思考题 三个作业，任选一个：
除了我分享的三个弱点外，你觉得还有其他弱点会影响我们看更大尺度上的规律吗？你是怎么克服这个弱点的呢？ 你是如何看待当下比较流行热词呢，比如云原生、低代码、响应式编程、元宇宙，你怎么看这些技术的趋势？ 你或者你周围人，有没有还在维护那些已经在业界垂死的技术？你认为其中的根因是什么呢？
11
上节课我们讲了为什么要顺应技术的生命周期。但是“往者不可谏，来者犹可追”，我们就不能抓住一个技术萌芽和发展的机会吗？今天我们就来探讨一下这个问题。
技术未来的趋势，谁主沉浮？ 你有没有想过，到底是谁决定技术的未来呢？其实大多数人都不决定技术的未来，哪怕是雷军，他也在思考该怎么顺势而为，“于万仞之上推千钧之石”。那么，技术大趋势的推动力来自哪里呢？
我认为技术真正的推动力来自市场，需求规模决定技术走向。这由经济规律决定，不以个人意志为转移。哪怕一个头部大厂，也不能完全决定技术的未来，而是市场规模和成本结构决定技术发展的走势。
那么细分到我们关心的软件架构，它的发展来自市场的三个核心推动力，自底向上分别是：硬件技术发展、软件行业的竞争格局，以及垂直行业的商业模式的进化。越往上，距离我们越近，迭代得也越快。
从硬件技术发展看软件架构的未来 我们先从软件发展的最底层的推动力——硬件发展讲起。
看技术趋势，甚至看任何发展趋势，都要先找前置量（Leading indicator）。对于软件发展而言，硬件的革新往往是前置量。
首先，硬件技术进化的驱动力是需求规模。计算机硬件技术从巨型机、大型机、小型机，到 PC、Mobile 的进化过程，就是市场需求规模的增长过程。随着市场需求规模越来越大，就会有越来越多的技术创新参与到规模效应中来。
这种有规模效应的技术创新几乎是赢家通吃。而市场中最后剩下的玩家，很少会超过两个。一般是领先的玩家开发主流技术，来服务主流用户和主流场景。而略小的那个玩家，则去服务主流技术覆盖得不够好的边缘场景和小众用户。
其次，硬件技术的进化来自驱动用户侧的体验变革，再传递到软件的变革。从商用小型机到个人电脑，从 Mac 到 PC，从 iPhone 到 Android Mobile，都是某个硬件厂商先做大，然后硬件厂商对市场份额的争夺决定软件的走势。
这也是为什么我说硬件变革是软件行业的前置量。它在提醒我们，虽然我们是软件架构师，但关注硬件侧的变革很重要。顺便说一句，当下很火的元宇宙也符合这个规律。Nvidia 先做大，大量量产的 GPU 寻找增量市场，试图吹大元宇宙这个泡泡。接着 EPIC、Facebook 和 Microsoft 入场。
不过国内互联网软件研发人员，对硬件的关注普遍不够。他们受国内大玩家的影响，比如阿里、腾讯、头条和美团，大多把注意力放在了端（Mobile）上。但硬件更根本的改变是从设备（device）开始的，而不是端。
在移动互联网时代，之所以 PC、Web 玩家都去抢夺 Mobile 的端入口，并不是 Mobile 端一下子变得更有技术前景了，而是因为 Mobile 端之后的智能设备开始大规模量产了。大量的设备带来大量的新用户，也就是 Mobile 端侧的需求被迅速放大。有了大量的需求，才会有大量的软件供给争夺份额。
我之前在美国的甲骨文、微软和亚马逊都工作过，对设备的争夺感触颇深。这些公司看到了苹果在智能设备端的长期霸权和成功，所以一而再再而三地尝试做自己的设备。甲骨文的 Exadata、微软的 Xbox 和亚马逊的 Kindle，都是在各自领域比较成功的设备。尤其是 Kindle，给亚马逊带来了在电子书领域决定性的优势。
可以看到，国内很多软件玩家对硬件的关注不够，导致战略不够清晰，投入也不坚决，甚至可以说完全没有。我觉得这是个重大的失策。而国内做得最好的华为，本来最有希望做出一个现象级的产品，但因为封锁现在也不太好说了。
那么怎么关注硬件呢？在硬件生产一侧，规模效应和出货量的关系很大。其实这个关系非常普遍，几乎适用于各行各业。我特别建议你去一两家大型工厂实地参观感受一下。不必是与计算机相关的生产商，只要是现代化、规模化和流水线作业的生产环境就行。这样你很容易就能理解出货量对规模效应有多么关键了。
相比厂房，流水线上移动的单个产品，甚至是工人的成本，都可以忽略不计。一旦流水线建好了，就必须开足马力使劲生产，这样才能靠量产带来规模化的利润回收。
这也是为什么摩尔定律对英特尔公司的成功这么关键，因为他们靠摩尔定律对未来的收入和生产规模有了一个相对准确的预估。
接下来的规律就与我们软件架构师息息相关了。计算设备的出货量决定软件架构！因为单个计算设备的定价基本是由出货量决定的。计算设备的价格决定软件的计算成本，而软件架构必须建立在合理的计算成本之上。
过去二十年分布式计算的架构就是这个规律的一个实例。本来分布式软件开发的成本要远远高于单机软件的开发成本。但是当低成本算力和高网络带宽同时出现时，分布式计算的硬件和分布式软件开发加在一起的总成本，就远远低于单机计算和单体软件开发的总成本。而算力因为摩尔定律和尼尔森定律的缘故，在不断以指数级别扩大规模优势，所以就驱使全社会对分布式操作系统和计算有了大量投入。这些投入的结果就是分布式架构最终胜出。
在硬件行业的竞争上几乎永远是出货量为王，尤其是产品价格远远高于原材料价格的半导体行业。不过靠出货量而最终竞争胜出在半导体之外的行业也适用，国内电器和电子设备制造业就是个不错的例子。
那么如果你知道摩尔定律和出货量为王的规则，你会决定怎么决定架构呢？我认为在架构设计上，要尽量寻找利用和放大规模效应机会，保障开发软件所带来的价值在规模增长的过程中不断变大。
我们先看你在架构决策上该如何利用好硬件的规模效应。这一点，我们可以对比一下国内的云计算厂家和亚马逊 AWS 的决策。
亚马逊 AWS 在硬件上有一个原则，就是用最低的成本采购最便宜的硬件。甚至在运行环节，比如说机房运维，机房的冷却参数也可以设置在国家安全标准所允许的最高温度，以此来追求极端的低成本。结果就是 AWS 在软件和机制层面开发了大量的高可用计算能力，使得建设在不太稳定的硬件环境上的服务，能够稳定运行，不受硬件故障的影响。 最后呢，系统规模越大，采购量越大，单位硬件成本越低，高可用带来的增量价值对比硬件成本也越大，而开发成本分摊到每个计算单元上就越小。所以他们的生意越大，自己的竞争壁垒越高。
但在国内，云计算刚火起来时，大多数云供应商在采购和软件投入的决策上是反过来的。很多云厂商采购比较高端的硬件来提升系统稳定性，然后通过营销手段拉新，最后通过提价赚取利润。很少有企业投入力量做底层高可用技术的。结果是国内很多玩家入场早，但至今都做不大。
顺便说一句，在软硬件的长期战略上，我特别佩服华为。华为非常强调规模优势，愿意花大价钱在有长期规模优势的地方投入技术。有时间你可以研究一下。
另外，我认为在纯软件层面，其实也有类似硬件的出货量为王的规模效应。举个例子， 前不久，我和一位在大厂做稳定性的同学聊起了 Service Mesh。他表示对比大厂的稳定性体系，Service Mesh 还是有很大差距的。大厂做了多年稳定性，场景也特殊，其他的小企业根本达不到大厂的量级。 Service Mesh 不论从成本和可靠性，都没办法和大厂的现有体系匹敌，未来也不可能。
不过我却觉得这是典型的软件规模优势必然取胜的场景。成千上万的企业必然为 Service Mesh 提供海量的测试案例。对比为单个顶级用户定制一次性的解决方案，一个为整个行业提供基础设施的玩家必然是赢家。我这个预测可以让时间来见证。
总结一下：软硬件都具备规模效应，最终出货量最大的玩家会以更低的价格和更好的质量赢得市场，而硬件的发展往往会左右软件架构的走向。最终软件架构必须要利用好规模效应。
从“天神打架”看技术趋势 软件行业内的竞争，则是软件架构技术发展的第二个核心推动力。
我们大多数人都不为一个决定技术趋势的大厂工作。即便我们为这样的大厂工作，往往也不处在决策位置上。从个人角度看，这些决定技术趋势的大厂就像天神一样。民间有言：“天神打架，凡人遭殃。”言外之意就是，天神要真是打架了，你躲得越远越好。
不过在技术层面，天神打架决定了未来的技术趋势。如果有机会看到这种场面，势必要睁大眼睛看清楚，这样才能在一众凡人中脱颖而出。
天神打架的玩法其实也逃不出竞争的普遍规律，不外乎我们老祖宗讲的合纵连横。
从竞争而来的技术往往有个特征，就是后来者为了挑战先入者的霸主地位，往往在模式和技术上更开放，合作上更为广泛（Inclusive）。比如个人电脑 Apple 和 IBM PC 之间的竞争，移动领域 iOS 和 Android 的竞争，等等。
我们用云计算 AWS 和云原生基金会 CNCF 的竞争来举例吧。这个竞争还在进行当中, 分析起来更有意思些。
在云计算领域，亚马逊有非常大的先发优势。它在 2006 年正式发布 AWS，比竞争对手微软发布 Azure 早了两年。事实上，微软真正投入到云计算领域的时间更晚，要到 2010 年。而谷歌真正投入到云计算要到 2012 年。所以这么长的时间，给了 AWS 足够长的市场渗透期。这就导致在很长一段时间里，谷歌和微软都没办法缩小他们与亚马逊之间的差距。
直到 2013 年容器技术 Docker 的出现，竞争突然出现了转机。Docker 的革命性就在于它用一个轻量级的方法，完美解决了发布和运行环境的兼容性问题。任何研发人员都能以极低的成本，与另外一个研发在云环境下合作。
谷歌和微软意识到这是他们撕开 AWS 封闭式云计算环境的一个机会。所以 2014 年，谷歌不惜把自己珍藏的核武器 Kubernetes 拿出来，让大规模的云上和跨云的调度成为可能。与此同时，也开始加速在 Cloud 的投入。在这之后，谷歌和微软在云上的竞争有了明显转机。
不过革命者 Docker 只是昙花一现，它的实力根本没办法和 AWS 抗衡。毕竟桌上玩家的赌注是以百亿美金计算的，所以大家最后还是团结在了一个非常包容（Inclusive）的开发标准的周围，那就是 CNCF。
以 Kubernetes 为代表的 CNCF 的力量到底有多大呢？2014 年，Gartner 报道说 AWS 的算力，是排在它之后 14 家竞争者算力总和的 5 倍！到了 2015 年，这个倍数变成了 10。但是当 CNCF 的大联盟在这年开始形成后，微软和谷歌就开始反攻蚕食亚马逊的市场份额。
IDG 2020 年的调查说有 55%的调查对象（组织）使用超过一个以上的云供应商。而亚马逊的公有云市场份额却从 2018 年的 68%降低了 2021 年初的 56%。
CNCF，尤其是 Kubernetes+Docker，事实上给了云计算以开放性和互联互通性。也就是说，不是像谷歌或微软这样的单个公司在与亚马逊竞争，而是一大批的开放生态参与者联合起来与亚马逊 AWS 竞争。
结果会是什么样呢？一般来说，开放生态在长时间竞争的过程中，会胜过封闭的单个公司。这是打群架的一帮人前仆后继和一个独行侠作战的过程。过去这种竞争往往是开放的一方最终胜出，而且胜出者不一定是最开始挑战独行侠的那位。我们可以看看未来 AWS 对 CNCF 会不会是这样。
那么这对我们架构师意味着什么呢？这意味着，我们要把架构依赖在你认为的那个赢家身上。
从商业模式看技术未来 我们讲了技术的真正推动力来自于市场，而市场的一个重要变革因素就是商业模式。所以商业模式也决定技术的最终走向，是个前置量。
商业模式的不断更迭往往和行业密切相关，我就用生鲜行业来举例。
互联网最早入场生鲜时，是纯线上加中央仓储的模式。不过这个模式很快就被验证跑不通，因为生鲜的季节性很强。
在水果蔬菜到季之前，虽然利润高，但产量少、供给稀缺，所以采购是个大难题，难以做到规模化。 到季之后，线上与线下的竞争变得非常激烈。利润薄，供应链的成本占比很高，那么中央仓储的履约模式就没有优势了。 到了季节尾声，利润虽然又再次爬高，但供给质量难以保障，对用户体验的伤害较大。而且，同样因为稀缺性带来的采购挑战，导致很难做成规模。 之后生鲜进化出了线上线下模式，与盒马非常类似。盒马在高端社区的模式证明这是可行的。线下拉客，线上复购。但缺点是在铺开过程中找不到足够多的高端社区，而且建店时间周期长，专业人才招聘困难，扩张速度慢。
后来就有了前置仓的模式，比如叮咚买菜。叮咚买菜的成本结构远远优于盒马，一是没有门店，不需要像盒马一样找专业的管理与运营人才。二是前置仓面积小，所以铺开容易，扩张速度快，成本也低。但生鲜的季节性挑战依然存在，所以叮咚买菜在扩展品类到冷藏冷冻食品上下了很多功夫。
去年社区团购模式火遍全国。相比前置仓，这个模式的履约成本更低，因为它把履约成本和前置仓也降低了，让团长来负责团点，用户自提。拉新成本也因为团长的存在而变得更低，所以一下子有大量玩家进场争夺市场份额。
无序的竞争带来了很多新问题，比如团长变成了稀缺资源，成本也迅速蹿升。不过相比前几种模式，社区团购这种商业模式单均成本更低、扩张更简单、对管理人才需求更低、规模效应更大，也就是说社区模式的确更先进了。所以这个模式扩散速度就非常快，对相关技术人员的需求也非常大。
你作为一个技术人，尤其是这个行业内的技术人，那么关注商业模式的进化就至关重要了。因为这几种商业模式背后所需要的软硬件与运营技术之间的差异，实在是太大了。这也是为什么一个行业内的老玩家，很难迅速转身去追逐另一个商业模式的原因。
所以当新的模式出现后，你要提前看到这些商业模式各自的优劣势，尤其要从成本、规模效应、增速、技术增值空间等视角来看。当你发现了一个有优势的商业模式，就要立即去关注、思考和尝试做相关的技术创新。
顺便说一句，由于这些商业模式本身具有内在价值，所以它们的进化在其他行业也会被复制。最好的例子就是平台型商业模式和前置仓模式，几乎扩散到了其他各行各业。这方面的书籍很多，我就不做介绍了。
看清楚技术发展周期之后 你可能说了，研究这些东西和我有什么关系？我就是普通的架构师，知道这些趋势又能怎样呢？
关系大了！我们可以运用这些规律去选择我们的职业，选择我们的架构。把自己和团队的未来赌在哪个方向上，决定了我们在某个商业模式上要投入多少时间去学习和研究。
就以我的职业发展为例。2009 年我在美国甲骨文工作时，公司买下了 Sun Microsystems，出了 Exadata 服务器。当时市场上的销售非常好，一台 full rack 服务器价格 100 万美金。而且供不应求，以至于很长一段时间里，连我们自己的数据库研发团队都找不到测试机。
我那时虽是个基层小架构师，但对甲骨文的这个动作并不看好。因为在硬件出货量上，小型机没有任何规模优势可言。SGI 买了 Cray，SGI 不久挂了。Sun 买了 SGI，Sun 不久也挂了。所以甲骨文买 Sun，在我看来就很不明智。公司在短期内的确有了非常好的设备侧的创新，但是对比 Intel 服务器设备，Sun 的超级计算机算力只有几十倍不到，而成本却是 300 倍。
Intel 架构当时在用户市场的驱动下仍然遵循着摩尔定律，但是 Sun 只有企业市场，所以未来出货规模发展对 Sun 是不利的。我也就算准了甲骨文最终会落败。
尽管我的职业发展和股票都有保障，但我觉得必须离开，去更具备规模化的技术单元上做技术才更有前景。后来的事实也证明我的选择路径是正确的。甲骨文一度是全球最大的软件企业，但在做出这个和其他不够合理的决策后，慢慢就风光不再了。
所以作为普通架构师，研究技术趋势有一个显而易见的好处，就是帮你选择一个正确的行业，正所谓“男（女）怕入错行”嘛！
我做这个决策时，人才供给市场竞争还没有现在这么激烈。这更加说明，你要更早地从硬件发展、软件技术竞争格局和商业模式进化的角度，去看未来的技术趋势和架构机会。
假设你真的看清楚了一个趋势和赛道，你该怎么做动作呢？我的建议是你一定要把自己 100%的身心投入到你认定的方向上。
过去十年，在互联网领域是个赢家通吃的年代，未来很长一段时间应该还是这样。除非大多数国家在政策上做大幅调整，否则在这种大环境下，下一个小注就等于没下。无论是公司还是个人，在一个没有前途的赛道上，投入不投入都是必死。但在一个有前途的赛道上，投入了也要下大赌注才能赢（All-in）。
除此之外，这个法则对架构师的日常工作也极具指导价值。当你评审别人的架构选型时，一定要关注他是否采用了一个已经有规模优势，或者是即将具有规模优势的技术。
如果满足，那么这个架构建议基本就是合理的。在此基础之上，你可以再通过其他维度去看架构选型。反之，如果选择了即将失去规模优势，或者不具备规模优势的技术，你就有必要跟他探讨这么做选型是否合理。
有些技术同学喜欢展示一些小众技术。动机可能是好的，选型理由也比较充分（比如在性能或可用性维度上有优势），但从更长期的规模优势看，选型可能就不合理，你必须要阻止。
假设你还在职业生涯初期，看不清技术趋势怎么办？你是该看其他老师建议的 TCP/IP 原理、C 语言编程入门呢？还是找个火热的词搏命？
我先给你分享一个规律。任何一个新技术，你进入的时间就决定了你的未来。可以这么说，萌芽期赌命，增长期圈钱，至捧期交学费，灵感期拿价值，产出期养老，衰老期做死，退出期刨腹。
你要是年纪轻轻，就不要去学习任何产出期、衰老期，甚至是退出期的技术。我强烈建议你去看萌芽期的技术。光脚的不怕穿鞋的，万一赌中了呢？
什么是萌芽期的技术呢？其实最好的源头，就是从顶尖学术会议中，找一下最近三年论文增长最快的领域。如果你没有特别的偏好，那么哪怕追一个大词也行，比如元宇宙。你去这个大词的始作俑者，对元宇宙而言就是 Nvidia 那里，看看他们的开发者社区玩什么。
对于个人而言，技术的初期充满风险，但值得进入。在这个赌命的过程中，你不但可以学习设计思路，看到一个技术的成长与发展过程，而你自己也能获得先发优势。如果精力允许，那么多看些萌芽期的技术，对于你的成长而言会非常有价值。
这个时候，勇气很重要，投入到一个萌芽期的技术的确意味着更大的风险。而当你听到某个大词已经满世界流行，到处有人写书开课时，其实它已经过了至捧期。晚了！
小结 我来总结一下第四条生存法则。我们多数时间都在思考和解决小尺度的问题，但对我们个人发展和工作产出而言，更重要的是去看大尺度的问题，比如技术的生命周期。
在计算机时代，时间是个非常恐怖的概念。一个互联网技术的先进性和稀缺性很少有超过 3 年的。微服务、高并发就是很好的例子，七八年前还是是稀缺和高增值的能力，现在已经完全被开源框架和云计算厂商变成了互联网的基础能力。
所以，技术的生命周期对于一个架构师而言，有一层很重要含义：架构师需要不断监控自身能力的有效性和增量价值，不断提升自身能力的稀缺性和价值创造的空间。而这个不断监控当下技术发展的过程，就会让你在更大尺度上的思考变得更准确了。
我们这节课讲了这么多关于技术趋势和规律的事情，就是期望你能够尊重技术规律，爱惜时间。在计算机科学的世界里，你不能以考古学家的心态来学习和做事。
在具体的架构设计的过程中，尤其是在企业现有人员、技术框架和竞争环境的约束下，架构师的技术选择空间会比较局限。但是哪怕在这个局限的选择空间内，你也要尽量看准趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。互联网时代，搏命比抱大腿更重要！
思考题 今天的思考题比较费脑，我建议你只选一个：
Nvidia GPU 架构会完胜 Intel 架构吗？为什么？如果可以完胜，那它对服务端架构会有冲击吗？在这个趋势之下，你认为未来的云计算会发生什么变化？ 前些年国内不少大厂炒作混合部署，你认为这么做的价值在哪里？从长期来看，这是个合理的战略吗？你也可以把“合作部署”换成其他比较流行的技术来谈，比如 Event Driven Architecture、低代码、响应式编程。 最近两三年里，你认为最大的硬件行业突破、软件竞争格局变化或商业模式变革是什么？这个变化会对未来的技术产生深远影响吗？为什么？
12 第五条生存原则
前四条法则分别讲了目标、资源、人性和技术周期，这些都与架构活动的外部环境有关。那么今天我们来讲讲在架构活动内部，也就是在架构师可控的范围内，应该遵守哪些法则。今天这节课，我们就先从技术体系的外部适应性讲起。
达尔文说过：“既不是最强壮的也不是最聪明的物种，而是最适应变化的物种最终生存了下来。”从这个角度来看，企业也是一个物种。一个企业在行业内与其他企业形成了竞争关系。那么最终在竞争中胜出的，不一定是体量最大的，也不一定是技术最先进的，而会是最适应竞争环境变化的企业。
计算机行业有很多这样的例子。比如大企业 Lucent、Kodak、Compaq 都在竞争中没落了，曾经技术非常先进的 SGI、Sun Microsystems、Digital Corp 到后来也都挂了。一个正面的例子是，微软在云计算领域原本慢了大半拍，但他转身非常彻底，后来很快就追上了，成了异军突起的赢家。
那么你作为架构师，能在企业的竞争中做些什么，同时也为自己创造增量价值呢？答案是：通过技术手段为企业注入更多的外部适应性。
这就是第五条生存原则要覆盖的内容：架构师要通过优化架构方案、干预架构活动，以保证最终交付的项目不仅能满足既定目标，还能适应不断变化的外部环境。这个过程有一个总的指导原则，那就是为最终产生的架构设计不断注入外部适应性。
架构师能注入外部适应性？ 外部适应性是指一个企业对外部环境变化的适应能力，以及对新机会的捕捉能力。
我特别要强调“外部”这个词。它表示适应性不是面向企业内部的，而是企业在外部环境发生变化时、在与其他企业竞争时所具备的适应能力。这是一个攘外而非安内的能力。
怎么理解呢？像苏宁和塔吉特（Target）这样的线下卖场，打磨了很多年之后，他们的效率很高。但当用户的购买行为都转到线上后，他们适应新的竞争环境的能力就不够了。也就是说，他们在互联网时代的外部适应性不足。
在企业中，不同职能所处的视角不同。那么你作为架构师，需要从自己的视角为企业注入外部适应性。同时在这个过程中，提升自己独立创造价值的能力。
不同职能之间视角的差异性 在企业中，很多职能都可以为企业注入外部适应性，举几个例子：
业务同学通过商业和投资手段，来迅速捕捉外部的商业机会，从而为客户创造价值，为企业获取竞争优势。比如大公司通过兼并小公司进入一个新兴市场。 运营同学通过新场景迭代效率，来提升企业的市场竞争力和市场占有率。比如阿里的大促运营，就是通过一系列营销手段来提升获客效率和销售额的，从而扩大了市场渗透率。 产品经理通过不断打磨产品来提升用户体验，从而达到提升企业竞争力和市场占有率的目标。比如抖音创作者和用户端的产品优化。 技术同学通过打磨技术体系来支持产品和运营，从而达到提升企业外部竞争力的目标。比如各个互联网公司都在打磨个性化算法、运营后台、数字化运营体系。 架构师是技术职能的一种，所以也是通过打磨技术体系来为企业注入外部适应性的。当然，架构师这个职能有自己的特殊性。首先，架构师与研发经理不同。后者具有人员管理的职责，因而可以通过人才招聘、培养和组织架构的调整来创造价值。
然后，架构师也不同于研发人员。研发人员可以通过优化数据模型、算法迭代、代码重构和模块升级来为企业直接注入外部适应性。而架构师仅仅可以通过组织架构活动与优化架构方案设计，来为企业注入外部适应性。
可以看到，我特别区分了几种职能所处视角的差异。为什么这么做呢？我发现，很多架构师把帮助他人创造价值与自身创造价值这两件事混为一谈，这样做，你就很难提升自己独立创造价值的能力。
举个例子。在大公司某个程序员晋升时经常会套用这样一个逻辑：“我们的大促业绩同比增长了 50%，所以我应该晋升。”
仔细想想，这个增长到底是业务方在大促期间多拓展了一倍商家带来的？还是产品同学重新设计了大促的商品圈选和反向招商逻辑，导致平台商品增长了 30%带来的？还是你通过技术创新，用知识图谱把商品之间的语义标签做得更多更准，导致交叉售卖的量增长带来的？
所以说，你负责大促的商品模块，不代表大促中所有商品售卖赚来的钱都是你挣来的。这个时候，你就需要展示自己从技术视角上创造的价值，这才是你独立创造的增量价值。如下图所示，展示了业务、产品和技术视角的差异性。
业务、产品和架构师所处的技术视角，分别代表研发活动的三个不同层次。
第一个层次，研发活动由业务驱动，直接在业务人员的指挥下响应外部机会。我们把这一组研发人员称为业务线研发。在一些公司里，这些人一般直接向业务部门汇报。比较常见的是增长的产品和技术人员同时汇报给增长业务部门，以迅速响应新的业务机会。
第二个层次，研发活动由产品规划驱动。产品把业务活动抽象为一组产品，沉淀出产品矩阵，并通过产品运营不断打磨用户心智。在这个过程中，相应的技术人员会不断提升自己对产品的理解，并通过技术手段放大产品提供给用户的增值。
比较常见的产品有营销产品、供应链产品、物流产品等。除了产品特性本身外，一些纯技术手段，比如营销的资金池优化、反作弊、供应链优化、物流调拨等等，也会为产品带来新的增值手段。
第三个层次，研发活动就是由架构师主导的架构活动。架构师和研发同学对业务、产品做了一系列的抽象，最终形成由技术驱动的技术产品。比如工作流引擎、风控引擎、策略引擎、算法的特性引擎和标签引擎，都属于这一类产品。
案例指引 我拿一个物流领域的场景来举例。如图所示：
假设你所在的企业有比较复杂的物流场景，那么业务团队经常会找新的物流供应商， 为平台提供物流的外包服务，或者是覆盖一个新场景，也或者是覆盖一个新路线。那么相应的业务线物流团队，就需要与供应商对接，迅速完成接入。
但是随着时间的推进，团队在物流上的经验变得更丰富了，物流线路也越来越多，单个供应商对接的方式只会越来越低效。这个时候，就需要有一个产品团队，把企业内部与物流相关的服务抽象成一组产品，让产品替代人力完成供应商的接入需求。
这时候，产品和技术同学可能抽象了一组物流的自动接入 API，定义了要交换的数据和相应的交换标准，甚至提供了沙箱环境，为第三方软件服务提供商提供便利。他们甚至可以介入，帮助物流供应商迅速接入。
随着产品和技术能力的进一步提升，技术同学可能会看到更多机会。比如对不同物流提供商的履约能力、履约时效、服务质量、用户满意度等做评分，形成一个供应商的信用系统。这个信用分可以用来控制履约成本，保障履约质量，以及提升供应商的合作意愿。
事实上，这个系统的很多设计都可以抽象出来，提供给物流之外的供应商使用。比如品控的供应商、仓储的供应商、安装维修的供应商等等，这就形成了一套供应商信用管控、供应商管理，以及根据供应商服务能力与成本做成的动态路由的体系。
之后，这个技术体系还可以在多个领域重复使用。那么自顶向下，一个公司的外部适应性就逐渐得到了提升。从最顶层对单个业务场景的直接响应，到下一层多个业务场景对单个产品的抽象，使得该产品和相关技术能够直接服务到多个业务场景。最后，多个产品被架构活动抽象成了一组底层技术产品。而这些技术产品，就可以在多个领域的产品中得到复用，使得多个产品领域和这些产品支持的多个业务领域，都能提升自己的外部适应性。
通过以上分析我们就比较清楚了，架构师需要在技术层面为整个企业的技术体系注入外部适应性，这才是你独立于其他职能所创造的长期价值，是你有底气的自尊的源泉。
那么架构师怎么做才能为企业的技术体系注入最大的外部适应性呢？想逼近这个问题的答案，就必须理解削弱一个技术体系外部适应性的因素都有哪些。
影响技术体系外部适应性的因素有哪些？ 我们可以从三个角度来分析。
企业内部压力的影响 先从职能角度来分析。技术之外的同学，比如业务和产品同学，几乎不关注技术体系的外部适应性。一来他们不擅长，二来这也不是他们工作的优先级。遗憾的是，业务线的技术同学，以及与产品密切配合的技术同学，往往也很少关注技术体系的外部适应性。这里面的原因比较复杂，主要有三个。
第一，业务交付时间的压力。技术同学经常受到来自业务和产品同学交付时间的压力，这样一来，技术质量都很难保障，更不用说技术的外部适应性了。
第二，技术岗的供给压力。最近几年技术岗的供给比较缺乏，很多技术同学频繁跳槽，在一家企业的工作时间较短，因而他们在客观上就不太关注自己的技术口碑。
第三，考核的压力。不少企业把技术岗的考核内容、考核周期都与业务线牢牢绑定。而需要长期打磨的技术能力，既不能被关注和度量，也没有资源被孵化。结果就是短期效应非常明显，自然，技术同学就很少关注技术的长期适应性了。
除了团队内部的压力外，企业也面临着不少压力。首先，时间对于所有的职能而言都是稀缺资源，大多数互联网企业都采用了小步快跑的迭代方式，很少有企业是先把问题研究清楚才入场的。大家都是边打边学。不论是业务岗、产品岗，还是技术岗，都是摸着石头过河，这就不可避免地导致所有职能都被自己的认知局限所羁绊。
比如你经常听到技术同学说“产品同学不靠谱，一天到晚改需求”。产品呢，则每天抱怨业务同学从早到晚变方向，朝令夕改。
事实上，这种行为在越是高速增长、竞争激烈的行业越是常见。等你完全看清楚一个行业，新的商业机会早就不在了。
你可以观察下社区团购，在短短半年多的时间里，就有数百亿的投资注入到这个模式之中。等你花半年时间准备好大举进入的时候，不但战局大变，就连监管环境也发生变化了。这个时候，由社区团购这个新模式带来的市场渗透机会就完全不存在了。
这有点儿像打猎，你不可能说：“你别动，让我打死你！”你距离猎物越近，与此同时你失去这个猎物的概率也就越大。
可以说，在时间的压力下，大家都不会在完全看清楚一个市场才行动。因此处在最底层的技术体系，在外部适应性上不太可能有充足的时间和精力去做到完美。
企业外部环境的影响 最常见的削弱一个技术体系外部适应性的外在因素就是竞争。竞争会打乱企业的部署和节奏，迫使企业不得不响应市场环境的变化，而不是有规划有节奏地做自己的业务和产品。
在这种情况下，不但技术体系不能提升外部适应性，甚至连产品和业务也没办法通过自己的方式提升企业的外部适应性。因为竞争会打乱企业的节奏，给企业各个层面带来影响：
有的影响是业务层面的。比如多个企业对流量渠道的竞争，大促和营销力度和时长，履约和服务的人群和地区性优势，等等。 有的影响是产品层面的。比如不同的用户体验和用户心智，不同的产品定位和功能，等等。 也有的影响是技术层面的。比如对长尾设备的覆盖，对创新技术的支持，商业生态、产品技术和 API 的开放性和兼容性，等等。 竞争对手在业务、产品和技术层面的动作，都会迫使企业做出相应的应对动作，很少有企业能我行我素的。
还是用打猎的比方来解释。哪怕你起得再早，准备得再好，总会有其他猎人在那里捣乱。这些猎人哪怕打不到猎物，也会放一枪把猎物吓跑。否则你打到了，他就再也没机会了。
除了竞争外，还有其他环境因素也会影响技术体系的外部适应性。比如用户需求的流行趋势、宏观经济周期、监管环境、资源供给、技术趋势等等，无时无刻不在发生变化，这些也可能导致企业原有的外部适应性的计划失效。
举个宏观经济环境的例子。在大多数风险投资充足的地区，尤其是中国和美国，大多数企业其实并不具备对外部适应性做长期规划的条件。因为一旦某个外部环境的变化被市场感知到，这种变化如果不能被已有玩家高速响应的话，那么资本市场，尤其是风险投资，必然会迅速入场。
就像在国内，很少有明显的机会能够在半年内都没被资本深入挖掘的。往往是机会一旦出现，资本会在一两个月内迅速集结力量做出响应。
企业组织结构的影响 最后一类削弱技术体系的外部适应性的因素，与企业的组织结构有关。不论是业务线研发、产品研发，还是基层技术的研发，这些同学的本能反应，都是先维持自己的生存空间。
另外，因为各个领域的内部目标、具体挑战和资源环境都不相同，所以每个领域的研发人员设计出来的软件架构自然也存在差异。
也就是说，研发人员由于自身认知局限、沟通的局限，或者是为了保护自己团队的利益，导致他们的设计都是局部最优，而不是全局最优。这种局部和全局的冲突，在一个跨团队的大型架构活动中很容易外化出来，导致整体的外部适应性随着组织复杂度的提升而被削弱。
那么你作为一个架构师，就要通过技术抽象为一个企业创造出经得起时间考验的整体设计，从而为企业的整个技术体系注入外部适应性。那么如何做到这一点呢？我们下节课就来讨论这个问题。
小结 这节课我们聊到了一个很重要的话题：你作为独立于其他职能的架构师，可以创造什么价值？有些 leader 认为自己创造的价值就是被自己管理和影响的人的创造的增量价值之和。也就是说，这些 leader 是间接创造价值的。架构师当然可以通过参与架构活动的每个人间接创造价值。 但是在此之外，你要通过为软件系统注入外部适应性而为企业直接创造价值。
我认为架构活动是企业软件进化的一个特殊节点。在这个节点上，所有参与者都在重新审视现有架构体系的不足，然后引入新的设计和技术。在这个过程中，你其实在为企业注入新的技术基因。
从这个视角来说，上帝经由你的手来改变企业这个物种。那么你就要抓住这个机会，运用我们前几个法则中传递的知识：逼近正确的目标、尊重人性、最大化商业价值，以及利用好技术生命周期，然后通过你的架构设计和对架构活动的决策来最大化企业的外部适应性。
思考题 请列举一个通过某种技术为企业注入外部适应性的例子，并着重描述：外部环境发生了什么样不连续的变化？这个技术为什么可以帮助到企业？你是如何识别这个技术的价值？还有其他选项吗？ PC 互联网到移动互联网过渡的时候，很多技术由于没能适应这个变化而逐渐被淘汰。你有类似的经历吗？比如在外部环境发生变化后，你开发的原本很受市场欢迎的技术，一下子就被大幅削弱了？为什么很难适应这种外部变化呢？你认为什么样的技术可以适应这种变化呢？ 外部适应性是面向未来的。你有没有见到过某个技术选型看似万无一失，似乎绝对能保证企业的外部适应性，但后来却在竞争中落败了？而你发现竞争对手的选型非常成功。你认为是什么原因导致你们做出错误的选型，但是竞争者却能作出正确的技术选型呢？ 当然，你也可以分析开源的技术。
