12分钟阅读.

一、引子

作为程序员的我们近期目标可能是架构师，那么如何快速成长为一名架构师呢？其实是有一些方**的，但架构设计也不像程序设计一样有固定的学习体系。接下来从什么是架构设计、架构设计原则、架构设计思维、架构设计方**四个方面来进行展开，架构设计除了掌握技术框架、技术组件、技术原理性知识外，也需要系统性掌握架构基础知识，以架构设计原则、设计思维为指导，掌握架构设计方**，通过不断的优化和迭代，来实现更优秀的架构设计。

二、什么是架构设计（what）

2.1 架构定义

百度百科：架构又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。

从定义中我们提炼出几个关键字：组件、结构、连接。

组件：也可以称为软件元素或者是架构要素。可以是子系统、模块、应用服务，取决于不同角度来看待。

结构：是架构之后的产出物，不同的软件系统会有不同结构，这些结构为解决不同场景而设计。

连接：实现架构组件之间的连接。连接关系可以是JVM内部调用、可以是组件之间、可以是跨应用的分布式调用、也可以是与外系统接口集成调用。

总结：架构是将软件组件按照一定结构连接起来的 。

软件组件怎么来找、用什么结构来连接、如何来连接，这些都是软件复杂度所带来的问题。

架构设计本质就是解决软件复杂度带来的问题 ，最终实现降本增效。软件复杂度表现形式有很多种，比如业务复杂度、性能复杂度、可用性复杂度、可扩展性复杂度、安全复杂度等；任何一个系统都有它侧重解决的复杂度问题，理解每个架构方案背后需要真正解决的是软件复杂度的什么问题，是评判一个架构设计目的性的关键因素，这也是做架构设计中常提的系统约束条件 。

业务复杂度体现的是如何来拆解业务，找到合适的软件元素和组件，按合适结构进行连接；性能复杂度体现的是找到软件元素，进行合适连接形成一定结构，达到高性能要求。比如说一个大型ERP系统，属于业务复杂度高的系统，你该如何去拆分它，拆分成一个个独立完备、具有明确业务边界的组件，这是做架构设计需要思考的。再比方说做一个秒杀系统，系统复杂度要求就是性能复杂度，怎么能扛住秒杀的洪峰，这是性能复杂度需要解决的问题。

2.2 软件开发和架构设计的区别

软件开发 更多是面向确定性逻辑问题，依据自身对需求的理解进行实现，实现方式较为固定，流程化开发完成需求功能，实现最终目标。

比方说实现订单接收的能力，分几步：参数验证、商品查询、库存预占、生成订单、扣减库存、修改订单状态、状态回传，业务逻辑较为固定，如果再加上编码规范以及框架约束，除了数据模型以及编码设计之外，其他方面涉及较少。

架构设计 更多是面向不确定性问题，怎么将系统拆分成组件，怎么去识别是不是组件、组件和组件之间怎么进行连接，这些都是有很多种可能性的架构方案。在多种方案之间如何来决策需要一系列的原则来进行指导，最终选出最佳方案。

解决一个软件复杂度问题方案，有方案A、方案B，甚至有方案C ，应该用哪种，原因是什么，都是架构设计需要思考的问题。在多种方案之间如何来进行决策，如何判断自己选择的方案是合理的，当然决策能力也不是拍脑袋来决定的，它其实也需要一系列原则来进行指导，通过这些指导原则加上实际经验来决策最优方案。

三、架构设计原则

谈到架构设计不得不说三个基本原则，作为架构设计过程中的参考，更好帮忙去做分析、做决策、做支持。

3.1、适合原则

首先提到就是适合原则 ， 一切不按实际场景出发的架构设计都是在耍流氓。

比如你 想买个车子，买贵觉得性价比不高，买便宜了觉得开起来不舒适，你最终会挑一个适合现在经济能力范围内又比较舒适的车子，这就是合适原则。

1）、以当前业务需求和非功能性需求为目标，匹配业务发展所处阶段，合理利用资源发挥最大价值（买车子需要匹配当前经济状态）；

2）、需要结合实际场景，合适的系统架构 （我买车子只是为了代步，不能说我觉得跑车气派，我就买个跑车，这和业务实际场景不符合）；

3）、考虑业务近1到2年的发展规模。

还需要和当前的业务规模以及最近1-2年的发展规划相互匹配 （虽然我一次性付不起，但有稳定经济收入，我可以考虑贷款，分2年期。这样我既买到理想的车型，也不担心压力大）；新技术推出，势必是解决某一场景下的问题，但并不能解决所有问题，任何架构都要综合来看，结合合适原则综合选择。

3.2、简单原则

其次是 简单原则 ，大道至简，一切简单化，用最简单的解决方案来解决问题 。

