【笔记】架构师思维养成之路

最近在某客上学习了一下郭东白老师的架构课，郭东白老师是原来阿里P10，是云计算和国际化电商平台领域的资深专家，他完整讲述了自身作为架构师该如何设计架构，以及对架构师的一些思考。整个囫囵吞枣般看完，好似虚竹一般，虽获得无崖子70年功力，但如何打出妙招，少侠我还多需努力。

1. 架构活动

一名软件架构师要为相对复杂的业务制定，并且引导实施一个结构化的软件方案。这个发现最终方案和推动实施的过程，就是架构活动。架构活动是作为架构师必须要认识清楚的，但同样也是很多架构师所忽略的。所有的架构规划必须有且只有一个正确的目标，而且它必须与公司的战略意图相匹配。这是架构设计的起点。​

我们往往做架构设计时会偏离目标，主要可以归结为两大原因，一个是技术上的，我们常常因为开发者的个人利益（技术能力，与其他开发者的关系，个人喜好），或对先进技术的强烈好奇，无脑引进最新的但还未成熟的技术框架（后面找工作可以吹吹，手动狗头），或者跨部门信息沟通不畅，过度设计了很多不需要的逻辑；二是业务上的，也是我们常常感到无能为力，比如公司领导换了一茬，极大概率会吧年初规划的OKR推倒重做，甚至上任的CEO也不清楚目标，大兴土木，随机探索，再或是市场方调研准确度低，我们架构需要设计两套业务靠大量的A/B测试来决定哪一套业务才是最符合目标的。

那么，架构师该如何规划一次架构活动呢？我们可以从以下几个方面入手。

1.1 可量化描述

理解当前团队的商业模式，或者具体为团队的OKR，以及团队和公司的OKR之间的关系。我们对这个O进行数学建模，最好用一个公式来表达出，哪些因素会促使达成这个O，每个因素的影响有多大，比如有的电商平台的主要收入来自于交易抽成，那么公式可以为:

【总收入=GMV*Commission】

针对于上述量化描述，下面设计出的方案也要遵守三个条件：

1. 确保最终架构方案的可行性 要自己搭建环境，模拟客户场景，完成POC，考虑新方案的实现成本有多少，新方案是否可以全面替代现有方案，全面替代的成本有多少，如果不能全面替代，而是两套方案并存，那么增量的维护成本有多大？
2. 确保参与方达成一个合理的实施路径 架构活动需要尊重和顺应人性，尊重人的基本感受和合理需求。作为架构师要充分考虑研发人员的人性，同时也要站在用户角度去思考架构规划。
3. 确保投入最小成本放大自己的产出 先跑起来，包括人力成本，时间成本，机会成本，技术的迁移成本，作为一个架构师要能省则省，但后面的核心能力，包括数据链路，监控，A/B能力等等，在建设时不要打折扣，虽然我们没有打算一上来就把整个系统构造完整，但还是要为将来的扩展做足够的考虑。

1.2 技术选型

在架构设计过程中，架构师的技术选型，要看准技术趋势，选择已经有规模优势或者是即将有规模优势的技术，而不是选择接近衰老期的技术。

推倒老的技术，有时会遇到非常大的阻力，因为这是人性的弱点，大家畏惧变化，以最小化改变来维持自己的心理安全感，写了10多年的java现在让他搞安全用rust，他一定是畏惧的，其次，就是经验主义，以前觉得用中台架构做到了业务成功，这次依然认为可行。

那如何看准技术趋势呢，可以参考Gartner热度曲线：

一个技术的发展一般分为五个阶段：萌芽期，至捧期，低谷期，灵感期和产出期。而架构师需要做的就是一个老去的技术就让他老去，快死的架构就随他灭亡，快死的架构不值得投入人力和时间去维护，更不用说去翻修或者是复用了。

在AI相关的技术热度曲线中，可以看到目前生成式AI，达到了至捧期。

1.3 风险挖掘

在这一步，我们需要从多个视角对重大风险做一个全面的挖掘。

第一个是项目交付的视角，现阶段我们认为目标已经是合理的了，所以就需要在时间和人力的限制条件下，看看执行过程中是否存在风险，在当前交付的时间约束之下，是否会出现研发动作和设计完全变形的情况；在当前的时间要求和资源投入，实施方案是否高于质量底线，多个参与项目团队能否有效协同，是否有足够的时间，让团队处理出现的问题（线上问题，一个bug解一天）。

