技术框架有哪些，市面上主流的框架技术，框架技术有什么

hwyzw

    技术架构是对某一技术问题（需求）的解决方案进行结构化的描述，它由构成该解决方案的组件结构以及它们之间的交互关系所组成。从广义上来说，技术架构是一系列涵盖多种技术问题设计方案的统称，像部署方案、存储方案、缓存方案、日志方案等等。

    []

    技术架构元模型综述

    技术架构元模型是对技术架构组成要素进行的抽象建模。它可以用来定义用于结构化描述架构设计的模型元素。技术架构元模型的定义必须满足当今企业数字化建设的实际需求。

    我们为了适应当今企业对技术架构的描述需求，在经典企业架构框架方法的基础上，对技术架构元模型进行了补充扩展。其内容主要包括架构模式模型、架构方案模型以及技术策略模型。

    02

    技术架构元模型应用

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

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

    一方面，在平台型技术架构的设计里，它作为多业务线、多应用、多数据场景得以落地的技术基座。技术架构设计需要覆盖的规模很大，应对的复杂度也与以往大不相同。再加上“富”技术条件的辅助，这就导致一个好的技术架构设计的困难程度实际上呈指数级上升。一直以来，技术架构设计方法和过程本质上是强依赖架构师的经验和能力的。在这样的语境下，一系列挑战和问题再次显现出来：

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

    03

    系统性的分析架构需求

    在架构咨询期间，我们见到了诸多因不良架构而引发的问题现象。在对这些问题现象背后的核心因素进行分析时，都指向了一个关键原因，那就是缺少前期对架构设计需求的系统性分析。当技术团队被问及为何采用某种设计思路以及为何使用某种技术组件时，所得到的回答往往与他们自身的主观经验有着很大的关联。

    这带来的重要影响在于，架构质量和设计者的经验有着紧密的关联。同时，经验的传递成本是比较高的。在架构决策过程中，其中的信息大多都被丢弃了，仅仅留下了架构设计的结果。正因如此，架构最终难以进行演进和迭代。

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

    1、问题 、上下文

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

   

    问题描述了架构需求所针对的实际问题，比如在业务中台里，要如何确保前台能获得一致的服务等级承诺（SLA）。

    上下文对与问题相关的背景信息进行了描述，比如问题产生的背景究竟是什么，需要考量哪些约束条件，期望达成怎样的效果等等。

    2、模式

    模式是依据对问题以及上下文的分析，迅速与业界或企业内的最佳实践相对应。

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

    3、决策

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

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

    04

    实践总结

    通常先使用问题和上下文对上层设计意图进行系统性分析。经过这样的分析后，如果得到的问题是准确的，那么在业界往往已经存在成熟的解决方案模式可供参考。架构模式元模型的价值在于帮助企业识别并利用那些已经成熟的最佳实践，从而提高架构设计质量，降低架构设计成本。

    以上面提到的中台如何提供一致的服务等级这个问题作为例子，经过分析后发现，背后的技术问题定义为如何处理接入前台之间跨功能需求（包括安全、存储、性能、可靠性等）的隔离问题，基于此能够快速确定对应的基础架构是多租户（Multi-）架构。

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

    我们通过以上四个元模型元素对架构设计过程进行了描述。在实际应用中，每一个元素都能依据企业的架构设计规范，建立起对应的参考模型，包括分类、图示和描述等，这些参考模型用于规范架构过程的产出物标准，这里暂不展开相关内容。

    在复杂的平台型技术架构里，能否对架构元素进行准确识别以及直观描述，会直接对架构设计方案是否易于被理解、使用和管理产生影响。在现实世界中，结构化是我们理解、记忆以及描述复杂事物的最好方式，我们期望能将其应用到架构设计中以提升架构的表现力，所以我们在设计时把元模型的主要考量因素设定为：

    本文   ——MEAF

    附

    思考笔记

    01

   

    本文相较于经典技术架构元素，弱化了逻辑和物理方面的分类。它采用带有明确职责属性的分类方式来定义架构元素，最终形成了轻量且结构化的描述元模型。

    02

    本文提出，在进行元模型的设计和使用之前，需要先明确自身真实的业务痛点以及架构需求，然后再去实现设计方案并进行建模的本地化部署。然而在现实里，总有部分企业几乎没有对自身企业架构需求进行思考，完全寄希望于在构建完架构资产之后，架构资产能够自动给出所有的答案和价值。那样很可能构建了一系列“死”的资产，不清楚该怎样将其“用”起来，也不明白如何对其进行迭代以及持续建设。

    与其先把资产录入完毕然后再去思考架构的用处，不如一开始就清晰地想好自己对于架构的需求。按照正确的顺序去做，就能收到事半功倍的效果。

    03

    企业架构的作用是什么呢？一句话，是建立组织的“统一视图”。企业架构的意义是什么呢？一句话，也是建立组织的“统一视图”。

    业务部门发现系统接不通，每天需要手工填写大量表单，还要做大量手工工作。在信息建设过程中，业务部门其实很难讲清楚哪些是业务问题，哪些是系统问题，哪些是数据问题。

    IT 部门每天要应对众多零散的 IT 需求。有时解决一个需求，会引发 100 个新问题。有时业务部门提出的解决方案存在局限性，无法从根本上解决问题，就直接粗暴地甩给 IT 部门，之后还不断进行变更。长久这样下去，业务问题与 IT 问题相互叠加，最终留下一片对局内人和局外人来说都极为复杂难解的问题沼泽。

    如果不存在企业架构，许多企业内部的工作者，仅仅能够成为问题的旁观者，然而却无法成为解决者。这实际上是视角方面的问题，在学科和部门的限制之下，有的人仅仅能够看到象的鼻子，有的人仅仅能够看到象的尾巴。企业架构所做出的最大贡献，便是将大家对于大象的认知，都描绘在一张图中，使得每个人都能够理解，并且每个人都能够运用。

    在这个基础之上，接着去谈论，每个架构领域该如何进行管理，如何为业务或新技术发展赋予力量，如何推动战略变革，如何增强与收购子公司的整合等。

    数孪模型科技专注于组织建模与治理平台的开发，也致力于企业架构以及数字化转型的设计。它将为行业的数字化转型给予强有力的基础设施和方法方面的支撑，共同构建行业数字化的发展成果，同时沉淀企业中优秀的行业案例。公司秉持“模型致知、数据智行、架构治理”这一核心理念。公司引领用户去构建虚与实映射、优化管理的组织数字化转型未来场景。公司以模型作为载体，深入地推进企业描述和管理万事万物的方式进行升级。