KISS （Keep Simple and Stupid）原则是用户体验的最高境界，同样它适用于架构设计 ；简单是软件设计的目标，简单代码占用的时间少，产生的漏洞少，并且易于修改 、维护、扩展和重构；不要以为简单设计是没有技术含量，用简单设计处理复杂问题更需要优秀的架构设计能力；软件系统之所以会被说成复杂，体现在 结构复杂 以及 逻辑复杂 ，而一个复杂问题是由多个简单问题构成的，难的是如何拆解它，将它拆解为多个问题，逐个解决，把复杂逻辑拆分为一个个单一执行单元，单个执行单元代码量一定要尽可能少。逻辑复杂系统在内部实现所有逻辑功能，几乎会导致每个环节都有问题，它需要面对不断变化的需求，所有人维护同一套代码，整个开发、测试、上线流程变得异常繁重。

3.3、演化原则

最后是演化原则 ，只有变化是永恒不变的 ，优秀架构一定是以业务不断发展而不断演进而来；设计架构要满足当时业务需要 ，具有可扩展性和持续开发能力，能够应变后续架构升级和调整；要不断地在实际应用过程中迭代，保留优秀设计，修复有缺陷设计，改正错误设计，剔除无用设计，使架构逐渐完善，要将变化部分和不变部分区分开。可以看下《**从几百到千万级并发的十四次架构演进之路》。在数字化领域，技术和业务都可能处在快速的变化中，架构是需要通过目标架构的设想和差距分析等架构方法来处理当前和长远的关系。

四、架构设计思维

要想做好架构设计必须具备的架构设计思维，主要有以下三种思维：抽象思维；分治思维；复用思维。

4.1、抽象思维

架构是为了满足业务需求而存在，需要通常是一些文字性的描述、原型、UI设计图，这些最终都会变成代码让机器执行。我们必须先进行抽象，把需求变成计算机能识别的模型。

例如，抽象出各个用户、订单、内容等模型，划清各个角色的责任以及对象交互的方式，隐藏很多无关紧要的细节。

4.2、分治思维

对复杂的系统分而治之，分解为小的、简单的部分。我们通常所说的通过增加一层来解决问题即是分治的一种体现，分类分层是把复杂问题简单化，化整为零，分别进行处理。例如针对高并发场景，可以通过设计将流量分发到不同的服务器，避免单台服务器过载。又例如，将一个大泥鳅系统通过DDD领域设计驱动的方**去设计，绞杀者模式去拆解、重构。但光分解还是不够的，同时还需要保证分解后的部分能够通过约定好的协议集成在一起。

4.3、复用思维

复用是提升开发效率的最简单有效的方法，通过对相同内容的抽象，让其能复用于不同的场景。

很多新手程序喜欢**粘贴代码，如果需求变化，需要修改所有粘贴过的地方，开发效率低且难以维护，同时还浪费很多测试的精力。

复用是最佳的软件工程实践，没有之一。复用可以给我们带来以下好处：

• 较高的生产率。• 较高的系统质量。• 改善系统的可维护性。

所以，我们在进行架构设计时也需要使用复用思维，将各个模块需要用到的共性功能抽取为可复用的共性组件。

我们可以将复用分为常规复用和系统层复用。其中常规复用又可分为代码复用、算法复用、数据结构的复用；系统层复用又可分为设计复用、分析复用。

以上三种设计思维在架构设计中都很重要、且相辅相成，但并不是把每一项做到极致，而是需要在设计中去平衡各个思维，因为架构设计的本质是解决软件复杂度带来的问题，最终实现降本增效。

五、架构设计方**（how）

提到架构设计方**，有企业架构（EA）框架：Zachman框架 ，还有国际权威组织结构制定的行业标准的体系架构框架 Togaf。

一个好的框架（Framwork）有三个不同的方面：描述内容（结构、元模型）；描述过程（什么活动需要什么顺序发生）；描述组织（参与架构的人员、角色）

Togaf涵盖了这三方面，而Zachman框架只涵盖了内容，即内容框架。

接下来就介绍下 TOGAF（The Open Group Architecture Framework），它由国际标准权威组织The Open Group制定 ，是一个行业标准的体系架构框架 。它是一套方法和工具，主要包含TOGAF能力框架、 TOGAF架构开发方法、 TOGAF企业连续体和工具三大部分。

下面主要介绍下软件开发方法 （Architecture Development Method) ADM，它以一个循环迭代模型为基础将企业架构的建设过程划分为前后衔接的若干步骤，并对每个步骤的输入、输出以及所采用方法都进行了详尽的阐述。描述了一种开发和管理企业架构生命周期的方法。

5.1、 ADM架构开发方法——基础结构图

ADM 软件开发方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成的，ADM基础结构图如下图所示。

ADM基础结构图

ADM葫芦图概括为“一备一中心，八步一方法”（一个预备阶段、以需求管理为中心，八个主体步骤，一套方法ADM）

预备阶段：梳理业务需求，了解需求背后真实的业务目标。

架构愿景：最终需要达成到一个效果，需要提前做规划。

业务架构、信息系统架构、技术架构：属于架构域设计框架。

