作者: 高福来

引言

在本系列的 第一篇 文章中已经给出系统架构的公式定义:系统架构 = 要素 + 连接 + 解决特定的问题,本篇文章重点讨论应对系统架构的方法。

如今,系统架构在业内还没有定型的固定方法,一般会讲:需求分析、系统分析与设计、UML、领域建模、设计模式、软件工程等,笔者不打算这样讲,这样下来会有厚厚一本书,希望从简洁、可落地实践的角度去阐述系统架构,后面的文章再给出每种架构具体可实践操作的方法。

一、系统架构的本质目的

我们已经知道系统架构是什么,有必要讲一下系统架构的目的,即为什么要进行系统架构。对于简单的系统而言,可能没有什么所谓的系统架构,这里的 " 没有 " 可能对我们来讲是常识,如简单的系统分层。系统架构的本质目的从公式定义中就可以看出: 解决特定的问题,这个特定的问题有技术上的问题、业务上的问题、项目管理上的问题。

还有一个问题不知道开发者是否注意到:怎么知道自己的架构设计是对的?这个问题很尖锐,架构设计具备严谨的逻辑性,从逻辑上讲是对的,实现起来基本上八九不离十,再根据实际使用情况做出调整。所以,系统架构从本质上讲具备逻辑性,虽然还没有真正实践,但从架构方案上能看得出是否合理、正确。

结论一:系统架构的本质目的就是解决问题和具备逻辑性。

二、系统架构的难点

系统架构并不是任何初学者都可以一学就会的概念,它具备一定要求,所以这里说的难点换个角度就是要掌握的能力。

2.1 技术上的难点

技术上的难点对于开发来讲比较好理解,在有些场景下,技术会成为架构的难点之一,如笔者之前在阿里店铺团队,双 11 高达十几万的 QPS,如果处理不当,可能就会导致访问的店铺页面打不开。所以,对于高并发场景,我们面临很多挑战,以下列举常见的技术难点:

  • 高并发场景:有限的资源应对大量请求。
  • 高可用场景:即使在极端条件下,强调系统的可用性。
  • 高扩展场景:如何应对变化的问题,以最少的代价支撑业务发展。
  • 分布式一致性场景:一致性问题在分布式场景下经常遇到,选用哪种技术方案要结合当前的业务、条件来选择。
  • 高性能场景:快速地处理请求。

技术上可以有意识地在平时去总结、练习,每种问题都应该有一套立体化的解决方法而不是一个散点去应对,如高并发场景,有些同学立马说用缓存、用消息队列等,这些只是手段,如果从本质问题出发,在每个环节上思考如何去做,这样就会提出系统性的解决方案,这一点会在后续文章中展开说明。

2.2 业务上的难点

有些业务是非常复杂的,不是简单的 CRUD,涉及到的链路非常长、涉及到的业务关联方也非常多,很有可能一个系统的代码行数超过 100 万,还包括很多历史逻辑在里面,这个在新业务中出现的概率较小,一般是大型系统并且你是后面加入团队的时候会遇到。尤其是用户量大、涉及到交易业务的系统,错一点就会造成巨大资损。作为一个新人,加入这样的团队面临的挑战会比较大,如果没有文档,只能靠自己去问、去看、去 debug、去踩坑。

在业务架构的基础上,笔者提出 业务能力地图 的观点,如何让一个新人以最少的成本熟悉业务系统,除了业务系统设计得非常好,有详细的文档可参考外,还要有可视化的能力地图,从一个业务场景出发,中间涉及到的调用逻辑全部通过可视化界面展示出来,一个新人就可以很清晰地知道整个业务流程如何运转,先从宏观上理解产品、业务运转,再去看代码要轻松得多。

2.3 项目管理的难点

一个大型系统设计的业务方比较多,如果系统架构方案已经产出,剩下的就是落地执行,项目管理也有可能是我们的一个难点,如何协调资源、处理冲突、关键项目里程碑、问题跟踪和解决、上线灰度策略、业务监控…这些在系统架构设计时都要考虑到,并且在执行的过程中要有反馈。

一个项目如果没有人管理延期的风险会很大,其实大部分开发不善长做管理、沟通等事情,在一个组织里,不同的人、不同的事形成一个较复杂的环境,所以也有人说管理是一门艺术。

上面着重从技术、业务、项目三个层面讲解系统架构的难点,这些难点就是我们后面要解决的问题,反过来就是我们应该具备的基础。

三、换个思维看系统架构的过程

换个思维学领域建模方法和实践 一文中,通过语文的阅读理解来类比领域建模的过程,有些读者反馈这种方式较好,通俗易懂,想起来好像还是那么一回事。笔者一直推崇的理念是大道至简,通过过往经验类比复杂的问题,有一个铺垫会降低学习的复杂度。

3.1 写作的过程

在这里依然用一个大家都熟知的经验来类比系统架构。我们从小都写作文,写作文的步骤是什么呢?

  • 审题:根据要求写作。
  • 谋篇布局:知道要写什么之后,就思考整体文章的结构是什么 (这个最关键,手法不同,文章的结构就不同,如总分总、设悬念、先抑后扬等),分几段来写,每段的内容是什么,段与段的链接怎样。
  • 素材选择:为了支撑表达我们的思想,素材有多个,如何选择最贴切的素材也是至关重要的。
  • 写作:最后成文。

3.2 提炼写作的要点

所以到这里,不知道你发现了什么没,最关键的是什么?就是文章结构,这里的结构就体现出不同的逻辑,不同的人看后会有不同的感觉,有的文章读后为什么能让你拍案叫绝,就是他的行文思路非常好、剧情引人入胜。

可以换个角度来说: 学好系统架构就如同写出一篇妙笔生花的文章出来。再来看如何写出一篇妙笔生花的文章出来的过程,我们大体在学生时代做了两件主要的事:

  • 词汇语句的积累:积累了大量的词汇和经典语句,我们是从出生就开始积累。
  • 文章结构:我们学习了大量的文章,分析文章的结构就是为了让我们学习这种结构。

至此,写作的核心要点就两个: 词汇语句和文章结构。那么类比到架构设计,其实已经快呼出之出了,先等一下,我们对这两个点再抽象一下。 词汇语句抽象了要素,文章结构抽象成模式。再来看系统架构,它的核心点也是上面两种:

  • 要素:解决问题的点和具体手段,如技术架构中的缓存、消息队列等。
  • 模式:就是最终呈现的结构,常见的有分层架构模式、管道模式、代理模式、事件模式等。

通过写作类比,应对系统架构的方法已经初步成型,接下来再细细道来。

四、应对系统架构的方法

本部分应该是最重要的,但经过前面的铺垫,现在显得并不是特别重要,因为不同的人看到这里,心里的想法肯定不一样。

应对系统架构的方法: 系统性思考、分解、抽象、模式

  • 系统性思考:我们考虑的目标是系统,不是单一的点,所以要系统性思考。