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