之前我在公众号发过一次孙玄（人称：玄姐）会在阿里云开发者社区开一个五节课程的架构师成长之路直播课，我也学习了他的第一课《技术人的道与术》后做了学习整理笔记并分享成文。今天，和你分享我学习他的第四课《架构设计思维模型》做的学习笔记，会和你分享三个架构师需要具备的架构设计思维模型。
模型1：业务需求至简抽象分析模型
玄姐认为，架构师需要具备的第一个重要的思维模型就是：业务需求至简抽象分析思维模型。通俗来讲，就是能不能抽象地分析出业务方或者客户方提出的一个需求背后，他真正的需求是什么。换句话说，能否分析出这个需求背后的本质是什么，而这个过程，就是业务需求抽象的过程。
其实这个思维模型也是产品经理的必修课，对于产品经理来说，挖掘「一匹更快的马」背后真实的用户动机是最重要的基本功，不要停留在用户提出的所谓需求上。
有句关于产品需求挖掘的名言「用户不需要1/4 英寸的钻头，他需要的是1/4 英寸的洞」「用户需要的也不是1/4 英寸的洞，而是在墙上挂一幅画」「用户不是需要画，他需要房间的格调」等等。这些听起来像是抬杠的演绎，其实就是不断探索和挖掘真正需求的过程。
在实际的实践过程中，我们可能经常使用的方法是5个Why，即连续提问5个为什么，从而追究其根本原因，试着找到用户背后的真正动机。
我在去年学习刘润老师的《商业洞察力》时，了解到洞察力这个概念，其实它就对应了这个需求抽象分析的过程。所谓洞察力，就是透过表象，看清“系统”这个黑盒子里，要素以及它们之间连接关系的能力。
润总说，任何系统都可以进一步拆解为多个要素，以及要素之间的连接方式，即系统=要素 x连接关系。
举个例子，对于电脑来说，主板、显示器等组件和零件就是要素，而它们之间如何衔接和搭配让电脑这个系统运转起来，就是连接关系。我们往往容易看见整体，却容易忽视连接关系。
所有无法解决的问题，可能都是因为我们看不清。例如，普通的人观察一只手表，有洞察力的人可能会洞察几百个零件之间的“连接关系”。普通的人观察一次合作，有洞察力的人可能会洞察协议背后的利益分配、分析转嫁的“连接关系”。普通的人观察一个团队，有洞察力的人洞察团队里责、权、利的错综复杂的“连接关系”。
因此，我也认为，洞察力也是玄姐提到的这个业务需求至简抽象分析模型的关键。
模型2：哲学本质架构设计思维模型
玄姐认为，市面上有很多的架构，比如单体架构、SOA架构、微服务架构等等，他们的存在都有一个最本质的原因，那就是：“满足公司多业务场景的需求，最终达到公司层面降本增效的终极目的”。换句话说，只有做出的架构最终能够帮助公司实现降本增效，才是满足公司的业务场景的架构。
当然，这对于我们来说还是太抽象，于是玄姐给了细化的内容，也就是在做架构设计的时候，有一些最基本的定律。如果我们能够一层一层的抽象和分析，将架构设计映射到这些定律，那么就具备了这些架构设计的思维模型。
一种思维模型是：CAP架构设计思维模型
CAP是三个英文单词的首字母，分别是consistency、availability、partition tolerance。即强一致性、可用性、网络分区容忍性。CAP定律说的是，分布式系统三者只能同时满足二者，强一致性、可用性、网络分区容忍性三者同时满足的情况不存在。
如果我们能够结合业务场景，将CAP模型用起来，那么我们就能够掌握这个思维模型，就会离本质又进一步。否则，我们仅仅是掌握了CAP定律，而不知道怎么去应用。
另一种思维模型是：BASE架构设计思维模型
BASE是对CAP中一致性和可用性权衡的结果，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。在很多情况下，我们都是没办法用CAP定律来进行映射的，但是可以通过映射到BASE的思维模型来去做。这时候能不能把它映射到BASE模型上去做，也是很重要的。
玄姐也给出了一个例子，以设计分布式锁为例聊了一下存储模型的选择。一般情况下，分布式锁是一个CP模型，我们要求你的锁不能重复。但是，难道分布式锁的实现永远是CP模型吗，有没有一些场景，AP模型也是可以的。当然，只要涉及到金融相关的，比如说，我的交易，我的支付，我的转账，要求一定是CP模型。但是，当涉及到社交相关的，比如说，我发一个消息给朋友，本来消息发重复了以后应该过滤掉，但是它没有过滤掉，朋友收到我两条重复的消息，比如说今天晚上有空一起吃饭吗，本来他不想回我，当他发现这个消息发了两遍，他觉得我的邀请非常诚恳，他就答应我了。在这种场景下是可以用AP模型的。所以分布式锁也要根据场景折中，一定要把架构设计映射到CAP定律，到底采用一个什么样的模型来打造会比较合适，是非常重要的一个方向。有了这样的思维模型之后，再去设计分布式锁就会比较明晰。在存储模型的选择上，如果是一个AP模型，可以用Redis来做。如果是一个CP模型，则可以用etcd来做。有了最底层的架构设计之道，再去做其他场景也是很容易迁移复用的。
玄姐说：一切脱离业务场景谈架构都是耍流氓！
模型3：根据场景Balance架构设计思维模型
玄姐认为，我们需要根据实际的业务场景来合理地设计系统架构，这个业务场景，包括了项目时间、团队研发能力、团队运维能力等。但是，最重要的还是要根据场景去折中或者平衡的这样的一种能力，其实也是一种重要的思维模型。
比如，有些人在大厂经历了许多磨练，具备了一定的架构设计能力，但当他去一个小厂或者一个创业公司的时候，再根据大厂的业务来设计架构的时候，他其实不一定能够设计出一个适合于当前业务的架构。因为，他没有场景折中能力，只能依葫芦画瓢，但是画出来的不一定是最优雅的。
将场景折中能力进一步细化，就会得到“合适”架构设计思维模型。换句话说，在大厂我们可以用这样的分布式架构，但是去了小厂，则不一定要继续设计一个分布式架构，这时对于初创期的小厂，可能一个单体架构会是一个比较好的起点方向。
什么叫做合适，可能还是比较抽象，对它进一步拆解，就会得到适度超前架构设计思维模型。换句话说，我们设计的架构应该是能够满足一定时间内业务的发展的，那么多长的时间算适度？玄姐认为半年到一年的时间段比较符合适度超前的。
看到这里，我回顾了一下我所在公司的架构设计，基本也是朝着适度超前的原则来设计的，我们基本也是朝着满足未来半年内的需求来约定的。
学习小结
跟玄姐学习了思维模型，这其实是一种以不变应万变的设计能力，不变的是架构设计的思维模型，万变的则是各种业务场景。架构设计的终极之道，也是玄姐提到的哲学本质就是降本增效，我们所有的设计其最终目的都是希望公司能够降低成本提高效益。
参考资料
孙玄，《架构师的架构设计思维模型》
findyi，《人与人的差异在于认知》
刘润，《商业洞察力30讲》