第二个是商业价值的视角，是否存在大幅影响最终产出的商业价值的因素，比如互联网企业最容易发生的恶性竞争，本来一个好的商业模式，大量玩家入场后，可能最后会变得无处逃生。

第三个是人性视角，是否某一个团队做的过于边角料或者做的东西不利于他们的考核，所以正如上一节所讨论，架构方案是否符合研发人员的人性。

第四个是其他风险，比如说监控风险，法律风险和安全隐私风险，你用的开源框架是否有一些重大的bug，或者用了一些盗版软件等。

那么如何在最短的时间发现最大的风险呢？

一方面要靠自己的判断，一方面要锁定公司内的领域专家，把项目背景和情况描述出来，然后认真听取他的意见反馈，然后与风险决策建议者一起碰撞，试图发现更大的跨域风险，每人每次大概1小时的样子，一般来说，覆盖一个大项目的所有视角，也就是十几个人。

针对风险的具体场景不同，需要对备选方案进行组合，最后给出预案被迫实施后的估计值：

• 总时间成本
• 总人力成本
• 总资金成本
• 效果折扣，降级方案造成的损失有多大
• 用户体验的损失

在最后的决策环境，我们要站在对全局有利的视角，而不是从赞助者或执行者的视角，要敢于冒险，但也要保持理智。

1.4 规划确认

假定我们已经树立了一组必保需求，然后从这组需求中推导了一组任务，并且我们以最大化某个项目目标的方式，将这组任务分配到了执行团队中。接下来就是规划确认环节，共八个部分：

• 定稿架构规划文档 此时已经收集了几乎所有与架构规划相关的文档，那么在定稿过程中，你可能会和不同团队，企业外部专家产生很多交互，我们需要把输入转成一个可行且有约束力的规划。这个有点像合同，确保所有参与者有能力且意愿履行责任，确保每一个都是经过完整性验证的交付项。
• 组织用例文档 最顶层的用例不要超过10个，价值点太多决策者也没时间确认，并且在一个时间高度紧张，交付风险极大的场景，架构师不应该把注意力放在超过10个的交付情况上。 用例的描述除了要尽量简洁外，还要将其整理成一个文档，这样的话，几乎所有人能都通过阅读这些用例来获得更为宏观的视角，而具体的每个场景的细节描述和需求文档，可以通过链接记录到另外的文档中。
• 确认交付节奏 这个环节是标准的研发流程，可以把任务录入到scrum看板中，根据燃尽图，甘特图等追踪必保任务的交付情况。
• 确认领域模型 就是DDD领域驱动设计，这个还是比较复杂的，简单说哦，软件系统是对现实世界的真实模拟，那么现实世界 的业务，下沉到软件世界后，该事物在现实世界中被赋予什么职责，在软件世界中就被赋予什么职责；在现实世界中拥有什么特性，在软件世界中就拥有什么属性；在现实世界中拥有什么行为，在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。 详细得看看这个了：《领域驱动设计》https://book.douban.com/subject/5344973/
• 确认API 各个API录到API管理平台，类似于Eolink，易读易用，规范性好，可测试性好，API即文档。

• 确认消息和数据流 再确认好API之后，接下来就要去确认消息和数据的流转了，也就是在某个角色在某个时间能为某个使用方提供的消息和数据。数据共享包括埋点要求，指标定义，必须支持的分析场景，模型定义，数据的及时性和准确性，数据清洗的分工和数据权限管理等。
• 确认交付节奏 关注强依赖的任务的交付，比如数据存储业务需要其他团队配合，需要数据中台或数据仓库去开发适配等，那么这就属于你需要关注的强依赖任务。
• 确认规划完整性 团队内部梳理边界，一旦他们发现了影响其他团队的重大风险存在，就可以拿到整个项目组层面来讨论了，尽量做到每个模块有一个owner，每一个边界划分都有一个执行者，每一条边，无论是API调用，数据流，还是消息机制。

2. 职业成长

我们先回顾一下代表架构师成长的五种角色：程序员、兼职架构师、跨域架构师、总架构师和 CTO。我们先看一下下面这张图，通过这个总结思考，我们能看到架构师这个职业背后更深刻的内涵。

