作者： 高福来

引言

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

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

一、系统架构的本质目的

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

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

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

二、系统架构的难点

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

2.1 技术上的难点

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

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

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

2.2 业务上的难点

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

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

2.3 项目管理的难点

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

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

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

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

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

3.1 写作的过程

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

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

3.2 提炼写作的要点

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

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

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

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

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

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

四、应对系统架构的方法

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

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

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