为什么构建架构工作台.docx

《为什么构建架构工作台.docx》由会员分享，可在线阅读，更多相关《为什么构建架构工作台.docx（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、为什么构建架构工作台？在ArchGuard中，我们想治理的是架构的三种形态：设计态、 开发态和运行态。对应于：设计新的企业（应用）架构。诸如于描述和设计系统的当前架构。理解和管控系统的现状。诸如于通过可视化的手段展示系统的现 状、以规那么来管理系统。观测系统 二 架构的运行。同样，对于诸多中大型组织师的架构相关的部门来说，他们同样 存在上述的这些问题。并且，我相信他们也面临着同我们构建 ArchGuard时一,样的困境:架构是多维的。包含技术、数据、平安、运维与系统等缺乏统一的架构语言。用于沟通的人类语言，诸如于什么是组 件？系统的架构千奇百怪。架构风格或模式差异，如微服务架构、插 件化架构等

2、。缺乏业务上下文。作为一个外部架构师，帮助治理时缺乏一些上 下文。细节是魔鬼。架构的世界丰富多彩，没有方法一一展现出来，比 如一个小小的接口，可能会反转我们对于理解的假设。我们（ArchGuard团队）目前的架构能力有限（这个不会写出来 的）资深架构师太少。所以，在实现这样一个标准化的架构模式系统之前，不如尝试构 建一个更灵活的形式：架构工作台。它可以帮助我们更好地探索系统， 也更符合我们的初期体验。什么是架构工作台对于工作台这一概念来说，作为一个活跃的DSL创造者，我比 较熟悉的是Martin Fowler在领域特定语言中对于语言工作台 的定义：语言工作台是一个环境，其设计初衷就是帮助人们构

3、建新的DSL, 以及有效地运用这些DSL所需的高质量工具。也因此在定义上，我们参考了老马的定义，并借鉴了现代化的工 作台理念，主要有：RStud io的代码文档化、Jupyter的交互性分析。 所以，我们的定义是：架构工作台是一个环境，其设计初衷用于帮助人们设计架构、演 进架构、观测架构，并有效地运用架构所需要的高质量工具，如交互 式的架构开发和分析。代码文档化，用于帮助我们更好地管理架构代码，将它融入软件 开发生命周期里，如架构文档、用户故事、持续集成等。而交互性分 析，那么是用于帮助我们有效减少定制的代码，进而演变为提供的是 API接口，与其定制化的代码。对于架构工作台来说，它应用包含了以

4、下一些核心功能与特性：设计架构、演进架构与观测架构。构建架构的数字事生说明性编程与显式设计在这些特性中，我们认为构建架构的数字挛生是这个工作台最应 该被重视的局部，而基础块那么是：设计架构、演进架构与观测架构。基础：设计架构、演进架构与观测架构在治理架构时，我们通常会关注于如何设计，如何演进，以及观 测架构在运行时的状态。设计架构。这样的功能其并不能理解，难点是，如何提供高效的 设计机制？采用UI拖拉拽的方式，又或者是DSL,都有各种的博弈。 总体来说使用代码会更加友好。而为了直观的展示架构的设计，我们 会通过架构图来表示，这也就是系统的核心。演进架构。其核心是构建架构治理模型和设计架构的适应

5、度函数, 以引导系统进行有序的变更。从实现的层面来说，就是从对实现出来 的软件架构（即代码等）进行分析，设计度量指标，并提供高质量的 工具，来引导架构回归到合理的状态。观测架构。即观察架构的应用的运行状态，主要依靠于各类的 APM （app I icat i on performance management, 应 用性能监测）工具。 在云原生时代，相关的工具也非常的流行，如Skywa Iking等。一个基础的架构工作台，应该考虑上述的三个要素。进阶：构建架构的数字事生理想的架构工作台，它应该提供一个可交互的架构的映射版本。 它意味着：它是对系统或对象在其整个生命周期中的虚拟表示，我们 可以根

