。

对于按照复杂度优先级解决的方式#xff0c;存在一个普遍的担忧#xff1a;如果按照优先级来解决复杂度#xff0c;可…一、识别复杂度

将主要的复杂度问题列出来然后根据业务、技术、团队等综合情况进行排序优先解决当前面临的最主要的复杂度问题。

对于按照复杂度优先级解决的方式存在一个普遍的担忧如果按照优先级来解决复杂度可能会出现解决了优先级排在前面的复杂度后解决后续复杂度的方案需要将已经落地的方案推倒重来。

这个担忧理论上是可能的但现实中几乎是不可能出现的原因在于软件系统的可塑性和易变性。

对于同一个复杂度问题软件系统的方案可以有多个总是可以挑出综合来看性价比最高的方案。

二、设计备选方案

架构师的工作并不神秘成熟的架构师需要对已经存在的技术非常熟悉对已经经过验证的架构模式烂熟于心然后根据自己对业务的理解挑选合适的架构模式进行组合再对组合后的方案进行修改和调整。

新技术都是在现有技术的基础上发展起来的现有技术又来源于先前的技术。

将技术进行功能性分组可以大大简化设计过程这是技术“模块化”的首要原因。

技术的“组合”和“递归”特征将彻底改变我们对技术本质的认识。

根据架构设计原则中“合适原则”和“简单原则“的要求挑选合适自己业务、团队、技术能力的方案才是好方案否则要么浪费大量资源开发了无用的系统例如之前提过的“亿级用户平台”的案例设计了

TPS

心里评估过于简单可能没有想得全面只是因为某一个缺点就把某个方案给否决了而实际上没有哪个方案是完美的某个地方有缺点的方案可能是综合来看最好的方案。

架构师再怎么牛经验知识和技能也有局限有可能某个评估的标准或者经验是不正确的或者是老的经验不适合新的情况甚至有的评估标准是架构师自己原来就理解错了。

单一方案设计会出现过度辩护的情况即架构评审时针对方案存在的问题和疑问架构师会竭尽全力去为自己的设计进行辩护经验不足的设计人员可能会强词夺理。

因此架构师需要设计多个备选方案但方案的数量可以说是无穷无尽的架构师也不可能穷举所有方案那合理的做法应该是什么样的呢

备选方案的差异要比较明显。

例如主备方案和集群方案差异就很明显或者同样是主备方案用

ZooKeeper

分钟这就不是架构上的差异而是细节上的差异了不适合做成两个方案。

备选方案的技术不要只局限于已经熟悉的技术。

设计架构时架构师需要将视野放宽考虑更多可能性。

很多架构师或者设计师积累了一些成功的经验出于快速完成任务和降低风险的目的可能自觉或者不自觉地倾向于使用自己已经熟悉的技术对于新的技术有一种不放心的感觉。

就像那句俗语说的“如果你手里有一把锤子所有的问题在你看来都是钉子”。

例如架构师对

MySQL

有的架构师或者设计师在写备选方案时错误地将备选方案等同于最终的方案每个备选方案都写得很细。

这样做的弊端显而易见

将注意力集中到细节中忽略了整体的技术设计导致备选方案数量不够或者差异不大。

评审的时候其他人会被很多细节给绕进去评审效果很差。

例如评审的时候针对某个定时器应该是

正确的做法是备选阶段关注的是技术选型而不是技术细节技术选型的差异要比较明显。

例如采用

ZooKeeper

/service/node/master另一个方案的节点设计是

/company/service/master这两个方案并无明显差异无须在备选方案设计阶段作为两个不同的备选方案至于节点路径究竟如何设计只要在最终的方案中挑选一个进行细化即可。

三、评估和选择备选方案

上在完成备选方案设计后如何挑选出最终的方案也是一个很大的挑战主要原因有

评价标准主观性比较强比如设计师说

方案复杂但另外一个设计师可能会认为差不多因为比较难将“复杂”一词进行量化

正因为选择备选方案存在这些困难所以实践中很多设计师或者架构师就采取了下面几种错误的指导思想

最简派设计师挑选一个看起来最简单的方案。

例如我们要做全文搜索功能方案

MySQL方案

最牛派最牛派的做法和最简派正好相反设计师会倾向于挑选技术上看起来最牛的方案。

例如性能最高的、可用性最好的、功能最强大的或者淘宝用的、微信开源的、Google

最熟派设计师基于自己的过往经验挑选自己最熟悉的方案。

我以编程语言为例假如设计师曾经是一个

Python

领导派领导派就更加聪明了列出备选方案设计师自己拿捏不定然后就让领导来定夺反正最后方案选的对那是领导厉害方案选的不对怎么办那也是领导“背锅”。

正确的做法是列出我们需要关注的质量属性点然后分别从这些质量属性的维度去评估每个方案再综合挑选适合当时情况的最优方案。

常见的方案质量属性点有性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。

在评估这些质量属性时需要遵循架构设计原则

1“合适原则”和原则

2“简单原则”避免贪大求全基本上某个质量属性能够满足一定时期内业务发展就可以了。

按优先级选择即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素将质量属性按照优先级排序首先挑选满足第一优先级的如果方案都满足那就再看第二优先级……以此类推。

那会不会出现两个或者多个方案每个质量属性的优缺点都一样的情况呢理论上是可能的但实际上是不可能的。

在做备选方案设计时不同的备选方案之间的差异要比较明显差异明显的备选方案不可能所有的优缺点都是一样的。

如

2原因有

的主要原因是可运维性因为再成熟的系统上线后都可能出问题如果出问题无法快速解决则无法满足业务的需求并且

Kafka

的主要设计目标是高性能日志传输而我们的消息队列设计的主要目标是业务消息的可靠传输。

排除备选方案

人还有其他中间件系统需要开发和维护无法支撑自研存储系统参考架构设计原则

备选方案

的优点就是复杂度不高也可以很好地融入现有运维体系可靠性也有保障。

针对备选方案

台服务器但实际上备机包括服务器和数据库主要用作备份可以和其他系统并行部署在同一台机器上。

备选方案

的第三个缺点是技术上看起来并不很优越但我们的设计目的不是为了证明自己参考架构设计原则

四、详细方案设计

详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。

这种情况可以通过下面方式有效地避免

架构师不但要进行备选方案设计和选型还需要对备选方案的关键细节有较深入的理解。

例如架构师选择了

Elasticsearch

的设计原理有深入的理解比如索引、副本、集群等技术点而不能道听途说

Elasticsearch

很牛所以选择它更不能成为把“细节我们不讨论”这句话挂在嘴边的“PPT

通过分步骤、分阶段、分系统等方式尽量降低方案复杂度方案本身的复杂度越高某个细节推翻整个方案的可能性就越高适当降低复杂性可以减少这种风险。

如果方案本身就很复杂那就采取设计团队的方式来进行设计博采众长汇集大家的智慧和经验防止只有

1~2