浅谈企业服务整合平台系统建设

开发 项目管理
企业服务整合平台作为服务整合技术支撑类平台,目前已投入生产运行半年之久,取得了一定的效果,全链路自动化的处理流程大大缩短了业务场景处理时间。

一、背景介绍

近两年G行分布式服务体系能力不断提高,初步形成服务化生态;服务网格、容器云、虚拟化技术逐步在生产环境实施及推广,为服务整合的实现提供了有效的技术支撑。与此同时,随着G行业务快速发展,应用系统数量快速增加、系统间调用关系日趋复杂;整合场景和业务需求的数量和复杂度均持续增加;投产频度增高、周期缩短,敏捷发布常态化。为适应业务发展和科技能力提升的需要,企业服务整合平台应运而生。

二、平台建设目标

此前G行分布式服务体系缺少具备统一规范的服务整合技术支撑平台和相应的可共享服务整合能力。而G行的分布式服务体系已涵盖超过60个系统,近100个服务,形成了一定生态规模,因此启动了企业服务整合平台的建设。企业服务整合平台建设主要有以下关键目标:

填补能力空白,建立分布式服务体系下的服务整合能力,提供可共享的公共业务能力整合,提升业务需求实现的质量和效率。

推进服务治理,丰富企业服务治理工具和手段,立足平台展开服务治理试点延伸。

降低体系内业务服务开发复杂度,提升研发效率,形成分布式服务体系业务设计、开发、测试、发布、运维的全生命周期研发模式,提升G行业务需求开发效率,增强企业竞争力。

复用解决方案,降低业务服务设计及实施复杂度,建立共享的服务整合实现案例库。

三、企业服务整合平台系统设计

3.1系统间功能分布设计

结合G行服务化转型架构规划及分布式服务体系建设现状,企业服务整合平台将负责分布式服务体系服务整合场景的实现和以服务接口形式的整合功能发布。相关整合场景以多个服务接口自动化调用处理的短流程模式,形成局部可共享的业务能力。

基于企业视角,统筹规划,建设通用服务整合平台,通过服务编排实现服务整合,组合后生成的新服务注册至企业分布式服务平台,相关服务也可被再次组合,形成专业应用服务之外的组合服务能力。

图片

3.2重要功能模块及分布

整合场景设计开发模块

整合开发IDE和平台设计开发管理流程,在过程中,形成整合场景资产沉淀。包括整合工程需求关联、设计描述、测试案例,将跟随服务整合工程完整生命周期,进行规范化资产化管理。

整合场景综合管理模块

针对已投产服务整合工程形成的服务接口,进行全生命周期管理;根据服务接口被调和主调关系,对接口及逻辑变更进行分析和流程化管理;针对服务整合场景调用SLA进行统计分析,结合调用关系支持进一步服务治理。

平台运维监控模块

提供平台、节点、整合工程场景粒度的监控和运维能力。包括基于脚本的人工应急处置机制。

平台应用网关

平台应用网关除分布式服务体系集成、接口发布、负载均衡能力外,计划实现可配置路由、流控、接口鉴权等升级能力。

批量对账服务模块

实现对账业务场景。

平台整合场景运行实例节点

图片

基于平台微服务运行框架,实现基于容器云、应用运行框架,支持服务整合工程场景粒度的接口发布和运行。

四、面临的主要问题及解决方案

企业服务整合平台作为基于业务场景提供交易请求的系统,会遇到各种各样的交易和业务场景,那么如何对各业务场景进行解耦,如何处理慢交易等特殊业务场景,以及当整合平台的业务场景达到一定规模时候如何进行扩缩容,都是非常值得思考并通过细致设计加以解决的问题。为此,企业服务整合平台提供了分组路由、平台孵化等机制应对这些问题。

平台网关分组路由机制

目前G行自主研发平台基于原生Spring Gateway实现分组化路由,企业整合平台将在此基础上补充基于服务名和业务场景的后台服务分组路由功能。企业服务整合平台针对慢交易等特殊业务场景,设置特定的运行节点组或者独立子应用服务单元,独立运行这类交易场景。同时企业服务整合平台采用全栈VBC容器云环境部署,可以实现运行节点灵活扩容,形成临时分组。

企业整合平台孵化机制

图片

当平台基于业务域积累一定规模业务场景案例后,企业服务整合平台即可提供服务灵活拆分及领域孵化机制。如该应用具备孵化条件,可独立立项拆分,从企业级服务注册中心申请新服务名,采用服务整合平台相同的技术架构,自平台分离或新建应用和数据库资源进行独立部署,形成全新的某业务领域服务整合平台。

