CN101242299A - 数据枢纽—业务支撑***网络化方法 - Google Patents
数据枢纽—业务支撑***网络化方法 Download PDFInfo
- Publication number
- CN101242299A CN101242299A CNA2007101351382A CN200710135138A CN101242299A CN 101242299 A CN101242299 A CN 101242299A CN A2007101351382 A CNA2007101351382 A CN A2007101351382A CN 200710135138 A CN200710135138 A CN 200710135138A CN 101242299 A CN101242299 A CN 101242299A
- Authority
- CN
- China
- Prior art keywords
- database
- hinge
- data
- business
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明提出了一种数据枢纽—业务支撑***网络化方法，该方法采用N+1体系结构，首先N个节点数据库存放各自管辖城市的用户数据，将分散在N个节点数据库里的用户资料表、客户资料表每15分钟通过数据库技术增量复制到1个枢纽数据库中，建立全局的用户资料表、客户资料表视图，并将跨区业务数据存放在1个枢纽数据库中；其次通过枢纽库变复杂网状复制关系为简单星形关系的功能实现***可通过配置调整快速线性增加节点扩容；再次通过枢纽数据库建立统一客户资料管理平台和数据提供中心，通过枢纽库的统一接口实现对外按需订阅和按需发布。
Description
技术领域
本发明属于通信运营商的信息***建设领域。涉及的是一种在信息***建设中采用的体系结构和数据管理的技术实现方法，以提高***平滑扩展性、可靠性、数据共享性和服务灵活性。该发明创造可直接应用于各通信运营商对其业务运营支撑***的建设领域，也可进一步推广到银行、电力、保险等行业的大型IT***的建设领域。
背景技术
1、***江苏公司BOSS(业务运营支撑***)***支撑3000万移动用户，2万台营业终端，2800台自助打印机和自助充值终端，日处理话单3.5亿条，日受理业务400万笔，是生产服务的重要保证，已成为企业的核心竞争力之一。BOSS***目前分地市部署在4个数据库的体系结构，在后续业务量增加时，即将达到每个库的容量支撑瓶径，通过设备扩容无法支持，需要其他手段的创新来提升支撑能力。
2、***广东、浙江等其他省公司的业务支撑体系也逐步出现单库支撑用户量到达瓶径和单库业务量增加而稳定性日益降低的现象，迫切需要解决。
3、由于中国人口基数庞大，一个省的移动电话用户数就超过绝大多数国外一个国家的移动电话用户数，***拥有移动电话用户3亿，已是全球用户规模最大的电信运营商。所以国外电信运营商的业务运营支撑***大都采用单库结构，其规模和复杂度要远低于***的业务运营支撑***，需要国内电信运营商作出积极的探索和创新。
发明内容
为了弥补现有技术的不足，本发明提出了“数据枢纽--业务支撑***网络化方法”，包括以下步骤：
步骤一、将用户号码、帐单信息、资费套餐、业务功能等所有数据按照用户所属不同城市分别存放在N(N＞＝2)个节点数据库里；
步骤二、建立1个枢纽数据库；
步骤三、将分散在N个节点数据库里的用户资料表、客户资料表通过数据库技术复制到枢纽数据库中，建立全局的用户资料表、客户资料表视图；
步骤四、将跨区一卡双号、跨区集团、跨区亲情号码等跨区业务数据存放在枢纽数据库中；
步骤五：在应用服务器上部署中间应用程序连接N个节点数据库和1个枢纽数据库；部署在接入服务器上对外提供最终服务的接入服务程序连接应用服务器上的中间应用程序；
步骤六、当用户办理不是步骤四里包含的跨区复杂业务时，输入手机号码(或证件号码)后，路由选择模块先查询本地节点数据库的本地的用户资料(或客户资料)，如查询到则返回归属节点数据库编号为本地节点数据库；如在本地查询不到，则再自动连接到枢纽数据库查询由各节点数据库复制过来组成的全局用户资料(或客户资料)，并返回手机号码(或证件号码)所真正对应存放的的归属节点数据库编号。转到步骤八。
步骤七、当用户办理里的是步骤四里包含的跨区复杂业务时，则将枢纽数据库编号返回为归属节点数据库编号。
步骤八、根据步骤六返回的归属节点数据库编号，中间层应用程序自动路由到对应的节点数据库根据用户申请的业务逻辑进行数据修改操作，完成用户申请的开户、充值、业务变更等业务；或根据步骤七返回的归属节点数据库编号，中间层应用程序自动路由到枢纽数据库，完成跨区复杂业务的数据修改工作。
上述的“数据枢纽一业务支撑***网络化方法”，其进一步特征在于N+1体系结构：
1、通过N个节点数据库的使用，使得***的可靠性大大提高，因数据按地市分在N个节点数据库上，所以单节点处理性能高，同时保证当某一节点出现软硬件故障及***扩容调整时，不会影响到其他节点所承担地市的业务。示意图见图1。
2、由于增加了1个枢纽库，将N个节点的网状数据复制交互关系删除，变成N个节点只与枢纽库交换，今后业务量增加时，只需通过调整配置(不需修改程序)将部署在应用服务器上的中间应用程序新增连接到新的节点数据库即可，可在一周内完成新的节点数据库的增加和应用上线工作，解决了目前各运营商普遍遇到的支撑容量线性快速提升难的重大难题。示意图见图2、图3及图5。
3、拓展枢纽数据库功能，使得其成为全局的统一客户资料管理平台及数据交换和供应中心，实现及时全面准确的按需订阅和按需发布，而对外屏蔽各信息来源什么平台、物理结构如何、存放位置等。示意图见图4和图6。具体步骤如下：
a)通过枢纽数据库，实现客户数据(包括客户资料、帐单信息、清单信息、梦网订购关系、历史活动信息等)全局视图，建立统一客户资料管理平台；
b)经营分析、10086客服等其他***可通过枢纽数据库提供的统一订阅接口进行订阅；
c)枢纽数据库通过自身统一提取模块从各节点数据库和其他数据库根据******的订阅需求提取和组合信息；
d)枢纽数据库通过统一发布接口向******发布提取和组合的信息，满足订阅需求。
本发明的有益效果：
本发明创造的“数据枢纽--业务支撑***网络化方法”有以下四个有益效果：
1、创新的大型IT***的N+1数据库体系结构，有效的解决了大型IT***容量线性提升和高稳定性的难题，保证了***的高稳定性和可线性平滑扩容，并可推广到集团内其他省公司或银行、税务等其他行业的大型IT***。
2、建立统一客户资料管理平台，实现按需订阅。实现客户资料全局视图，其它***可以通过枢纽库简单、准确、及时提取到所需信息，无需知道其后是什么平台、物理结构如何、存放位置等，保证了数据消费的全面性、一致性、及时性和安全性。
3、快速灵活支撑省内跨市和国内跨省复杂业务。将跨地亲情号码、短号集团等复杂业务，存放枢纽库上作为全省共享数据；枢纽库作为对外统一接口，跨省办理的缴费、换卡等业务请求都统一提交到枢纽库，由其分发到目标省或本省对应的数据库。
4、通过N+1体系结构的使用，为IT支撑***向电信级和网络化发展提供了有力保证。
该技术的使用使得可通过配置调整增加节点快速平滑扩容和业务支撑***稳定性大大提高，平均故障时长由原来的每月1小时降低到每年0.6小时，并进一步节省设备投资，带来的直接和间接经济效益约为每年1003万元；并能支持跨区业务的快速灵活推出、BOSS数据的统一安全管理，保证了业务和服务领先，同时在客户中进一步树立了***优质服务的形象，更提高了广大用户的满意度和忠诚度，进一步使业务支撑网的领先优势成为***的核心竞争力之一。
附图说明
图1为本发明实施例中业务支撑***体系结构演变渐进图；
图2为本发明实施例中N+1的体系结构图；
图3为本发明实施例中***线性快速平滑扩容图；
图4为本发明实施例中统一客户资料平台示意图；
图5为本发明实施例中业务支撑***中间应用层示意图；
图6为本发明实施例中数据按需订购和数据发布流程图。
具体实施方式
下面结合附图和实施例对本发明进一步描述。
1、枢纽数据库的物理设计
数据库名：hubdb
实例名：hubdb1/hubdb2
存储空间：300G
内存参数
物理内存：42G，数据库SGA及PGA参数设置如下：
| 参数名 | 内存大小(M) |
| sga_max_size | 24576 |
| shared_pool_size | 1536 |
| db_cache_size | 20480 |
| db_keep_cache_size | 2048 |
| large_pool_size | 256 |
| java_pool_size | 32 |
| log_buffer | 16 |
| pga_aggregate_target | 2048 |
| db_block_size | 8192 |
| Processes | 2000 |
| job_queue_processes | 30 |
| db_files | 2000 |
2、双实例枢纽数据库的分担策略选择
枢纽数据库为一个独立数据库，使用ORACLE RAC技术，建立两个实例，可互相接管，每个实例的职责由枢纽数据库使用策略决定，使用策略为按功能分担。枢纽数据库的两个实例的使用策略有以下两种：
A.但地市分担策略
生产***各类应用同时使用枢纽数据库的两个实例，按照BOSS***数据库目前地市划分原则，枢纽库一号实例为如下地市：南通、扬州、泰州、盐城、南京、徐州、连云港；枢纽库二号实例为以下地市：镇江、常州、无锡、宿迁、淮安、苏州。
B.按职责分担策略
根据生产***应用类型，分别使用不同枢纽库实例：所有的中间件服务器、Web服务器等OLTP联机应用全部使用枢纽库一号实例；出帐进程、资料同步进程、数据库资料复制、数据订阅和发布等BATCH应用使用枢纽库二号实例。
考虑隔离对生产***OLTP在线交易的影响和应用程序配置的简单性，采用按职责分担的策略。
3、与程序无关的底层数据库复制技术
各节点数据库将用户资料表(以手机号码为关键字)和客户资料表(以证件号码为关键字)复制到枢纽数据库，由枢纽数据库组合成统一的全局视图，供开户、充值等OLTP联机业务实时访问，也为***的其他***提供统一访问视图。由于采用的是与程序无关的底层数据库复制技术(ORACLE的物化视图)，而使***简单、高效和稳定，并具有较大的可迁移性和推广价值。
4、复制的必要性分析
因为用户到任一节点数据库所辖市办理业务，必须在任一点查询到该用户的用户资料资料；开户时，需要检查其身份证是否在在其他库已开户；异地缴费时先查询到其归属地，然后才将查询和缴费操作路由到归属库
5、与节点多少无关的中间应用层自动路由技术
当移动用户办理的不是一卡双号、跨区集团、跨区亲情号码等跨区复杂业务时，输入手机号码(或证件号码)后，路由选择模块先查询本地节点数据库的本地的用户资料(或客户资料)，如查询到则返回归属节点数据库编号为本地节点数据库；如在本地查询不到，则再自动连接到枢纽数据库查询由各节点数据库复制过来组成的全局用户资料(或客户资料)，并返回手机号码(或证件号码)所真正对应存放的的归属节点数据库编号。
当用户办理里的如是是一卡双号、跨区集团、跨区亲情号码等跨区复杂业务时，，则将枢纽数据库编号返回为归属节点数据库编号。
中间应用层设置了自动路由功能，根据路由选择模块返回的归属节点数据库编号，自动将业务请求路由到对应的数据库，完成相应的开户、充值或跨区业务操作。
6、与应用无关的快速线性平滑扩容技术
由于自动选择路由功能的具备，在后续用户量和业务量变大时，增加节点数据库而不需要修改应用；由于增加了1个枢纽库，将N个节点的网状数据复制交互关系删除，变成N个节点只与枢纽库交换，大大降低了***的复杂度，变网状交互关系为星型关系。以上两个优点的具体，使得后续用户量和业务量增加时，只需通过调整配置(不需修改程序)将部署在应用服务器上的中间应用程序新增连接到新的节点数据库即可，可在一周内完成新的节点数据库的增加和应用上线工作，解决了目前各运营商普遍遇到的支撑容量线性快速提升难的重大难题
6、建立统一客户资料平台技术
通过建立枢纽库，实现客户数据(包括客户资料、帐单信息、梦网订购关系等)全局视图，其他***可通过枢纽库简单、准确、及时提取到所需信息，不需知道其后是什么平台、物理结构如何、存放位置等。
7、按需订阅和按需发布技术
经分、客服等其他***根据需要，可通过统一接口和统一数据总线订阅数据，由统一客户资料平台根据***资源通过实时、定时等方式进行按需发布，保证及时性和安全性，也有效降低***负载。
8、跨区业务的快速支撑技术
支撑省内跨市复杂业务，支持省内异地亲情号码、跨市短号集团等复杂业务，其存放枢纽库上作为全省共享数据；跨市办理缴费、换卡等业务求情都统一提交枢枢库，由枢纽库分发到目标库，***结构简单清晰。
支撑国内跨省复杂业务，同省内跨市业务一样，将跨省集团等复杂业务的数据都存放在枢纽库上；枢纽库作为对外统一接口，跨省办理的缴费、换卡等业务请求都统一提交到枢纽库，由其分发到目标省或本省对应的库。
“一点推出，全网运营”，通过枢纽库的支撑，一个地市(省)推出的新业务，全省(国)都可使用更加方便
虽然本发明已以较佳实施例公开如上，但它们并不是用来限定本发明，任何熟习此技艺者，在不脱离本发明之精神和范围内，自当可作各种变化或润饰，因此本发明的保护范围应当以本申请的权利要求保护范围所界定的为准。
Claims (5)
1、一种数据枢纽--业务支撑***网络化方法，包括以下步骤：
步骤一、将用户号码、帐单信息、资费套餐、业务功能等所有数据按照用户所属不同城市分别存放在N(N＞＝2)个节点数据库里；
步骤二、建立1个枢纽数据库；
步骤三、将分散在N个节点数据库里的用户资料表、客户资料表通过数据库技术复制到枢纽数据库中，建立全局的用户资料表、客户资料表视图；
步骤四、将跨区一卡双号、跨区集团、跨区亲情号码等跨区业务数据存放在枢纽数据库中；
步骤五：在应用服务器上部署中间应用程序连接N个节点数据库和1个枢纽数据库；部署在接入服务器上对外提供最终服务的接入服务程序连接应用服务器上的中间应用程序；
步骤六、当用户办理不是步骤四里包含的跨区复杂业务时，输入手机号码(或证件号码)后，路由选择模块先查询本地节点数据库的本地的用户资料(或客户资料)，如查询到则返回归属节点数据库编号为本地节点数据库；如在本地查询不到，则再自动连接到枢纽数据库查询由各节点数据库复制过来组成的全局用户资料(或客户资料)，并返回手机号码(或证件号码)所真正对应存放的的归属节点数据库编号；转到步骤八；
步骤七、当用户办理里的是步骤四里包含的跨区复杂业务时，则将枢纽数据库编号返回为归属节点数据库编号。
步骤八、根据步骤六返回的归属节点数据库编号，中间层应用程序自动路由到对应的节点数据库根据用户申请的业务逻辑进行数据修改操作，完成用户申请的开户、充值、业务变更等业务；或根据步骤七返回的归属节点数据库编号，中间层应用程序自动路由到枢纽数据库，完成跨区复杂业务的数据修改工作。
2、根据权利要求1所述数据枢纽--业务支撑***网络化方法，其特征在于，业务支撑***的总体体系结构为N+1体系结构，使得***可靠性显著提高一个数量级，故障时长由平均每月1小时降低到每年0.6小时，具体为：
通过N个节点数据库的使用，使得***的可靠性大大提高，因数据按地市分在N个节点数据库上，所以单节点处理性能高，同时保证当某一节点出现软硬件故障及***扩容调整时，不会影响到其他节点所承担地市的业务。
3、根据权利要求2所述数据枢纽--业务支撑***网络化方法，其特征在于它还提供了一种快速线性平滑扩容方法，具体而言，由于增加了1个枢纽库，将N个节点的网状数据复制交互关系删除，变成N个节点只与枢纽库交换，业务量增加时，通过调整配置，将部署在应用服务器上的中间应用程序新增连接到新的节点数据库，在新的节点数据库的增加和应用上线工作。
4、根据权利要求1所述数据枢纽--业务支撑***网络化方法，其特征在于，它还包括一种统一客户资料管理和数据按需订阅和按需发布方法，即通过拓展枢纽数据库功能，使得其成为全局的统一客户资料管理平台及数据交换和供应中心，实现及时全面准确的按需订阅和按需发布，而对外屏蔽各信息来源什么平台、物理结构如何、存放位置等，具体流程如下：
a)通过枢纽数据库，实现客户数据(包括客户资料、帐单信息、清单信息、梦网订购关系、历史活动信息等)全局视图，建立统一客户资料管理平台；
b)经营分析、10086客服等其他***可通过枢纽数据库提供的统一订阅接口进行订阅；
c)枢纽数据库通过自身统一提取模块从各节点数据库和其他数据库根据******的订阅需求提取和组合信息；
d)枢纽数据库通过统一发布接口向******发布提取和组合的信息，满足订阅需求。
5、根据权利要求1所述数据枢纽--业务支撑***网络化方法，其特征在于，对跨市(省)业务的快速灵活支撑，支撑省内跨市复杂业务，支持省内异地亲情号码、跨市短号集团等复杂业务，其存放枢纽库上作为全省共享数据；跨市办理缴费、换卡等业务求情都统一提交枢纽库，由枢纽库分发到目标库；
支撑国内跨省复杂业务，同省内跨市业务一样，将跨省集团等复杂业务的数据都存放在枢纽库上；枢纽库作为对外统一接口，跨省办理的缴费、换卡等业务请求都统一提交到枢纽库，由其分发到目标省或本省对应的库。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007101351382A CN101242299A (zh) | 2007-11-09 | 2007-11-09 | 数据枢纽—业务支撑***网络化方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNA2007101351382A CN101242299A (zh) | 2007-11-09 | 2007-11-09 | 数据枢纽—业务支撑***网络化方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101242299A true CN101242299A (zh) | 2008-08-13 |
Family
ID=39933525
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNA2007101351382A Pending CN101242299A (zh) | 2007-11-09 | 2007-11-09 | 数据枢纽—业务支撑***网络化方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101242299A (zh) |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102281521A (zh) * | 2010-06-10 | 2011-12-14 | 中国电信股份有限公司 | 一种电信计费运营网***及其计费方法 |
| CN102831499A (zh) * | 2012-08-06 | 2012-12-19 | 北京亿速码数据处理有限责任公司 | 全国城市一卡通互联互通***及方法 |
| CN104158721A (zh) * | 2014-07-15 | 2014-11-19 | 神州数码融信软件有限公司 | 一种基础信息交互的*** |
| CN106776820A (zh) * | 2016-11-25 | 2017-05-31 | 中国银行股份有限公司 | 获取不同区块链数据的方法及***、区块链、中心化*** |
| CN111090691A (zh) * | 2019-12-19 | 2020-05-01 | 北京百度网讯科技有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN112418804A (zh) * | 2020-11-26 | 2021-02-26 | 深圳市中博科创信息技术有限公司 | 一种秒批业务数据的自动归集方法 |
-
2007
- 2007-11-09 CN CNA2007101351382A patent/CN101242299A/zh active Pending
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102281521A (zh) * | 2010-06-10 | 2011-12-14 | 中国电信股份有限公司 | 一种电信计费运营网***及其计费方法 |
| CN102281521B (zh) * | 2010-06-10 | 2015-11-25 | 中国电信股份有限公司 | 一种电信计费运营网***及其计费方法 |
| CN102831499A (zh) * | 2012-08-06 | 2012-12-19 | 北京亿速码数据处理有限责任公司 | 全国城市一卡通互联互通***及方法 |
| CN104158721A (zh) * | 2014-07-15 | 2014-11-19 | 神州数码融信软件有限公司 | 一种基础信息交互的*** |
| CN106776820A (zh) * | 2016-11-25 | 2017-05-31 | 中国银行股份有限公司 | 获取不同区块链数据的方法及***、区块链、中心化*** |
| CN111090691A (zh) * | 2019-12-19 | 2020-05-01 | 北京百度网讯科技有限公司 | 一种数据处理方法、装置、电子设备和存储介质 |
| CN112418804A (zh) * | 2020-11-26 | 2021-02-26 | 深圳市中博科创信息技术有限公司 | 一种秒批业务数据的自动归集方法 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101233497B (zh) | 收益管理***和方法 | |
| CN101071434B (zh) | 一种分布式数据库***中用户分布的方法、装置及*** | |
| CN101242299A (zh) | 数据枢纽—业务支撑***网络化方法 | |
| CN101159603B (zh) | 一种无线网络海量数据存储方法 | |
| CN102148712B (zh) | 基于云计算的服务管理*** | |
| CN103886104A (zh) | 一种适用于电力***的分布式实时数据库管理***及实现方法 | |
| CN108647081A (zh) | 基于订单的虚机资源自动分配*** | |
| CN104866531A (zh) | 快速访问银行客户信息数据的方法及*** | |
| CN107194810A (zh) | 资产配置***和方法 | |
| CN112991046A (zh) | 电子资源的额度控制方法、装置、设备及存储介质 | |
| CN105404826A (zh) | 一种动态产生业务对象的权限管理方法 | |
| CN101094428A (zh) | 一种智能网业务数据库查询统计***及其方法 | |
| CN101021919A (zh) | 一种证件信息保真查询***以及查询方法 | |
| CN117061592A (zh) | 一种基于云平台的数据中心***及其搭建方法 | |
| CN104318378A (zh) | 一种小型企业客户关系管理*** | |
| Lin et al. | Architecture design and key technologies study of Omnichannel business platform for electric power marketing | |
| CN111708808A (zh) | 分布式业务***及其业务汇总查询方法、装置和设备 | |
| CN102929628A (zh) | 支持多互联网服务中心构建和运营的服务框架 | |
| CN112738168B (zh) | 一种交易银行业务中台及业务平台 | |
| Tseng et al. | A successful application of big data storage techniques implemented to criminal investigation for telecom | |
| CN101877103A (zh) | 金融增值服务*** | |
| CN101567943A (zh) | 一种数据管理和呼叫管理相分离的彩铃***及其实现方法 | |
| Fu et al. | [Retracted] Design and Management of Electricity Marketing Information System Based on Multisensor Fusion | |
| CN100433649C (zh) | 电信网络***中多对象配置的方法 | |
| CN114463111A (zh) | 一种网格化营销平台 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Open date: 20080813 |