5.9软件架构流程之一 识别复杂度

date	comments	categories	tags	permalink	title
2020/3/16	true	软件架构	架构 复杂度	5.9	软件架构的流程之一 识别复杂度

前面说过架构设计的本质，目的是为了解决软件系统的复杂性，所以在我们设计架之初，首先就要分析系统的复杂性来源。只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向，否则如果对系统的复杂性判断错误，即使后续的架构设计方案再高明再先进，都是南辕北辙，做的越好，错的越多越离谱。

架构的复杂度主要来源于高性能，高可用，高扩展等几个方面，但是在架构师做判断的时候，不能够生搬硬套，认为任何时候架构都必须同时满足各方面的要求，实际上大部分场景下，复杂度的主要来源都只是其中的一个，少数情况下才包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误，哪怕真的认为要同时满足这三方面的要求，也必须要进行优先级的排序。

例如这个案例

之前提到过的“亿级用户平台”失败的案例，设计对标腾讯的 QQ，按照腾讯 QQ 的用户量级和功能复杂度进行设计，高性能、高可用、可扩展、安全等技术一应俱全，一开始就设计出了 40 多个子系统，然后投入大量人力开发了将近 1 年时间才跌跌撞撞地正式上线。上线后发现之前的过度设计完全是多此一举，而且带来很多问题：

• 系统复杂无比，运维效率低下，每次业务版本升级都需要十几个子系统同步升级，操作步骤复杂，容易出错，出错后回滚还可能带来二次问题。
• 每次版本开发和升级都需要十几个子系统配合，开发效率低下。
• 子系统数量太多，关系复杂，小问题不断，而且出问题后定位困难。
• 开始设计的号称 TPS 50000/ 秒的系统，实际 TPS 连 500 都不到。

由于业务没有发展，最初的设计人员陆续离开，后来接手的团队，无奈又花了 2 年时间将系统重构，合并很多子系统，将原来 40 多个子系统合并成不到 20 个子系统，整个系统才逐步稳定下来。

假如说你运气真的不好，接手了一个每方面复杂度都存在问题的系统，那么应该怎么办呢？答案是一个个来解决，不要幻想一次架构就解决所有的问题，例如刚刚提到的要对标腾讯QQ的案例！后来接手的团队其实面临几个主要的问题，系统稳定性不高，经常出现莫名的小问题，系统子系统数量太多，系统关系复杂，开发效率低，不支持异地多活机房解决的故障会导致业务整体不可用，如果同时要解决这些问题，那可能面对许多的困境:

• 要做的事情太多，感觉无从下手
• 设计与方案本身太复杂，落地时间遥遥无期
• 同一个方案要解决不同的复杂性，有的设计点是相互矛盾的，比如要提升系统可用性，就需要将数据及时存储到硬盘上，而硬盘刷盘反过来又会影响系统性能。

因此正确的做法是将主要的复杂的问题列出来，然后根据业务技术团队等综合情况进行排序，优先解决当前面临的最主要的复杂的问题。上面的案例中接受团队就优先选择了将子系统的数量降下来，后来发现子系统数量降下来之后,不但开发效率提升了，连原来经常发生的小问题都基本消失了，于是团队在在这个基础上做了异地多活方案，也取得了非常好的效果。

当然了，按照复杂度优先级来解决问题，有可能存在着一个让人担忧的问题，就是解决后续的问题的时候，有可能和前面已经解决的复杂的问题冲突，这时候是否要推到前面的解决方案呢？其实这个担忧理论上成立，但现实中是不太可能出现的，因为软件系统有非常强的可塑性和易变性，对于同一个复杂的问题，可以有很多个不同的解决方案，总是可以从中挑出综合性价比最高的方案。

哪怕架构是最终决定要推倒重来，这个新的方案也必须能够同时解决已经被解决的复杂的问题，一般来说能够达到这种理想状态的方案，基本都是依靠新技术来引入的，比如说hadoop能够将高可用、高性能、大容量三个大数据处理的复杂问题同时解决。

识别复杂度对架构师来说是一项挑战，因为原始的需求中并没有哪个地方会明确的说明复杂度在哪里票价格是在理解需求的基础上进行分析，酒精的价格可能一看就知道复杂度大概在哪，如果经验不足那该怎么办呢？答案是用排查法。