五、平台服务架构原则

企业服务整合平台提供大量业务交易整合场景,确定服务集成范围及集成原则将至关重要。基于此,企业整合平台提出了平台整合服务原则和应用服务原则,作为对业务场景接入整合平台、服务子应用化和整合平台业务域孵化的依据。

平台整合服务原则:

  • 服务共享原则:整合后场景接口原则上其应用场景具备为多个消费方提供服务的可能。
  • 服务整合原则:整合场景调用接口应来自两个或两个以上服务(系统),且整合场景中单一服务所提供接口不应超过50%。(除总前服务交换网关)该场景应优先由后台服务进行整合。
  • 服务范围原则:整合平台向分布式服务体系内作为整合场景调用方的应用提供整合服务,且不直接向各类客户端或业务人员直接提供服务能力。
  • 数据处理原则:由于平台围绕服务整合流程进行处理,所有业务场景所需业务数据均依赖相关后台服务通过服务接口提供。
  • 逻辑处理原则:整合平台具备提供整合过程中的简单业务逻辑处理,如遇复杂逻辑实现的场景,应由后台服务提供相关能力

平台应用服务原则:

  • 平台实施优先级原则:服务整合平台主要为企业通用整合场景提供服务化支持,自治子应用在未成熟前在平台实施。随相关应用发展,在规模和复杂度具备独立提供服务条件,则申请通过架构评审独立迁出相应服务能力。
  • 平台子服务解耦原则:存在提供基于主数据的非整合性质服务接口和其它服务能力,该类应用将采用微服务模式作为平台子服务,计算和数据库资源同平台整合服务独立解耦。子服务仍依赖企业服务整合平台统一对外发布接口。

六、集中交换体系交易整合迁移策略思考

目前G行集中交换体系交易整合场景随着前后台系统服务化,将逐步迁移至分布式服务体系。针对不同业务场景情况,其迁移策略分为以下几类:

图片

1.直接孵化领域整合平台:已具备成熟领域能力,可直接形成新的专业领域整合平台服务。服务调用方已在分布式服务体系内的领域整合场景,可参考企业服务整合平台技术架构,进行迁移构建。

2、迁移至企业服务整合平台:未成熟领域整合场景迁入企业服务整合平台。如服务调用方已在分布式服务体系内,可迁移相关场景,支持体系内应用。

3.独立演进成为独立应用服务:具备独立业务特征的应用应独立发布企业级服务。随着服务化展开,服务调用方已在分布式服务体系内,具备可形成独立应用服务,包括业务主数据的应用,建议独立发布服务或应用子服务。

七、总结与展望

企业服务整合平台作为服务整合技术支撑类平台,目前已投入生产运行半年之久,取得了一定的效果,全链路自动化的处理流程大大缩短了业务场景处理时间。同时我们对整合平台的未来进行了规划与思考,尤其是在业务场景的规划与设计方面。平台将不断丰富业务场景整合,扩展业务范围,编排更复杂的业务场景。同时平台将做好业务场景间的解耦,充分用好容器云资源和微服务架构优势将业务场景更加细粒度化,充分保障各业务场景平稳运行,使其在G行分布式架构转型中发挥更大的作用。

责任编辑:武晓燕 来源: 匠心独运维妙维效
相关推荐

2022-09-19 21:10:25

CRM销售管理系统

2013-04-26 15:13:49

企业漏洞漏洞收集

2023-01-13 16:46:38

CRM系统建设

2022-11-02 10:06:25

CRM系统建设LTC

2022-03-04 06:36:35

数据能力数据分析

2016-08-31 13:48:30

联想

2012-02-27 13:45:47

联想R680-G7GIS联想服务器

2012-03-07 09:57:22

开放平台

2010-11-04 09:57:15

视频通讯应急管理RADVISION

2022-08-14 14:41:57

系统建设实践

2009-05-25 14:53:18

通信系统应急系统捷思锐

2021-01-15 11:15:17

智能工厂信息化系统规划

2019-08-08 08:51:53

安全流量AI

2010-01-05 15:56:12

保险公司灾备系统

2013-04-28 10:51:09

企业漏洞漏洞收集平台

2024-01-15 07:36:46

AI系统监控系统

2013-08-09 10:17:42

谷歌绿色数据中心数据中心

2011-05-13 08:43:31

农信社ITJP1

2016-09-22 11:49:13

2012-11-14 13:41:17

信息化网络
点赞
收藏

51CTO技术栈公众号