6.2 技术架构元模型应用

6.2.1 富技术时代如何做好平台型技术架构设计

受益于新技术的涌现和不断成熟，及技术工具的极大丰富，技术架构设计的灵活度和效率都得到了显著提升。

另一方面，在平台型技术架构的设计中，作为多业务条线、多应用、多数据场景落地的技术基座，技术架构设计所需覆盖的规模、应对的复杂度今非昔比。加之“富”技术条件的加持，一个好的技术架构设计的困难度实际上指数级增加。而一直以来，本质上是强依赖架构师的经验和能力的技术架构设计方法和过程，在这样的语境下，一系列挑战和问题再次凸显：

• 对于架构需求把握不足或者没有架构需求的分析意识，过早的进入架构设计，导致系统复杂度变高甚至过度设计，为开发落地带来额外的研发成本
• 架构设计采用的技术和工具过于超前，超出团队成员技术水平，造成落地难度高，新成员上手速度慢，进而对整体进度和实施效果造成影响

• 架构设计过程时间长，完成后团队就不再愿意对设计方案继续调整和迭代，当技术发展变化很快时，设计完成时方案已经过时。

  因此，富技术时代下，做好平台型技术架构设计的关键是：

  • 系统性的分析架构需求
  • 结构化的设计架构方案
  • 沉淀可复用的架构经验

( 图 6.2-2 技术架构元模型的应用 )

6.2.2 系统性的分析架构需求

在架构咨询过程中，我们看到很多由不良架构引发的问题现象，分析背后的核心因素时，都指向了一个关键原因，即缺少前期对架构设计需求的系统性分析。当技术团队被问到为什么使用某种设计思路，为什么使用某种技术组件时，得到回答往往跟其自身的主观经验有很大关系。

这带来的重要影响是架构质量与设计者经验密切相关，而经验的传递成本很高，架构 决策过程中的信息基本都被丢弃，只留下架构设计结果，导致架构最终难以演进和迭代。

因此我们在技术架构元模型中增加了架构模式元模型，引入模式分析的方法对架构的设计过程进行建模。

( 图 6.2-3 架构模式元模型 )

问题 Problem、上下文 Context

问题和上下文是对上层架构设计输入的分析和解读。

问题描述了架构需求背后要解决的实际问题是什么，例如业务中台中如何保证前台获得一致的服务等级承诺（SLA）。

上下文描述了与问题相关的背景信息，例如问题产生的背景是什么，需要考虑什么样约束条件，期望达到什么样的效果等等。

模式 Pattern

模式是通过对问题和上下文的分析，快速映射到的业界或企业内的最佳实践。

模式是解决某一类问题的方案原理的总结，通过模式技术人员可以快速构成对问题及方案背后原理的理解，在问题不变时，模式具有相对的稳定性，是沉淀技术知识的最佳形式。

决策 Decision

决策描述了在模式的基础上，引入与具体架构方案设计相关的影响因素后，形成的符合满足架构建设需求的技术类决策，决策的描述方式可以是决策树或决策表。

对决策的建模有助于使企业建立起规范的技术决策管理，规范化决策过程及决策内容，是企业构建可演进式的架构治理能力的关键。通常决策的影响因素包括来自顶层设计的 IT 技术战略、架构策略、技术选型、跨功能需求、IT 实施方法等。

实践总结

通常使用问题、上下文对上层设计意图进行系统性的分析后，得到的问题如果准确，那么它在业界往往已经存在成熟的解决方案模式可以参考。

架构模式元模型的价值是帮助企业识别和利用已经成熟的最佳实践，提高架构设计质量，降低架构设计成本。我们以上面提到的“中台如何提供一致的服务等级”这个问题为例，经过分析，背后的技术问题定义是如何处理接入前台之间的跨功能需求（安全、存储、性能、可靠性等）隔离问题，由此可以快速确定对应的基础架构是多租户（Multi-tenancy）架构。

( 图 6.2-4 多租户架构 设计模式示例 )

多租户架构在业界有标准化的成熟模型可以参考，因此我们可以将其作为参考架构，再结合上下文中的需求背景做架构细化，最后引入技术策略模型进行技术选型、实施规划等方面的技术决策，产出最终技术架构方案。

至此我们通过以上四个元模型元素描述了对架构设计过程的建模，实际应用中，每一个元素可以根据企业的架构设计规范，建立对应的参考模型（分类、图示、描述）用以规范架构过程的产出物标准，这里暂不进行展开。

6.2.3 架构方案模型

( 图 6.2-5 架构方案模型 )

相对于经典技术架构元素，我们弱化了逻辑、物理上的分类，使用带有明确职责属性的分类方式定义架构元素，同时我们对元素的职责进行了符合平台化特征的重新定义，最终组成轻量的结构化的描述元模型。

( 图 6.2-6 技术架构层与应用架构层元模型关系 )

技术组件 Component

技术组件用于描述技术服务的实现，是可部署的物理组件，例如可运行的软件系统或构建打包后的应用组件，技术组件通过架构模式的决策元素，与技术选型进行关联。

