快速成为*架构师的内功修炼
查看直播——基于线上真实案例，详谈架构设计的哲学本质
一、*架构师具备的架构设计思维模型
第一个比较重要的思维模型是业务需求至简抽象分析思维模型。作为一个架构师，不能完全活在技术的世界里，一定是要解决一些问题的。这些问题就是你的需求。比如说，产品同学来了一个需求，你能不能去抽象分析出来这个需求背后，他真正的本质需求是什么。需求背后的本质是非常重要的。
如果你能把这个需求背后的本质做出来，这个需求在你看来已经是一个简单的需求，这个叫需求抽象，即业务需求至简抽象分析的思维模型。
第二个思维模型是掌握哲学本质架构设计思维模型。
在市面上有很多架构。比如说，我们的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，即没有了分布式。
刚才讲了，我们要具备CAP的架构设计思维模型。这个思维模型要通过例子去体现。
接下来我们看一个业务场景，交易商品库的锁定。比如说，一个用户加入我们的百万年薪课。限定一个人只能下单一次。要保证一个人下单一次，其实是有一个共享资源的问题。共享资源就是用户的UID。这时候需要对你的用户UID做一些串行化，让他串行化进行访问。如果用户UID被别人锁住了，你就不能再进行下单，你就不能消费，这是一个交易锁定。业务场景二和业务场景三如下图所示，分别是MQ消息去重和订单操作变更协同。
我们来分析一下这些业务场景的共性，它们背后其实都是有一些共享资源。
比如说，第一个防止用户重复下单，共享资源是用户UID。第二个消息驱动，假如是一个订单消息，共享资源就是订单的ID。第三个消息的协同，共享资源也是一个订单ID。
所以，本质上解决方式就是共享资源的一个互斥化，其实就是共享资源的一个串行化。而共享资源的串行化，其实就是一个锁的问题。但是，我们不能用本地锁，而要用分布式锁。分布式锁其实就是要解决资源在分布式环境下的一个串行的问题。
我们采用基于Redis的分布式锁实现方案，其原理是唯一线程串行处理。其实现方式如下图所示。浅层次来讲，存在锁时间不可控的问题。从更深的层次，我们要考虑业务场景的容忍度，一切脱离业务场景谈架构的行为都是不可取的。
回到整个架构设计哲学本质：分布式锁是CP模型，Redis集群是AP模型。
一般情况下，分布式锁是一个CP模型，我们要求你的锁不能重复。但是，在用Redis来实现这把锁的时候，会发现它其实是AP模型。很显然，你最后一定会遇到一些问题。
所以，你要具备CAP的架构设计思维模型的能力。有了思维模型，再去进一步分析它的深层次原因。大家可以想一个问题，难道分布式锁的实现永远是CP模型吗，有没有一些场景，AP模型也是可以的。当然，只要涉及到金融相关的，比如说，我的交易，我的支付，我的转账，要求一定是CP模型。
但是，当涉及到社交相关的，比如说，我发一个消息给朋友，本来消息发重复了以后应该过滤掉，但是它没有过滤掉，朋友收到我两条重复的消息，比如说今天晚上有空一起吃饭吗，本来他不想回我，当他发现这个消息发了两遍，他觉得我的邀请非常诚恳，他就答应我了。在这种场景下是可以用AP模型的。所以分布式锁也要根据场景折中，一定要把你的架构设计映射到CAP定律，到底采用一个什么样的模型来打造会比较合适，是非常重要的一个方向。
一旦有了这种思维模型，再去设计分布式锁就比较简单。在存储模型的选择上，如果是一个AP模型，可以用redis来做。如果是一个CP模型，推荐大家用etcd来做。有了最底层的架构设计之道，再去做其他场景也是很容易的。
关键词：*架构师，架构设计，思维模型，分布式锁，CAP定律