农业银行：打造企业级规则管理平台

规则引擎的出现，打破了传统设计上的数据和逻辑的紧耦合关系，统一管理系统内涉及的多种规则，业务技术协同提高了研发效率，快速应对因监管规定、管理要求、市场竞争带来的需求持续变化，同时保持系统技术框架、逻辑结构的稳定性。最终在实现对业务需求快速响应的同时，确保系统运行的稳定性，整体节约了系统建设运维的成本。

一、现状问题及应对思路

        1．现状问题

        随着银行内部对规则引擎产品的运用增多，应用范围日渐扩大，规则项目数量增多，在整个银行IT系统应用层面普遍出现以下四方面的问题。

        （1）全行规则分散无法统一管理。业务规则是银行的核心资产之一，各应用系统管理这些核心资产的方式各有不同。由于规则引擎的项目都是各自独立部署，各项目的核心规则散落在各自的应用系统，无法进行统一管理。

        （2）缺乏供业务编辑规则的成熟环境。虽然ODM（IBM的一个规则引擎产品）提供了组件可供业务独立编辑和发布规则，但由于行内缺乏成熟的管理流程，没有可靠的规则管理环境，至使各个项目的业务人员基本未能参与到业务规则的修改中。

        （3）开发人员集成难度较大。ODM产品提供了多种方式的应用与规则引擎的集成方式，集成细节繁琐，各项目组所花费的时间和人力成本较多，新产品运用有风险。

        （4）新项目组的学习成本过高。项目组在使用规则引擎时，面临巨大的学习成本。一是对规则引擎产品的适用场景不清晰；二是规则引擎项目的完整实施过程不明确；三是缺乏统一的设计开发规范。项目存在较多未知风险。

        2．解决思路

        研究发现，同样的问题在国内外同业中都有遇到。各同业银行在规则引擎产品的应用方面持续积极探索，逐渐从分散应用走向集中，意在通过实现企业级规则服务中心以改变上述问题。农业银行软件开发中心项目组基于此思路，打造了一个全行统一、易于集成的规则服务中心，命名为“业务规则智能服务云”。

        方案基于云服务的设计思路，云计算实际是将计算分布在大量的分布式计算机上，而非本地计算机中。因此服务云将把业务对规则的管理统一集中化，而各应用的执行服务仍分布运行以保证各应用系统的独立性和完整性。

        由于是基于云服务的设计思路，即“一对多”的模型设计，通过简单的接入方式轻松接入。服务云在原有的ODM产品外封装一层易用的统一接口，采用通用的设计模式适应多类型的系统接入，以最小的投入支撑更大的需求。

        服务云的实现，将原有的“以设备为中心”的规则引擎实施模式，转向“以信息为中心”的模式。服务云的建设，对应用系统而言屏蔽了具体的规则执行环境，项目组将更少关心具体的集成细节，而是将更多的精力集中到对业务规则的梳理与设计中。

二、业务规则智能服务云

        根据上述解决思路，农业银行搭建了企业级的规则服务云并配套了相应的实施指南及规范。智能服务云一方面为新开发的规则项目提供从需求分析至上线运维的实施参考，另一方面为现有规则项目的优化和整合提供帮助。

        1．规则服务云架构

        （1）逻辑架构。规则服务云通过统一的调用接口，与各规则项目的应用系统进行数据交互。统一调用接口对数据进行安全性校验，并将对调用情况进行监控记录，将数据分发给各决策执行环境（如图1所示）。决策执行环境根据应用的需要分布部署，在执行环境中得到的输出数据，由通用接口分发回各应用系统。决策执行环境中的规则将同步给统一的规则库保存，业务用户可以通过统一的规则配置服务云查看和管理规则库中的规则。

        （2）应用架构。规则服务云为规则管理用户提供规则管理功能，如图2所示。服务云为各应用系统提供管理功能，包括统一的调用接口、规则项目的运行监控、日志的统计分析等功能。服务云的设计同时考虑满足各系统相应的非功能需求，包括访问控制、权限管理、日志和备份等功能。

        2. 统一的调用接口

        （1）接口实现逻辑。为了简化基于规则引擎的项目集成部署工作，规则服务云提供了一套统一的调用接口，各应用系统能够便捷地实现与规则引擎的通信，大大减轻了规则项目集成的难度与工作量。统一接口的存在，隔离了众多业务平台与规则引擎计算之间的复杂交互，统一并简化了接口调用的传输协议，支持业务平台通过JAVA、C、C#、CICS等多种开发语言及开发框架进行调用。

 1 2 下一页 尾页

扫码即可手机
阅读转发此文