基于 SOA 的组件化业务基础平台

谁践踏了优雅 2022-05-11 02:52 168阅读 0赞

## 前言 ##

业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层，解决 “应用软件的业务描述和操作系统平台、软件基础架构平台之间的交互与管理问题”。很多国内软件厂商，很难在操作系统平台和软件基础架构平台上有所作为，因此国内众多的软件厂商纷纷推出自己的业务基础平台，把业务基础平台看作自己的核心技术。当前比较流行的业务基础平台大多都是基于早期的技术架构，虽然经过了多年的发展，但是由于技术架构不是完全基于 SOA 的组件化概念搭建，组件化支持并不是很彻底，如何在 SOA 下搭建组件化业务基础平台成为当前软件开发商所面临的新课题，本文将会基于组件化的概念，介绍一种搭建组件化业务基础平台的思路，首先我们看一下什么是“业务基础平台”，以及组件化概念。

### 业务基础平台 ###

如前言所述，业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层，解决 “应用软件的业务描述和操作系统平台、软件基础架构平台之间的交互与管理问题”。操作系统平台解决了“应用软件系统与硬件之间的交互与管理问题”，软件基础架构平台解决了“应用软件系统与操作系统平台之间的交互与管理问题”，而业务基础平台则是解决了“应用软件的业务描述与操作系统平台、软件基础架构平台之间的交互与管理问题”。如下图所示：

图 1. 业务基础平台在技术架构中的位置

![70][]

一般业务基础平台都包含两个部分，运行环境和开发环境，开发环境主要用于解决如何更加快速的开发，也是业务基础平台的核心内容，本文主要介绍业务基础平台的运行环境架构，关于开发环境将不在进一步论述。

### 业务组件和公共组件 ###

业务组件（Business Component，BC）是一个可以独立运行的系统或者模块，业务组件的目的是以方便业务组件独立升级和减少不必要的组件之间的交互为基本原则，通过一定程度的分离，实现软件重用（Software Reuse）。如果业务组件是共用的，是其它业务组件需要重用的，称之为公共业务组件（简称公共组件），所有的公共组件组成企业架构中技术架构的公共服务平台，比如主数据管理、系统管理、统一认证管理、通用报表等，这些都是公共组件。详见之前的文章《面向服务体系架构（SOA）和业务组件（BC）的思考》（以下简称 SOA 和 BC）关于业务组件和公共组件的说明。

## 组件化业务基础平台 ##

基于组件化业务基础平台和传统的业务基础平台主要的差异在于组件化业务基础平台具有更多的灵活性、可扩展性，能够更加方便的进行组件升级和组件维护。特别是对于大型的行业软件来说，易于升级、易于维护，能够灵活的扩展成为评测一个业务基础平台的一个重要标准，随着业务的不断发展，很多一体化行业软件代码数量已经超过 1G，如何对如此庞大规模的代码进行维护、升级成为软件开发者和运维管理者日益关注的一个课题，代码关系复杂、系统启动慢成为一个大型系统所面临的一个主要矛盾。组件化业务基础平台主要用于解决简化开发，快速系统维护的问题，以下通过对两种业务基础平台的对比，对组件化业务基础平台的组件实现、调用方式、所包含的公共组件及组件进行说明。

### 传统的业务基础平台 ###

当前在 J2EE 框架下业务基础平台基本上是采用了“Spring Framework”、“Expresso Framework”、等开源软件为基础的框架，业务系统基于业务基础平台进行开发，在一个企业内部，很容易形成基于一个业务基础平台横向开发出多个业务模块，甚至是跨行业的业务组件，基于一个业务基础平台开发的系统，所有的业务组件可以基于一个数据库运行，搭建一体化的业务应用系统。当前常见的业务基础平台包括浪潮 Loushang 平台、SAP 的 Net Weaver、金蝶 Apusic、普元 EOS 等。其架构如下图所示：

图 2. 业务基础平台模型

![70 1][]

但是这种模式存在几个重大的缺陷：

1.  业务模块和业务基础平台紧耦合，业务模块过于依赖于业务基础平台，一旦业务基础平台升级，业务模块也不得不升级，很多业务系统需要重写；
2.  随着业务的发展，业务模块不断增加，系统越来越庞大，系统难于管理，特别是随着系统代码的不断增加，性能越来越差；
3.  业务模块升级困难，由于各个业务模块和业务基础平台紧密，各个业务组件很难独自升级，而且所有相关的升级不得不考虑业务基础平台的影响。