6、据实时数据进行更新，并使用模拟、机器学习和推理来帮助决策。从概念上来说，它提供了一个非常美好的未来，难点就在于如何实现这样的系统？我们正在设计ArchGuard的数字季生版本，那么围绕于这三种形 态的架构形式（从实现的层面考虑的）：设计态。关注于边界、概念与交互。开发态。关注于层级、依赖与模块。运行态。关注于性能、链路层级与资源使用。这个版本相当于是设计态，在实现的时候，还会受到开发能力和 数据上的制约。未来，我们是不是也应该代码及其架构事生的双向绑 定？核心：说明性编程与显性设计我们所熟悉的各类架构相关的规范，它存在着诸多的问题，诸如 于：规范不直观、规范没有自动化等。为了有效的演进架构，我

7、们需 要有效地结合规范、代码、设计，也就是说明性编程与显性设计，它 们都是来自于PL （编程语言）/ DSL （领域特定语言）中的概念。说明性编程（i I I ustrat i ve programmi ng）是用于加强执行结果 的解释性，如在架构治理的场景下，通过生成架构图来理解DSL编 写的结果。另外一类觉的方式，有诸如于Excel中的表格和图表等。 详细可以查看文末Mart i n FowI er的相关文章。显式设计。显式是通过明确编写要完成的指示来完成所需更改的 手动方法。显示设计那么是指引我们如何构建好系统的描述语言，诸如 于ADL (架构描述语言)的DSLo除了，使用贴进架构描述的

8、语言， 还有用于支撑DSL的工具支撑，如编辑器智能感知。这两个特性是围绕于架构即代码这一理念所改善的，诸如于 PIantUML Graphviz 这一类图表即代码(Diagrams as code)也具 备了这样的特质。其它特质当然，为了让这个系统更好用，我们还需要其它的一系歹“特性：架构演进的模拟验证。在构建了架构的数字季生之后，我们就可 以易于扩展的功能。即采用微内核架构，即插件化、微前端化等。依旧还有诸多东西可以探索，等待我们构建完第一个版本后，再 展开讨论。我们应该如何去设计与实现的？我们现在ArchGuard中实践一个这样的系统，它相当地令人激 动。作为一个早期的版本，它勉强可以工作

9、，如下是我们构建系统的 一些思路。1 .大数据的工作台作为灵感由于，系统是一个类似于数据分析的系统，所以我们的诸多流感 来源于大数据领域。在工作台上，起初，我们的想法是构建一个采用 RStudio似的可编译报告，并提供类似于Jupyter的交互体验。可由于Jupyter的交互体验太差，下载的文件又没有可读性，不能方便地编辑+运行。所以，我们采用了 Markdown作为数据格 式，方便于开发人员编写文档，也可以在任意的IDE中翻开和编辑。在UI上，那么是采用ProseMi rror主编辑器，即Markdown的编辑 器，采用Monaco Editor作为副编辑器，即代码的编辑器。2 .构建基于R

10、EPL的抽象考虑到了 IDE支持，我们采用了 Kotl in来构建内部DSL,这 样就无需外部DSL需要构建编辑器支持。接着，就采用了 Kotl in Scripting Comp i I er 作为底层的 REPL ( read - eva I - print I oop, 也称为交互式顶层构件)，简单来说，就是Kotl in语言的命令行模 式。从形态上来说，类似于MySQL Workbench的形式，又或者说是 Python 的 CLI 模式。随后，便是抽象系统(ArchGuard)、设计态的架构、架构适应度 函数的DSLo.请求和响应程序的运行在有了编译器后端的支持及Kot I i n DSL的IDE之后，我们需 要构建双者的桥梁。于是，我们采用WebSocket作为通信方式，返 回结果上按不同的类型处理。诸如于：集成后端API的运行结果。图形结果。Mermaid、D3. js、Echart, js是针对于不同图形展示。执行对应的扫描。与通常的C/S结构开发无异。图形化的结果，用于支持我们的说明性编程与显性设计。