关于企业应用:企业应用平台的六大引擎

4次阅读

共计 3353 个字符，预计需要花费 9 分钟才能阅读完成。

因为技术的提高，古代企业应用无需从头开始开发，而能够利用企业应用平台，通过组件化、低代码乃至无代码的形式来构建，以取得更高的品质、性能和交付速度。本文提出企业应用平台的一种以元数据为核心的、基于六大引擎的架构。平台以元数据和业务畛域为核心，六大引擎环绕着核心，为企业应用的开发提供弱小的赋能。
有人可能会质疑低代码开发模式，而我认为这次要是因为低代码开发还没有失去古代软件工程的赋能，所以不够好用，因而将来的一个重要策略方向就是用古代软件工程来赋能低代码开发，即低代码软件工程（当前能够探讨这一话题）。

每一个引擎都是一个产品，能够由一个团队来负责开发和保护。能够基于开源产品做二次开发，然而肯定要齐全把握每一个引擎，能力确保平台的整体的高质量。
这六大引擎是：

数据引擎：负责数据的建模、治理和存取，为其余引擎提供数据源。换言之，是对数据库的一种高层封装机制。它比拟像 Martin Fowler 所述三层架构中的数据源层，或者 DDD（畛域驱动设计）中的 Repository 概念，然而有所不同。这是最重要的一个引擎，因为能够说企业应用都是面向数据的，是围绕数据而建的。数据引擎要反对对象关系映射，要能主动治理 DB schema（例如主动建表）。最好还可能内置软删除、草稿、审计等性能，这几样性能适宜对立建设，不须要让下层利用进行反复建设。数据引擎的底层是 ORM 框架，市面上没有适合的数据引擎产品（Supabase 勉强算一个）或 ORM 框架（JPA 勉强算一个），倡议全新开发。您可能会问，它与 ORM 框架有什么区别呢？最次要的区别为，数据引擎反对低代码开发模式，甚至能实时创立和批改数据模型而无需重启服务器。
体现引擎：负责各种数据交换的建模、治理和执行，例如为数据类型主动导出 CRUD API、将数据记录转换成适宜 UI 显示的 VO（视图对象）或适宜 API 应用的 DTO（数据传输对象）。这个引擎也相当重要，后文会介绍它为什么如此重要。市面上没有适合的体现引擎产品，须要全新开发。
平安引擎：负责安全策略的建模、治理和执行，其中一项比较显著的性能是对数据拜访权限的治理。对于器重平安和权限的企业应用，平安引擎是很重要的。市面上没有适合的平安引擎产品，须要全新开发。
规定引擎：负责业务规定的建模、治理和执行，业务规定能够用规定语言或图形化编辑的形式来编写，能够在运行时动静更新。规定引擎不是必要的（您也能够在零碎代码中硬编码所有的业务规定），然而很实用，它让业务规定能被更简略更疾速地交付。市面上有一些开源规定引擎如 Drools，也有一些脚本引擎如 Groovy、AviatorScript、MVEL 等能够被当作繁难的规定引擎来用。以上这些产品都须要用户手动用脚本代码的模式来编写规定。还有一些商业规定引擎反对低代码的可视化开发。这些引擎产品不反对元数据，所以要么将它们通过二次开发再应用，要么开发全新的引擎产品。因为脚本引擎产品大多有较高的内聚性和成熟度，能够当成一个程序库来用，倡议采纳二次开发的形式。
流程引擎：负责业务流程的建模、治理和执行，业务流程能够用流程语言或图形化编辑的形式来编写，能够在运行时动静更新。流程引擎不是必要的（您也能够在零碎代码中硬编码所有的业务流程），然而很实用，它让业务流程能被更简略更疾速地交付。流程引擎个别都反对低代码的可视化开发。市面上的开源流程引擎有 jBPM、Activity、Flowable 等，它们都基于一种名为 BPMN 的流程定义语言标准，也有一些流程引擎如 Temporal、Step Functions、Apache DolphinScheduler 不基于 BPMN 标准。这些引擎产品不反对元数据，所以要么将它们通过二次开发再应用，要么开发全新的引擎产品。因为 BPMN 系流程引擎产品大多简单臃肿，可扩展性差，因而咱们倡议基于非 BPMN 系产品做二次开发或者间接全新开发。
智能引擎：负责各种智能（报表、商业智能和人工智能）的建模、治理和执行。在现在的智能时代，简直没有企业会放弃建设智能零碎，智能引擎的重要性显而易见。智能是一个前沿畛域，还须要更多摸索。