如何既能实现一体化，又可以解决以上问题是当前业务基础平台需要解决的问题。

### 组件化业务基础平台 ###

在《面向服务体系架构（SOA）和数据仓库（DW）的思考》（以下简称《 SOA 和 DW 》）一文中曾经提出一个原则：“软件的核心是重用，方法是分离，关键是标准”，组件化基础业务平台依然是遵循这个原则。随着 SOA 技术的逐步发展，SOA 已经成为像面向对象一样虽然不像“云计算”那样时髦，却成为一个重要的软件体系设计模式。由于很多软件都是基于业务基础平台进行开发的，业务基础平台的组件化成为组件化开发的一个基础的要求，如果业务基础平台没有实现组件化，组件化开发还是停留在之前的遗留系统改造的概念中。如何实现业务基础平台的组件化，如何利用组件化对业务基础平台进行改造成为业务基础平台关注的一个焦点。

组件化开发，首先是业务基础平台本身的组件化，把业务基础平台看成是一个独立的组件，即《 SOA 和 BC 》所描述的基于企业集成平台（企业门户、应用集成、数据集成）的公共组件所描述的内容。

业务基础平台的组件化，并不是所有的内容全部组件化，有些内容是无法分离出去的，因此首先要把业务基础平台的内核分离出来，建立一个业务基础平台的微内核，微内核是跟每一个业务组件紧密相关的。然后把业务基础平台中可以分离出来的内容单独作为一个组件，即公共组件，从而实现业务组件和公共组件的分离。

业务组件和公共组件使用一个数据库，通过公共组件及相关的标准实现整合，如果还有已有的系统，则通过企业集成平台进行整合。如下图所示：

图 3. 组件化业务基础平台模型

![70 2][]

### 业务基础平台主要业务组件 ###

公共服务组件包含系统管理、流程管理、主数据管理、元数据管理等，在数据层面分别对应着系统数据、流程数据、主数据和元数据等数据。考虑到公共服务组件的独立性，特别是保证每一个组件独立升级之后不会影响到其他的公共服务组件以及业务组件，因此需要对公共服务组件进行隔离。

图 4. 业务基础平台主要业务组件

![70 3][]

系统管理主要包含：用户管理、功能管理、权限管理、认证管理等功能，其中需要特别注意的是实现不同的业务组件的统一认证的问题，即实现不同的业务组件部署在不同的应用下（在 J2EE 环境下为 EAR 文件）的单点登录。

主数据管理主要包含：主数据模型管理、主数据质量控制、主数据监控等功能，主要实现各个组件之间公用的基础数据的管理，需要考虑主数据在那个业务组件中进行维护的问题，不同的主数据需要在不同的业务组件中完成，而不是所有的主数据都在主数据管理组件完成。

流程管理主要包含：代办任务管理、流程自定义、流程引擎等功能，主要实现对代办任务的统一管理、流程的管理。流程管理主要实现流程和业务的分离，并实现办公用的灵活流程、业务用的固定流程，详见《基于 SOA 的工作流（WF）整合》的描述。

元数据的管理主要包含：元数据管理、数据质量监控等功能，主要实现技术元数据和业务元数据的管理。

### 业务基础平台组件接口调用方式 ###

在实际开发应用中，性能是很重要的一个非功能性需求，特别是针对大型的应用系统，性能是决定项目成败的一个关键因素，业务基础平台的架构决对性能问题有着重大的影响。如何在实现松耦合的基础上，进一步提升性能问题（包括保证数据库事务处理），是大型应用软件的业务基础平台必须要解决的一个问题，不能仅仅是为了组件化而组件化，如果不能解决性能问题，组件化就不能在大型的应用系统中得到广泛应用，因此需要根据在实际开发过程中碰到的不同的场景，采用不同的调用方式，除了组件化中提到的服务，还有要有其他的方式作为补充，即能实现松耦合，又可以保证性能，实现不同层次的不同调用。

实现组件化，首先要定义清晰、简单的业务组件界面，特别是业务组件和公共组件之间的界面，然后建立一个兼顾松耦合、性能的调用方式及不同的调用方式的标准。在《 SOA 和 ROA 》描述了业务组件接口模型，除了人机交互界面（没有组件之间的调用关系），组件之间的调用关系主要有服务接口和数据接口两种。如下图所示：

图 5. 业务组件接口模型

![70 4][]

