顶级架构师的架构设计思维模型——阿里云 MVP孙玄-阿里云开发者社区

开发者社区> 阿里云MVP> 正文

顶级架构师的架构设计思维模型——阿里云 MVP孙玄

简介: 阿里云MVP,奈学教育CEO孙玄为大家带来基于线上真实案例驱动,谈顶级架构师的架构设计思维模型的介绍。内容包括顶级架构师具备的架构设计思维模型,分布式锁线上真实案例架构设计哲学本质剖析两部分。

快速成为顶级架构师的内功修炼

查看直播——基于线上真实案例,详谈架构设计的哲学本质

一、顶级架构师具备的架构设计思维模型

第一个比较重要的思维模型是业务需求至简抽象分析思维模型。作为一个架构师,不能完全活在技术的世界里,一定是要解决一些问题的。这些问题就是你的需求。比如说,产品同学来了一个需求,你能不能去抽象分析出来这个需求背后,他真正的本质需求是什么。需求背后的本质是非常重要的。

如果你能把这个需求背后的本质做出来,这个需求在你看来已经是一个简单的需求,这个叫需求抽象,即业务需求至简抽象分析的思维模型。

第二个思维模型是掌握哲学本质架构设计思维模型。

在市面上有很多架构。比如说,我们的SOA架构,微服务架构,等等。有这么多架构,他们存在的一个最本质的原因是什么呢。

我相信这么多架构存在,它只满足一个需求,那就是满足你的公司多业务场景的需求,最终达到公司层面要降本增效这样一个终极目的。也就是说,我们在做一个架构设计的时候,要选择合理的架构。比如说,微服务架构对你来说是合理的,只有掌握哲学本质,你做出的架构才是降本增效的,才是满足公司的业务场景的。

当然,掌握哲学本质架构设计思维模型有一些抽象,我们继续往下去剖析。对哲学本质的思维模型进一步往下去细化,就会发现做架构设计的时候,有哪些最基本的定律。再往下细化,一种思维模型是CAP架构设计思维模型

CAP本身是一个定律,你能不能根据一些需求一层一层的抽象,一层一层的分析,最后把你的架构设计映射到一批定律。如果你能一步一步通过需求做抽象分析,然后对架构进行拆解,最后映射到CAP定律,那么你就具备了CAP的架构设计思维模型。否则,你仅仅是掌握了CAP定律,但是你不知道怎么去应用。思维模型是一种智慧,也就是说,你要结合业务,把CAP模型用起来。如果你能掌握这个思维模型,那么你离本质又进了一步。

另一种思维模型是BASE架构设计思维模型。BASE是对CAP中一致性和可用性权衡的结果,其核心思想是即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。在很多情况下,我们是没办法用CAP定律来进行映射的,但是可以通过映射到BASE的思维模型来去做。这时候你能不能把它映射到BASE模型上去做,也是很重要的。

第三个架构思维模型是根据场景Balance架构设计思维模型

这个场景其实很多,比如说你的业务场景,你的老板给你的项目的一个时间场景,你的研发能力,你的运维能力都是场景。当然,最重要的一定是你的业务场景。根据场景去折中或者平衡的这样一种能力,其实是非常重要的一种思维模型。比如说,你具备一些大厂的架构设计的能力,当你去一个小厂,或者当你去一个创业公司,你再根据它的业务来设计架构的时候,不一定能够设计出适合当前业务的一个架构。因为你的场景折中的能力并没有形成,你只能依着葫芦去画瓢,但是瓢画出来不一定是最优雅的。继续往下细化,进一步拆解,得到“合适”架构设计思维模型。也就是说,在大厂你可以用这样的分布式架构,但是去了一个小厂以后,不一定要用分布式架构,可能用一个单体架构是一个比较好的方向。这是一个非常重要的思维模型。什么叫合适,还是比较抽象。进一步的拆解,得到适度超前架构设计思维模型。也就是说,你给出的架构能满足一定时间内业务的发展,比如说,满足半年到一年的发展需求,这样一个架构设计思维模型就是适度超前的。

具备了思维模型以后,我希望能够掌握架构设计的能力,具备以不变应万变的架构设计能力。这个不变就是架构设计的思维模型,这个万变就是各种场景。有了这种能力,你就一定可以给出优雅的架构设计方案

如果你能够把业务需求至简抽象,你能够得到问题的本质,你能给出合适的架构方案,那么你就会达到架构设计的终极之道,即架构设计哲学本质:降本增效。最终目的就是让你的公司能够降本增效,我们也必须按照这样的方式进行设计和实践。

