Tech

导读

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

在了解架构本质之前先了解下架构的定义，百度百科对架构的定义：架构又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

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

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

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

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

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

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

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

软件开发更多是面向确定性逻辑问题，依据自身对需求的理解进行实现，实现方式较为固定，流程化开发完成需求功能，实现最终目标。比方说实现订单接收的能力，分几步：参数验证、商品查询、库存预占、生成订单、扣减库存、修改订单状态、状态回传，业务逻辑较为固定，如果再加上编码规范以及框架约束，除了数据模型以及编码设计之外，其他方面涉及较少。

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

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

首先提到就是合适原则，一切不按实际场景出发的架构设计都是在耍流氓。比如你想买个车子，买贵觉得性价比不高，买便宜了觉得开起来不舒适，你最终会挑一个适合现在经济能力范围内又比较舒适的车子，这就是合适原则。以当前业务需求和非功能性需求为目标，匹配业务发展所处阶段，合理利用资源发挥最大价值（买车子需要匹配当前经济状态）；需要结合实际场景，合适的系统架构 （我买车子只是为了代步，不能说我觉得跑车气派，我就买个跑车，这和业务实际场景不符合）；还需要和当前的业务规模以及最近1-2年的发展规划相互匹配 （虽然我一次性付不起，但有稳定经济收入，我可以考虑贷款，分2年期。这样我既买到理想的车型，也不担心压力大）；新技术推出，势必是解决某一场景下的问题，但并不能解决所有问题，任何架构都要综合来看，结合合适原则综合选择。

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

最后是演化原则，只有变化是永恒不变的，优秀架构一定是以业务不断发展而不断演进而来；设计架构要满足当时业务需要 ，具有可扩展性和持续开发能力，能够应变后续架构升级和调整；要不断地在实际应用过程中迭代，保留优秀设计，修复有缺陷设计，改正错误设计，剔除无用设计，使架构逐渐完善，要将变化部分和不变部分区分开。

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

下面主要介绍下软件开发方法（Architecture Development Method) ADM

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

图一 ADM基础结构图

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

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

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

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

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

架构设计方法论是指导你如何来做架构设计，它有架构域划分，在软件设计中架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构，首先需要进行业务需求结合业务场景的梳理，熟悉业务后，通过归纳以及抽象的方式，形成业务架构，依据业务架构的理解，研发人员需要对业务做进一步的抽象和沉淀，画出与之相对应的数据架构和应用架构，最后技术人员通过技术架构来做功能实现。业务架构是目标、是方向，应用架构是抽象、是归纳，技术架构是手段、是系统落地的参考物。

下图为ADM架构开发概念蓝图。

图二 ADM架构开发概念蓝图

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

场景层：描述业务场景；

产品功能层：划分产品功能以及模块；

领域模型层：通过对产品功能分析，抽象领域模型；

依赖层：从业务层面考虑涉及到底层业务依赖哪些子系统或者组件。

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

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

• 实体（Entity）：领域对象；

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

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

再就是应用架构，应用架构划分出不同功能模块，再根据功能模块间的关系，组合成子系统。应用架构关系三个问题。第一，子系统如何划分；第二，子系统之间什么关系；第三，考虑模块的复用和功能的抽象。应用架构需要体现应用架构是否清晰、层次划分是否明确、各应用系统之间连接关系是否合理、系统之间耦合程度是否低、是否以统一方式对外提供一致服务接口。

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

上文阐述了架构设计的一些基本原则，帮助读者思考如何通过架构设计理论知识提升自身的架构能力，从而成为一名合格架构人员。架构设计是一个长期并且需要不断打磨的过程，任何系统的架构都做不到一蹴而就，需要系统面临技术问题、业务问题时不断地优化和迭代。架构设计除了掌握技术框架、技术组件、技术原理性知识外，也需要系统性掌握架构基础知识，以架构设计原则为指导，掌握架构设计方法论，通过不断地优化和迭代，来实现更优秀的架构设计。