识别复杂度实战

假设我们现在一个创业公司名称叫做 "前浪微博"。假如这个时候业务发展非常的快，系统也越来越多，系统间协作的效率越来越低，比如说

• 用户发一条微博后，微博此系统需要通知审核子系统进行审核，然后通知统计子系统进行统计，再通知广告子系统进行广告预测。接着通知消息子系统进行消息推送,一条微博有十几个通知，目前都是系统经通过接口调用的，每一个要通知的系统，微博子系统就要设计接口进行测试，效率很低，问题定位很麻烦，经常和其他子系统的技术人员产生分歧，微博子系统的开发人员不胜其烦。
• 用户等级达到vIp后，等级子系统要通知福利子系统进行奖品发放，要通知客服子系统安排安排专属服务人员,要通知商品子系统进行商品打折处理等等，子系统的开发人员也是不胜其烦的。

新来的架构师在处理这些问题时，结合自己的经验，敏锐地发现了这些问题背后的根源在于,架构上各业务子系统的耦合,而消息队列系统正好可以完成子系统的耦合，于是提议要引入消息队列系统，经过一分析二讨论，三开会四汇报5审批，等一系列操作后，消息对接系统终于立项了，其他的背景信息还有

• 中间间堂内规模不大，大约6个人左右
• 中间建团队熟悉加法语言，但有一个同事新来的c加加水平很牛
• 开发平台是Linux数据库是mysql
• 目前整个业务系统的单机房部署,没有双机房

针对微博的消息队列系统,采用排查法来分析复杂度，具体的分析过程如下。

一 这个消息队列是否需要高性能

我们假设前浪微博系统用户每天发送1000万条微博，那么微博子系统，一天会产生1000万条消息，我们在假设平均一条消息有10个子系统读取，那么其他子系统读取的消息大约是1亿次。

1000万和1亿看起来很吓人，但对于架构师来说，关注的不是一天的数据，而是一秒的数据,即TPS和QPS，我们将数据按照秒来计算，一天内平均每秒写入消息数为 115 条，每秒读取的消息数是 1150 条；再考虑到每天的读写并不是完全平均的，设计的目标应该是以峰值来计算的峰值，一般取平均值的三倍，那么消息推列的TPS 345，QPS是3450。这个量级的数据，意味着并不要求高性能。

虽然根据当前业务规模计算的性能要求并不高，但业务会增长，因此系统设计需要考虑一定的性能余量，由于现在的基数降低，为了预留一定的系统容量，应对后续业务的发展，我们将设计目标设定为峰值的4倍，因此最终的系统要求是tps为1380，QPS为13,800！此时的TPS并不高，但是QPS为13,800已经比较高了，因此高性能读取是复杂度之一，注意这里的设计目标设定为峰值的4倍，是根据业务发展速度来预估的，不是固定为4倍，不同的业务可以是两倍也可能8倍，但一般不要设定在10倍以上，更不要一上来就按照100倍预估。

二 这个消息队列是否需要高可用性

对于微博此系统来说，如果消息丢了导致没有审核，然后触犯了国家的法律法规则是非常严重的事情，对于等级子系统来说，如果用户达到相应等级以后，系统没有给他奖品和专属服务，则VIP用户会很不满意，导致用户流失，从而损失收入，虽然也比较关键，但没有审核的系统丢消息那么严重，综合来看消息队列需要高可用性，包括消息写入消息存储消息读取都需要保证高可用性。

三 这个消息队列是否需要高可扩展性

消息队列的功能很明确，基本无需扩展，因此可扩展性，不是这个消息队列的复杂度关键。

为了方便理解，这里就只排查了高性能和高可用可扩展性三个复杂度，在实际应用中不同的公司或者团队可能还有一些其他方面的复杂的分析，例如金融系统可能需要考虑安全性，有的公司需要考虑成本等.

综合下来，消息队列的复杂性主要体现在这几个方面，高性能消息读取高可用消息写入高可用消息存储，高可用消息读取前浪微博的消息，队列设计才刚完成第1步，下一篇文章再来分析第二步。