​

如上图所示，这五个角色分别代表了架构师成长的五个阶段。在不同的阶段，架构师关注的是软件架构的不同侧面：

• 在程序员阶段，主要关注需求实现的结构化，也就是一个模块内有关业务的部分。
• 兼职架构师阶段，主要关注模块整体，以及与业务无关的横向问题。
• 跨域架构师阶段，主要关注不同模块间结构合理性的问题。
• 总架构师阶段，关注技术架构的长期正确性。
• CTO 阶段，关注企业的长期生存。

那么我们思考一下，想培养出这五个维度的能力，需要具备什么必要条件呢？

• 思考力：思考力是在我们生活和工作中，通过独立思考带来有效结论的能力，有别于其他人的视角 + 不同的证据组合 + 不同的思维方式
• 信息内化能力：所谓信息优势，就是你所在的环境有大量高质量的信息，或者你获取这些信息的能力比别人强，渠道比别人多。所谓内化，是指能够从这些源头中有效总结，比别人积累了更多的知识。这里我特别用信息，特指独立于客观存在的那些内容。用知识，指我们脑海中可以随时随用的那些内容。 信息内化的过程，也就是从接触信息到消化吸收成个人知识的过程。如果能更进一步把这些知识系统性地表达出来，你就是一个很了不起的知识传播者了。
• 适应力：比如在职业初期要沉迷于技术，而一旦成为 CTO，反倒要不断思考技术之外的解决方案。 在职业初期基本上不需要什么人际关系能力，但是作为一个跨域架构师，要想解决好冲突，这个能力就是绝对必须的了。

3. 思考力

每个人的思维方式都不一样，有的人喜欢在别人逻辑推导的基础上发现漏洞，并试图修复优化；有的人喜欢对问题进行层层分解，自己独立得出结论；也有的人喜欢从其他学科中寻找类似的问题，从而发现新的解决问题的思路；还有的人喜欢在跟别人的深度讨论和辩论中逼近真理。通常来说，不同的思维方式会带来不同的推导路径，从而得出不同的结论。

然鹅，在现实生活中，你会发现，越是那些有挑战的问题，参与讨论的各方越是缺乏对问题的统一定义，因此很多时候我们花了很大力气，之后才发现大家讨论的都不是同一个问题，目标也完全不同。不信的话，下次在大家争论得不可开交的时候，你可以试着打断一下，然后让每个人把正在讨论的问题分别写在纸上，看看大家对问题定义的描述是否完全一致。反正我没遇到过一致的情形。

因此，越是有挑战的问题，越难找到统一的度量结论的标准。事实上，如果一旦思考清楚我们在一个问题上的目标，并量化出这个目标的指标，解决方案往往也就开始浮现了。它不再是一个未解的难题。

架构师该如何通过独立思考来最大化自己的增值呢？

• 培养实证思维 实证思维对模型有一个评判标准，并指出了模型的优化路径。一个有实证思维的人，会认为自己的模型及从模型总结而来的规律是普适的、可以表达和复制的。如果有更多的人来尝试，会让自己的理论在更短的时间内变得更完善。实证主义有一些特征：一个基于科学理论是可以被独立表述的，这些理论是有一定的逻辑结构的，是完备和自洽的，这种理论可以被浓缩成一组公理，这些理论是普适的，是可以复现、迁移的，也是可以被比较和验证的。
• 亚马逊高效6页纸

1. What we do?（背景）
2. Why we do it? or What’s the problem（解决什么问题）
3. How we do it?（我们怎样做）
4. Validation（如何验证）
5. Discussion/Analysis（讨论、分析）
6. Summary（总结）

• 去中心化思维 去中心化思维不是让你放弃思考，而是要求你频繁切换思考角度，将自己放在各个分布式的节点上做换位思考。从而帮助其他人看到各自的思考漏洞，看清楚他与战略目标之间的差距。 这种思考习惯需要靠长时间的训练才能逐步养成。如果你是一个技术管理者，那么在团队里定时做深度的代码与设计 Review，会是一个非常好的帮助团队同学养成去中心化思考习惯的方法。
• 批判思维
• 保持Reading，洞察案例
• 保持合作的心态，是交到更多高质量思考的人的前提。

谨以此文，多多勤勉，多多温习。

Reference

郭东白老师的架构课