跟玄姐学习三种架构设计思维模型

之前我在公众号发过一次孙玄(人称:玄姐)会在阿里云开发者社区开一个五节课程的架构师成长之路直播课,我也学习了他的第一课《技术人的道与术》后做了学习整理笔记并分享成文。今天,和你分享我学习他的第四课《架构设计思维模型》做的学习笔记,会和你分享三个架构师需要具备的架构设计思维模型。

模型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讲》

 

posted @ 2020-08-21 21:56  EdisonZhou  阅读(99)  评论(0编辑  收藏