一个架构至多须要一种能在其外部通用的数据交换格局，例如因特网是基于包 (packet) 的。元数据就是这么一种格局，它是各个引擎之间的次要沟通桥梁，也是低代码开发的外围要件。元数据能够被示意为 JSON 或 YAML 格局的配置数据，它是在数据之上的对于数据结构和语义的形容信息。开发者在构建企业应用时，个别会应用 SQL DDL 创立一些数据库的表 (database tables)，并且编写一些实体类(entity classes) 的代码（例如 Java 代码）。您能够大抵认为，元数据对应的就是实体类的定义（实际上元数据能够蕴含实体模型、视图模型、权限模型等多种信息）。
请设想一个典型的低代码开发过程：

有一款在线可视化编辑器，容许您在 GUI 上即时创立一个实体类。您能够创立一个 User 类，给它增加一些字段（例如 name, country, age），而后一保留，这个实体类的定义就在零碎中失效了（能够存储和查问 User 信息了），无需手动编写实体类代码。这个编辑器所保留的信息就是元数据，它记录了这个实体类的定义。以上性能是利用数据引擎实现的。
进一步，您还能够在线创立一个视图，它基于方才那个实体类(User)，然而只蕴含一些想展示的字段(name, country)，排除了某些不想展示的字段(age)，并且能够附带某些过滤条件表达式(country=currentUser.country)，即通过这个视图只能查问到那些与以后用户属于同一个国家的用户。以上性能是利用体现引擎实现的。
您能够间接在代码中拜访这个视图，也能够为这个视图主动导出一个 Web API。您也能够创立一个角色(Role)，把视图绑定到此角色，再把角色授予某些用户，那么这些用户在拜访 User 信息时就只能看见这个视图，而不能看见原始的 User 类。这样一来，用户就只能看见容许被受权给他们的数据，而不能看见全量数据。以上性能是利用平安引擎实现的。
您能够创立一个业务规定，将触发机会设在 User 类的数据被删除之后(afterDelete)，此规定会查找行将被删除的这个 User 所领有的资产数据，将这些资产数据标记为解冻状态。以上性能是利用规定引擎实现的。
您能够创立一个业务流程，将触发机会设在 User 类的数据被删除之前，此流程会发动一个审批流程，只有实现了审批流程，才会执行删除操作。以上性能是利用流程引擎实现的。
您能够创立一个有用的视图并把它主动导出为一个报表。您也能够编写一些代码，通过对元数据做一些操作来生成报表。以上性能是对智能引擎的简略利用。现在大数据畛域也在强调“元数据管理”(例如 Apache Atlas)，这与咱们的指标其实是统一的，将企业应用平台的元数据与大数据平台的元数据连通，是对元数据的一种很好的利用形式。

为什么是基于引擎的架构？

根据康威定律，零碎的架构实际上是由组织的沟通构造所决定的。提出引擎这一形象，就是为了让企业应用平台的架构适应个别组织的沟通构造。每个引擎都是一个内聚的畛域，能够由专门的团队来负责。元数据作为各个引擎之间的次要沟通桥梁，引擎之间也能够通过引擎的 API 沟通，下层利用则和元数据和各个引擎的 API 沟通。
其实一些企业应用平台已有向这种架构格调倒退的趋势，本文只是推动它的正式化。

为什么是六个？

本文只提出了最重要的六大引擎，这是一个偶合的数字，但您也能够认为它与六边形架构（hexagonal architecture）是有所响应的。除此六大引擎，当然还能够有其余引擎，但其重要性绝对较低。咱们只关注这六大引擎，而它们的组合足以用于构建大多数的企业应用。

能够采纳微服务架构吗？

这是一个值得答复的问题。答复是：能够，但有所限度。基于平台的业务利用当然能够用微服务架构来建设，但这个平台自身并不适宜微服务架构。如果您想将每个引擎做成一个微服务，不倡议这么做。引擎之间的分割比拟严密而且细粒度，每个引擎一个微服务的形式不利于性能和可靠性，我见过一些失败的引擎微服务架构尝试。
举荐的总体架构是，每个业务利用被部署为一个服务，在每个服务中同时部署了所有的引擎。