在上述接口模型中，组件的接口是面向集成平台的，在组件化业务基础平台组件模型中，由于是基于一个统一业务基础平台，因此可以增加一个通过 API 调用的接口方式，提高调用效率和保证事务处理，同时为了进一步优化性能，服务接口可以分成重量级的 SOAP 和轻量级的 REST 两种，因此可以把组件之间的调用关系进一步分成四种（如下图所示）。在不同的层级，从性能和耦合性两个角度，组件间可以选择不同的调用方式， 具体采用那种调用关系主要是考虑性能、接口复杂度、耦合性等问题，不同的业务组件，特别是不同的厂商之间开发的组件采用基于 SOAP 的服务，同一个厂商开发的不同组件之间通过 REST 服务进行调用或者直接采用数据接口进行调用。一个业务组件内部，业务组件和公共模块之间的调用，以及为了保证事务处理，直接通过在不同的业务组件中内嵌模块的方式，实现 API 调用，如下图所示：

图 6. 组件化业务基础平台接口调用方式

![70 5][]

*  基于 SOAP 的服务接口：通过 SOAP 的 Web 服务调用，适用于不同的业务组件之间，特别是不同厂商开发的业务组件、不同平台的业务组件以及新建的业务组件和遗留系统之间的调用。SOAP 的服务接口有相关的标准支持，可以支持更多的平台和厂商。
 *  基于 REST 的服务接口：同平台、同厂商开发的业务组件之间的调用，特别是同一个组件中界面和业务逻辑之间的调用，从而实现界面和业务逻辑分离。REST 服务是轻量级的服务调用，主要用于提高性能，简化开发。

业务组件之间于 SOAP 的 Web 服务调用或者 REST Web 服务调用，因为基于 SOAP 的 Web 服务拥有众多的标准，可以方便的实现跨平台调用，适用于不同厂商之间的业务组件调用，同一个厂商之间的不同组件调用可以直接通过能够提供很好性能的 REST Web 服务调用。

*  基于 API 的调用 ，业务组件内部不同模块之间的；业务组件和基础平台的内核之间；不同的业务组件之间需要紧密结合事务处理的调用，通过 API 调用实现，保证系统的事务处理和系统性能。

不同的业务组件之间需要事物处理的调用，通过内嵌一个内核业务处理模块的方式进行，如库存处理相关业务，在订单模块和采购模块都需要调用，通过服务方式很难处理事物，可以将一个简化的库存模块（如 Jar 包，建议采用 OSGi 架构，WAS8 已经提供了很好的支持）直接内嵌到订单模块和采购模块，如下图“库存模块内嵌到订单和采购业务组件”所示；工作流引擎也可以采用这样的方式，详见《基于 SOA 的工作流（WF）整合》的说明。

*  基于数据接口调用：同平台、同厂商开发的业务组件，可以直接通过数据视图调用，简化接口关系，特别开发比较紧密的小组开发的组件之间调用、大数据量的数据调用。不同的业务组件之间，纯粹的数据调用，可以直接通过数据接口方式进行调用

图 7. 库存模块内嵌到订单和采购业务组件

![70 6][]

界面组件和业务逻辑组件应该是可以完全独立的，在完全实现组件化业务基础平台中，界面组件应该是可以独立部署的，界面组件和业务逻辑组件之间通过 REST 的服务交互，详见《 SOA 和 ROA 》所描述的架构说明。业务逻辑组件可以没有任何界面，完全独立于界面显示，实现界面和业务的分离。在 J2EE 环境中，完全可以实现业务组件全部由 Jar 包组成，不含任何界面内容，界面组件则完全采用 JSP 实现。

基于数据接口调详见《 SOA 和 DW 》关于共享库的描述，在实现所有的组件公用一个数据库的基础上，不同业务组件需要确定数据接口作为共享标准（如下图所示深蓝色部分流程、系统、主数据、业务一、业务二、···），其中有些数据是不需要在不同的业务组件进行共享的，则属于组件内部的数据，（如下图所示淡蓝色部分流程、系统、主数据、业务一、业务二、···），对于业务基础平台所包含的业务组件流程、系统、主数据也采用这样的方式，可以保证业务基础平台向下兼容的进行独立升级，而不会影响到其他的业务组件。

图 8. 数据接口实现思路

![70 7][]

内部服务总线可以不同于当前商业 ESB，采用比较复杂的服务总线产品，内部服务总线为了提高性能，可以采用简化处理，仅仅实现服务路由的功能，甚至仅仅实现一个服务注册管理即可。简化处理主要是解决当前 ESB 所遇到的性能问题，如果没有服务动态变化的需求，可以不考虑服务编排的问题。