技术及解决方案：碰到技术问题都需要有一套甚至是多套解决方案，架构设计职责就是做取舍、做决策。

迁移规划、实施治理：后续线上运维相关事项，给出合理解决方案。

需求管理：项目的每个阶段都应基于并验证业务需求。

TOGAF描述了四类跨阶段迭代：预备阶段和阶段A之间的 架构能力迭代 ，阶段B-F之间的 架构开发迭代 ，阶段E、F的 过渡规划迭代 ，以及阶段G、H和预备阶段之间的 架构治理迭代 。

架构设计方**：是指导你如何来做架构设计，它有架构域划分，在软件设计中架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构。

首先需要进行业务需求结合业务场景的梳理，熟悉业务后，通过归纳以及抽象的方式，形成业务架构。

依据业务架构的理解，研发人员需要对业务做进一步的抽象和沉淀，画出与之相对应的数据架构和应用架构，最后技术人员通过技术架构来做功能实现。

业务架构是目标、是方向，应用架构是抽象、是归纳，技术架构是手段、是系统落地的参考物。

5.2、ADM架构开发方法——概念蓝图

ADM架构开发概念蓝图

左侧部分是企业的业务战略、目标、挖掘业务需求给出业务解决方案。中间部分是通过业务架构设计、数据架构设计、应用架构设计、技术架构设计给出技术解决方案。右侧部分技术解决的方案通过应用、项目去承载、在满足功能的基础上实现系统高性能及智能化。解决业务的复杂性，最终实现降本增效。

我们重点关注下中间部分架构设计，架构域分类：

1、 业务架构：讲需求描述转变成业务目标，梳理出信息业务流程和业务元素。

2、 数据架构：描述数据资产及数据管理资源的结构。

3、 应用架构：划分不同功能模块、根据功能模块的关系，组合成子系统。

4、 技术架构：支持业务、数据、应用部署所需的软件与硬件能力。

熟悉业务，形成业务架构，根据业务架构，做出数据架构和应用架构，最后通过技术架构落地实施。

5.2.1、业务架构

首先来看 业务架构 = 业务目标 业务流程 业务要素。

业务架构最重要的是识别出业务流程和业务流程中包含的业务要素，换个角度来看就是业务要素与业务要素之间的关系，这些关系组成了整个业务。

业务一般会按照 场景层、产品功能层、领域模型层、依赖层这四层画出业务架构图。

场景层：描述业务场景；产品功能层：划分产品功能以及模块；领域模型层：通过对产品功能分析，抽象领域模型；依赖层：从业务层面考虑涉及到底层业务依赖哪些子系统或者组件。

业务架构示例：业务目标 业务架构图. 业务目标：SAAS平台实现开户即用。用户根据所有应用的权限进行应用功能的访问，统一访问入口、控制请求（按应用、租户去路由到指定应用集群上）并进行应用治理。

5.2.2、数据架构

其次是 数据架构 ：由业务架构驱动，从业务架构分析业务流程，分析领域模型层，从领域模型层触发构建数据架构。

数据架构解决的是，第一，需要什么数据；第二，怎么存储；第三，如何设计。

数据模型最常用视图就是ER图，它主要描述数据实体、属性和关系。

实体（Entity）：领域对象；

属性（Attribute）：领域对象属性；

联系（RelationShip）：两个领域对象之间的关系（1:1，1:n或者）。

数据架构示例：

5.2.3、应用架构

再就是 应用架构 ，应用架构划分出不同功能模块，再根据功能模块间的关系，组合成子系统。应用架构考虑三个问题。

第一，子系统如何划分；第二，子系统之间什么关系；第三，考虑模块的复用和功能的抽象。

应用架构需要体现应用架构是否清晰、层次划分是否明确、各应用系统之间连接关系 是否合理、系统之间耦合程度是否低、是否以统一方式对外提供一致服务接口。

应用架构示例：

5.2.4、技术架构

最后是 技术架构 ，技术架构关注的问题有，如何使用技术手段来解决实际问题、技术框架如何选择、技术中间件如何选择、存储如何来做、非功能性需求如何来实现等。整体技术方案的输出就是实现技术架构的过程，最终会形成关键技术实现要点，形成一个完整的技术架构。

总结技术架构涉及到技术问题、技术方案、及技术组件。通过各种技术组件形成技术方案，最终解决业务上的技术问题。技术组件可以是分布式缓存、消息队列、分布式定时任务等，同时包括硬件能力、包括IT技术设施、**、通信、标准等。

技术架构图示例：

部署架构图示例：

六、小结

本文主要从什么是架构设计、架构设计原则、架构设计思维、架构设计方**四个方面来进行阐述，架构设计除了掌握技术框架、技术组件、技术原理性知识外，也需要系统性掌握架构基础知识，以架构设计原则、设计思维为指导，掌握Togaf架构设计方**，通过不断的优化和迭代，来实现更优秀的架构设计。