与技术组件相关的映射示例

技术服务 Service

技术服务用于描述实现上层架构设计意图所需的技术能力（或功能），例如网关、防火墙、数据存储、缓存等。技术服务属于逻辑模型，作为一种对服务能力的描述，与之相关的 SLA 等跨功能性需求会同时作为其参考描述信息。

技术服务的描述示例（参考 SLA 服务等级描述）

技术服务的价值在于将上层架构中的技术需求与实现相分离，以保证架构设计的稳定性和实施上的灵活性。

在技术架构治理中，技术服务是企业 IT 的核心能力对外的重要展现形式，也是 IT 的核心资产之一，从技术服务的角度实施管理将有助于提升企业整体 IT 服务水平。

技术平台 Platform

技术平台是用于描述由一组技术服务构成，提供解决特定技术领域能力的逻辑模型，它主要用于从更高的层次对技术服务进行管理，简化架构参与者对复杂架构的理解和使用，统一对用户提供一致的SLA 服务承诺。

下面是技术平台在架构设计中的典型用途：

1. 技术平台作为技术服务的提供者
   例如微服务架构通常需要多种技术服务提供支撑，在一些企业内部或技术产品中，将其统一归入微服务平台。
2. 技术平台作为技术组件部署运行的承载者
   例如当架构中需要描述部署方案时，技术平台可作为对部署载体的描述，例如提供容器化运行的 PaaS 平台。
3. 技术平台作为外部服务的提供者
   例如使用 AWS 等云平台提供的技术服务时，架构设计上即可忽略对技术服务支撑的技术组件的描述。

实践总结

结构化的架构描述有利于企业从多种视角对架构进行管理和治理，实际架构设计过程中，可以由技术服务为切入点展开高阶设计和详细设计。

首先明确上层架构设计意图中对技术能力的依赖是什么，进而定义出技术服务所需提供的 SLA 服务承诺等级，结合架构模式中的决策模型选择技术组件的选型。

对于需要多种技术服务组成而成的能力描述加入技术平台进行统一描述，在高阶设计中以技术平台和技术服务为主描述清楚架构意图和逻辑，在详细架构设计中进而展开技术组件级别的设计。

6.2.4 沉淀可复用的技术知识

技术架构中的复用涉及两个方面：

1. 通过技术组件、平台提供可共享的技术服务
2. 架构设计过程中产生的可重复利用的技术知识

技术服务共享在企业中已经通过 IaaS、PaaS 等技术平台得以实现，在最后一个实践中，我们要关注的问题是技术知识的复用。

企业架构设计背后都是成本的投入，从技术管理的角度，管理者希望一次投入可以在更长的时间里产生更多的价值；从技术设计的角度，架构师希望用更短的时间完成更高质量的架构方案。因此很多企业在技术治理策略中，将技术知识作为重要的技术资产进行管理。

下面从技术架构知识管理关注的两个核心问题展开我们对元模型在知识复用上的设计意图：

• 当完成架构设计后，我们从中得到了什么？
• 有什么是可以在以后的设计中重复利用？

( 图 6.2-7 复用技术架构设计 )

当完成架构设计后，我们从中得到了什么？

通过元模型可以看到，架构设计的产出物包含结果产出物和过程产出物，过程产出物往往在设计过程中作为隐性内容被忽视了，对架构过程的建模的目的之一就是将过程产出物显性的表现出来。

结果产出物的价值主要体现在对建设实施的指导，而过程产出物则代表了对问题、方案的思考分析过程，其价值主要体现在技术知识传递环节，在知识管理领域中 “渔” 比 “鱼” 价值更高。

架构模式元模型中元素同样是对经验的结构化表达，使仅存储在少部分设计者大脑中的信息得以可视化的展现，便于经验的传递和学习，这也是架构模式元模型的重要作用之一。

有什么是可以在以后的设计中重复利用？

在现实世界中，能够被广泛重复利用的事物都有一个共同的特征，就是在较长的时间里具有很高的稳定性。稳定是可复用的基本前提，复用的价值是从外部变化时而自身可以不变中的获得的。

在技术架构元模型中，架构方案是架构模式在特定场景下的实例化结果，其中特定场景包含上层架构输入的设计意图、影响决策的技术策略等，这些因环境而变的信息是不稳定部分。

架构方案 = 模式 ( 问题，上下文，决策 )

因此在一个架构设计中，问题、上下文、决策都是变量，只有模式是稳定的。最后我们可以将可复用的技术知识对应到三类架构产出物上：

模式

解决某类问题的最佳实践，只要问题存在，模式就是稳定不变的，不受使用场景的变化而变化，可以结合领域扩展模型对模式细节展开描述。

经验

经验是特定场景中对模式的实例化应用的过程记录，经验可以加快对模式的理解，学习如何结合实际场景应用模式解决问题，经验的内容由架构模式元模型中的问题、上下文、决策三个元素组成，每个元素可以通过定义对应的参考模型展开描述。

方案

最后是架构设计结果，作为案例供后续参考。