### 业务基础平台组件版本 ###

为了保证业务组件的灵活的扩展，还有一个很重要的因素，就是版本的兼容，要实现以上不同层次的接口调用的向下兼容，包含服务接口、API 接口、数据接口，即升级之后的应该和老版本可以兼容。特别是数据库接口，必须实现向下兼容，不然无法实现一体化数据库，造成升级困难。数据接口并非是所有的数据模型，主要是针对核心对象模型建立的对象基本关系模型，关于基础对象模型的建立，可以参见《基于面向对象（OO）的数据库设计模式探讨 1、2 》所描述“对象关系模型”建模的思路，建立更加稳定的数据模型，保证数据接口的稳定。后续文章会进一步的描述关于建立通用数据模型的思路。

实现了四个层面的接口向下兼容的，组件就可以独立升而不会相互影响，保证不同业务组件的版本兼容，对于一个业务组件内部，不同的模块之间，需要保证版本一致，如业务基础平台的内核，需要跟业务组件的版本保持一致。保证一个和业务组件本身的版本兼容，不同的业务组件之间可以版本不同，但是数据结构要兼容。

图 9. 不同版本的业务基础平台整合

![70 8][]

## 业务基础平台和集成平台 ##

通过以上分析可以看到，组件化业务基础平台和集成平台有所不同，基于一个业务基础平台构建一体化系统有着诸多的限制，和集成平台相比组件化业务基础平台需要更多的标准（如 API、数据接口等），限制也更加严格，尤其是针对不同的厂商，同时适应这些标准比较困难，因此更适合用于同一个厂商内部的不同业务组件之间的一体化。不同厂商的系统或者业务组件，遗留系统，则需要通过集成平台进行集成，来搭建一体化系统。通过集成平台，采用通用的标准，对系统进行简单的改造就可以实现集成。

为了使组件化业务基础平台具有更加广泛的应用，可以进一步完善，实现对跨数据库的管理，用于解决超大型的应用对性能的要求，业务数据可以分别部署在多台机器中，数据库有多个实例，分散数据库的压力。同时可以支持在遵循所有相关标准的基础上其他厂商的业务组件，如果实现多个厂商基于一个基础业务平台开发，需要其他的厂商的紧密配合。如下图所示：

图 10. 不同厂商的组件通过集成平台进行整合

![70 9][]

注：如果部署两个数据库，考虑到性能问题，需要考虑将公共组件的数据复制一份到独立部署的数据库中，特别是主数据、权限数据等，跟业务紧密相关，具体实现方式不在本文探讨的课题。

## 总结 ##

相比传统的业务基础平台，组件化业务基础平台能够实现业务基础平台组件之间以及业务组件之间的松耦合，可以实现：

1.  因为业务基础平台内核分离出来，业务基础平台可以独立升级，不会影响到业务组件运行和开发，这样保证了资产的复用，不至于业务基础平台升级后，业务组件也必须跟着升级，减少不必要的重复开发。
2.  每个业务组件可以独立升级，不会影响其他的业务组件，基于松耦合的组件化开发，不同的业务组件之间通过标准的接口调用，接口是标准的，不需要对所有的业务组件进行升级。
3.  业务基础平台可以独立部署，独立部署之后，可以整合其他厂商基于开放标准开发的业务组件，从而实现企业级的集成平台（需要数据集成和应用集成平台支持）。

[70]: /images/20220511/bcc6ba121f7d4bd99104a79c9c55fad9.png
[70 1]: /images/20220511/0d366098f0bb43c7a84f41bb7e25f65a.png
[70 2]: /images/20220511/01b13e4faf8643e49b4b0db55847b6e2.png
[70 3]: /images/20220511/37c7f72a3eec48f1a6f95b6fe35d5102.png
[70 4]: /images/20220511/99baf8c6096647eea995bf64265e4e36.png
[70 5]: /images/20220511/86b2387caded46b2afc73123f69f5353.png
[70 6]: /images/20220511/311014d209df4a61a22b282571ee09f6.png
[70 7]: /images/20220511/aad7cfba39cb4894b81bf6e42533e7b7.png
[70 8]: /images/20220511/37f1c31f690f4d8b96b203ed3ed0f1b9.png
[70 9]: /images/20220511/463f2a84676d47e7808dbae7d4173c2f.png