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

本文涉及的产品
数据管理 DMS,安全协同 3个实例 3个月
推荐场景:
学生管理系统数据库
简介: 原文:基于 SOA 的组件化业务基础平台 前言 业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层,解决 “应用软件的业务描述和操作系统平台、软件基础架构平台之间的交互与管理问题”。
原文: 基于 SOA 的组件化业务基础平台

前言

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

业务基础平台

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

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

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

业务组件和公共组件

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

组件化业务基础平台

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

传统的业务基础平台

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

图 2. 业务基础平台模型

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

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

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

组件化业务基础平台

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图 5. 业务组件接口模型

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

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

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

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

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

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

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

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

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

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

图 8. 数据接口实现思路

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

业务基础平台组件版本

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

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

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

业务基础平台和集成平台

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

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

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

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

总结

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

  1. 因为业务基础平台内核分离出来,业务基础平台可以独立升级,不会影响到业务组件运行和开发,这样保证了资产的复用,不至于业务基础平台升级后,业务组件也必须跟着升级,减少不必要的重复开发。
  2. 每个业务组件可以独立升级,不会影响其他的业务组件,基于松耦合的组件化开发,不同的业务组件之间通过标准的接口调用,接口是标准的,不需要对所有的业务组件进行升级。
  3. 业务基础平台可以独立部署,独立部署之后,可以整合其他厂商基于开放标准开发的业务组件,从而实现企业级的集成平台(需要数据集成和应用集成平台支持)。
相关实践学习
MySQL基础-学生管理系统数据库设计
本场景介绍如何使用DMS工具连接RDS,并使用DMS图形化工具创建数据库表。
目录
相关文章
|
5月前
|
监控 负载均衡 安全
构建高效微服务架构的五大核心技术实践
【4月更文挑战第2天】 在当今软件开发领域,微服务架构已成为构建复杂系统的首选模式。它通过将大型单体应用拆分成一系列小型、自治的服务来提高可维护性和扩展性。本文深入探讨了构建高效微服务架构的五大核心技术实践,包括服务拆分策略、API网关设计、服务发现与注册、熔断机制以及分布式追踪与监控。文章不仅分享了实践中的经验教训,还提供了实施这些技术时的具体建议和最佳实践。
|
5月前
|
监控 Java 测试技术
现代化软件开发中的微服务架构设计与实践
随着软件开发的发展,传统的单体应用架构已经无法满足现代化应用的需求。微服务架构作为一种新的设计理念,为软件开发提供了更灵活、可扩展的解决方案。本文将介绍微服务架构的设计原则、实践方法以及相关技术工具,并结合实例展示其在现代化软件开发中的应用。
|
21天前
|
缓存 负载均衡 数据管理
深入探索微服务架构的核心要素与实践策略在当今软件开发领域,微服务架构以其独特的优势和灵活性,已成为众多企业和开发者的首选。本文将深入探讨微服务架构的核心要素,包括服务拆分、通信机制、数据管理等,并结合实际案例分析其在不同场景下的应用策略,旨在为读者提供一套全面、深入的微服务架构实践指南。**
**微服务架构作为软件开发领域的热门话题,正引领着一场技术革新。本文从微服务架构的核心要素出发,详细阐述了服务拆分的原则与方法、通信机制的选择与优化、数据管理的策略与挑战等内容。同时,结合具体案例,分析了微服务架构在不同场景下的应用策略,为读者提供了实用的指导和建议。
|
5月前
|
敏捷开发 监控 持续交付
构建高效微服务架构:后端开发的现代化之路
【5月更文挑战第28天】在云计算和容器化技术日益成熟的当下,微服务架构已成为企业追求敏捷开发与部署的重要解决方案。本文将深入探讨微服务的核心概念、设计原则以及实施步骤,并通过具体案例分析如何利用现代后端技术栈构建和维护一个可扩展、高可用的微服务系统。我们将讨论微服务带来的优势,如提高系统的弹性、促进团队协作和加速创新过程,同时也会指出其潜在的挑战,包括服务治理、数据一致性等问题。
|
5月前
|
监控 安全 数据管理
构建高效微服务架构的五大核心要素
【5月更文挑战第27天】在现代软件开发中,微服务架构以其灵活性、可扩展性和容错性而受到企业青睐。本文将深入探讨构建一个高效微服务架构所需的五大核心要素:服务划分策略、通信机制、数据管理、安全性和监控与日志系统。这些要素是确保微服务架构能够高效运行并适应快速变化需求的关键。我们将逐一解析每个要素的重要性及其实现方法,为后端开发者提供一套全面的指导原则和实践技巧。
|
5月前
|
Kubernetes API 开发者
构建高效可扩展的微服务架构:后端开发的新趋势
【5月更文挑战第28天】 在数字化转型的浪潮中,企业对软件系统的要求越来越高。微服务架构因其灵活性、可扩展性和敏捷性而成为解决复杂系统问题的热门选择。本文深入探讨了微服务架构的设计原则、关键技术和实施策略,旨在为后端开发者提供构建和维护高效微服务系统的实用指南。通过对容器化、服务发现、API网关等技术的剖析,揭示了如何优化系统性能、提高可靠性并简化运维流程。
|
5月前
|
API 持续交付 开发者
构建高效微服务架构的五大关键技术
【5月更文挑战第20天】 在当前数字化转型的浪潮中,微服务架构因其灵活性、可扩展性而成为众多企业的首选。本文深入剖析了构建和维护高效微服务架构的五大关键技术:容器化技术、服务网格、API网关、持续集成/持续部署(CI/CD)和分布式追踪。通过这些技术的整合使用,可以显著提高系统的可靠性、弹性及开发效率。
|
5月前
|
监控 安全 数据管理
现代化后端开发:微服务架构下的数据管理与安全挑战
随着信息技术的不断发展,现代化后端开发正日益注重微服务架构下的数据管理与安全挑战。本文将探讨微服务架构在后端开发中的应用,重点关注数据管理和安全方面的挑战,并提供相应的解决方案。
|
10月前
|
监控 Cloud Native 容灾
下一代软件架构该如何搭建微服务核心能力
随着数字化时代的来临,各种架构设计思想确实如雨后春笋般涌现,给软件开发领域带来了百家齐放的局面,但是软件开发领域也正面临着前所未有的挑战,比如微服务架构、云原生架构、Serverless架构、事件驱动架构、中台架构、容灾架构等,都在不同场景下展现出了独特的优势。尤其是从事云原生领域的开发者来说更有发言权,因为在裁员潮来临的时候,科技公司先要“下手”的就是云原生、容器化等领域。但是话又说回来,传统的单体应用架构已经无法满足现代软件需求的快速变化和高可靠性要求,在这种情况下,微服务架构作为一种分布式系统设计方法,逐渐受到技术圈的关注和应用。那么本文就来简单聊聊下一代软件架构如何搭建微服务的核心能力
69 2
下一代软件架构该如何搭建微服务核心能力
|
11月前
|
自然语言处理 Cloud Native 安全
下一代软件架构,如何构建微服务核心能力
下一代软件架构,如何构建微服务核心能力
433 8
下一篇
无影云桌面