二、分布式锁线上真实案例架构设计哲学本质剖析

首先我们讲一下CAP定律。2000年,Eric Brewer教授提出CAP猜想,2年后,被Seth Gilbert和Nancy Lynch从理论上证明。CAP是三个英文单词的首字母,分别是consistency、availability、partition tolerance。即强一致性、可用性、网络分区容忍性

CAP定律说的是,分布式系统三者同时满足二者,强一致性、可用性、网络分区容忍性三者同时满足的情况不存在。

举一个简单的例子。以数据库更新为例,C、A、P的具体含义如下图所示。假设我们有两个机房。机房一会通过数据访问层访问MySQL的主库,同时MySQL的主库会把数据同步到机房二的数据库的从库。机房二的数据访问层可以对数据进行读取。正常情况下,网络是通的,通过数据访问层写主库,然后同步到从库。

如果网络不通了,这时候数据同步不了,你这个写请求就返回不了,你的A就不可用。所以在这种情况下,C、A、P不能同时满足。我们只能选择CP模型或者AP模型。实际过程中AC模型意义不大。因为没有P,即没有了分布式。

image.png

刚才讲了,我们要具备CAP的架构设计思维模型。这个思维模型要通过例子去体现。

接下来我们看一个业务场景,交易商品库的锁定。比如说,一个用户加入我们的百万年薪课。限定一个人只能下单一次。要保证一个人下单一次,其实是有一个共享资源的问题。共享资源就是用户的UID。这时候需要对你的用户UID做一些串行化,让他串行化进行访问。如果用户UID被别人锁住了,你就不能再进行下单,你就不能消费,这是一个交易锁定。业务场景二和业务场景三如下图所示,分别是MQ消息去重和订单操作变更协同。

image.png

我们来分析一下这些业务场景的共性,它们背后其实都是有一些共享资源。

比如说,第一个防止用户重复下单,共享资源是用户UID。第二个消息驱动,假如是一个订单消息,共享资源就是订单的ID。第三个消息的协同,共享资源也是一个订单ID。

所以,本质上解决方式就是共享资源的一个互斥化,其实就是共享资源的一个串行化。而共享资源的串行化,其实就是一个锁的问题。但是,我们不能用本地锁,而要用分布式锁。分布式锁其实就是要解决资源在分布式环境下的一个串行的问题。

image.png

我们采用基于Redis的分布式锁实现方案,其原理是唯一线程串行处理。其实现方式如下图所示。浅层次来讲,存在锁时间不可控的问题。从更深的层次,我们要考虑业务场景的容忍度,一切脱离业务场景谈架构的行为都是不可取的。

image.png

回到整个架构设计哲学本质:分布式锁是CP模型,Redis集群是AP模型。

一般情况下,分布式锁是一个CP模型,我们要求你的锁不能重复。但是,在用Redis来实现这把锁的时候,会发现它其实是AP模型。很显然,你最后一定会遇到一些问题。

所以,你要具备CAP的架构设计思维模型的能力。有了思维模型,再去进一步分析它的深层次原因。大家可以想一个问题,难道分布式锁的实现永远是CP模型吗,有没有一些场景,AP模型也是可以的。当然,只要涉及到金融相关的,比如说,我的交易,我的支付,我的转账,要求一定是CP模型。

但是,当涉及到社交相关的,比如说,我发一个消息给朋友,本来消息发重复了以后应该过滤掉,但是它没有过滤掉,朋友收到我两条重复的消息,比如说今天晚上有空一起吃饭吗,本来他不想回我,当他发现这个消息发了两遍,他觉得我的邀请非常诚恳,他就答应我了。在这种场景下是可以用AP模型的。所以分布式锁也要根据场景折中,一定要把你的架构设计映射到CAP定律,到底采用一个什么样的模型来打造会比较合适,是非常重要的一个方向。

一旦有了这种思维模型,再去设计分布式锁就比较简单。在存储模型的选择上,如果是一个AP模型,可以用redis来做。如果是一个CP模型,推荐大家用etcd来做。有了最底层的架构设计之道,再去做其他场景也是很容易的。

image.png
关键词:顶级架构师,架构设计,思维模型,分布式锁,CAP定律

快速成为顶级架构师的内功修炼

查看直播——基于线上真实案例,详谈架构设计的哲学本质

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里云最有价值专家,是专注于帮助他人充分了解和使用阿里云技术的意见领袖。

官方博客
官网链接
精彩专题