CN109460841B - 用户开户方法、系统及存储介质 - Google Patents

Abstract

本发明提供一种用户开户方法、系统及存储介质，通过提交申请微服务从订单中心接收开户申请预订单，并获取报文及资源预占；开户提交微服务解析报文并进行费用处理，将开户信息提交业务支撑系统；写卡数据查询微服务根据开户信息获取写卡数据，存储到白卡中；卡数据同步微服务对用户所选号码进行资源实占，进行开户订单回写，在业务支撑系统完成开户，加强对2I2C业务IT支撑与创新，以服务化、中心化的方式去支撑，去掉AOP中间环节直接对接订单中心，实现集中化管理、线上线下一体化的支撑，业务支撑范围准确快捷，服务划分解耦且独立部署，在需求变动或新功能迭代需修改应用代码时服务间互不影响，可在线部署，提高业务稳定性、可用性。

Description

用户开户方法、系统及存储介质

技术领域

本发明涉及通信技术领域，尤其涉及一种用户开户方法、系统及存储介质。

背景技术

2I2C业务，全称B2I2C业务，其中B-企业(Business)，I-互联网(Internet)，C-消费者(Consumer)，是指与具有互联网线上应用触点，且用户规模上千万的互联网企业开展的合作项目，完全采用电商模式运作。随着中国联通对2I2C的快速推广，通过各种电子渠道接入cBSS支撑系统的业务受理请求也出现了井喷式的爆发增长。这一大业务发展助力在提高了公司整体收入的同时也面临着各种问题。

针对2I业务目前已知的分布式解决方案中并没有适合的方案，cBSS的特点是核心模块业务高度耦合，应用难以解耦，数据模型难以改变，难以拆域拆库拆表，生产系统环境依赖的是IOE(IBM、Oracle、EMC)，无法进行有效的分布式存储，扩容难度大。目前订单中心等一些电渠系统调用cBSS需要经过AOP进行业务处理，且处理流程繁复并不稳定；2I新产品推广支撑周期长，且产品配置需要跨多个系统进行配置，无法实现2I产品的一点配置与快速支撑；新产品上线如涉及代码变动的，需跟随cBSS系统常规版本进行发布且发布日期固定，发布间隔周期长，且涉及联调系统多、联调面广、联调周期长；并且可能存在线上线下支撑情况不一致的问题。

发明内容

本发明提供一种用户开户方法、系统及存储介质，以服务化、中心化的方式去支撑，服务划分解耦且独立部署，在需求变动或新功能迭代需修改应用代码时，服务间互不影响，且可在线部署，提高了业务稳定性、可用性。

本发明的第一方面是提供一种用户开户方法，应用于微服务架构的业务系统，所述业务系统包括提交申请微服务、开户提交微服务、写卡数据查询微服务及卡数据同步微服务，所述方法包括：

所述提交申请微服务获取订单中心发送的开户申请预订单，所述开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据所述开户申请预订单与所述产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占；

所述开户提交微服务解析所述报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统；

所述写卡数据查询微服务根据所述开户信息获取写卡数据，并存储到白卡中；

所述卡数据同步微服务对用户所选号码进行资源实占，并进行开户订单回写，从而在所述业务支撑系统完成用户开户。

进一步的，所述根据所述开户申请预订单与所述产品类型对应的详细数据获取报文，包括：

所述提交申请微服务获取所述开户申请预订单中的用户身份信息、用户所选号码和产品类型；

所述提交申请微服务获取与所述产品类型对应的产品详细数据；

所述提交申请微服务将用户身份信息、用户所选号码、产品类型及与所述产品类型对应的产品详细数据进行报文拼接，获得所述报文。

进一步的，所述提交申请微服务获取订单中心发送的开户申请预订单后，还包括：

所述提交申请微服务通过规则校验对用户身份信息进行校验。

进一步的，所述业务系统还包括写卡结果通知微服务；

所述写卡结果通知微服务检测完成写卡后的写卡数据，返回将写卡结果通知。

进一步的，所述业务系统还包括开户订单回写微服务；

所述进行开户订单回写，包括：

所述开户提交微服务调用开户订单回写微服务进行台账资源表、台账费用表、以及台账属性表回写，获取正式订单，并进行订单状态变更。

进一步的，所述业务系统还包括完工微服务；

所述方法还包括：

所述完工微服务根据正式订单的数据生成三户资料数据，并通过微服务接口把所述三户资料数据发送给账户管理微服务。

进一步的，所述提交申请微服务获取订单中心发送的开户申请预订单，包括：

所述提交申请微服务采用预定灰度发布机制获取订单中心发送的开户申请预订单。

本发明的第二方面是提供一种业务系统，其特征在于，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如第一方面所述的方法。

本发明的第三方面是提供一种计算机可读存储介质，其上存储有计算机程序；

所述计算机程序被处理器执行时实现如第一方面所述的方法。

本发明提供的用户开户方法、系统及存储介质，通过提交申请微服务获取订单中心发送的开户申请预订单，开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据开户申请预订单与产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占；开户提交微服务解析报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统；写卡数据查询微服务根据开户信息获取写卡数据，并存储到白卡中；卡数据同步微服务对用户所选号码进行资源实占，并进行开户订单回写，从而在业务支撑系统完成用户开户。本实施例的方法加强了对2I2C业务的IT支撑与创新，以服务化、中心化的方式去支撑，去掉AOP中间环节直接对接新老订单中心，实现集中化管理、线上线下一体化的支撑，业务支撑范围准确快捷，服务划分解耦且独立部署，在需求变动或新功能迭代需修改应用代码时，服务间互不影响，且可在线部署，提高了业务稳定性、可用性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的业务系统的架构图；

图2为本发明实施例提供的用户开户方法流程图；

图3为本发明实施例提供的业务系统的结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明提供的用户开户方法应用于如图1所示的微服务架构的业务系统，所述业务系统至少包括提交申请微服务、开户提交微服务、写卡数据查询微服务及卡数据同步微服务。业务系统前端可对接商城的订单中心、cBSS支撑系统营业受理前台等等对外提供服务，技术上可应用F5进行负载均衡(也可采用其他负载均衡算法)，在DC/OS微服务平台上进行业务层的分层设计：对接服务层(接收不同的协议请求来转换为标准化的输出)、次级子服务(标准化的输入、能力可共享、可对服务进行编排形成组合服务)、数据库操作原子服务(所有对数据库的操作进行集中、使用redis进行缓存处理)；数据层主要操作ORACLE生产数据库，通过OGG+kafka的方式同步DRDS数据库，进行业务的二次处理。

本发明的业务系统在设计时去掉了AOP等中间环节，直接对接商城订单中心以及其他外围系统，通过基础服务的组合编排也可支撑营业厅CRM系统的业务调用。设计时结合了微服务架构、分布式应用、分层应用、松耦合等设计思想完成了业务流程、服务集、数据层的设计与研发。应用了DC/OS微服务、分布式关系型数据库、分布式数据缓存机制、分布式发布订阅消息系统等多种技术。业务系统的设计与实现中充分考虑了后续的迭代开发、能力开放、服务的共性与个性化、以及支撑灰度发布、在线引流、线性扩展、弹性部署以及自动化测试。业务系统上线后进行了联调测试与业务验证，最终形成了一套可复制的微服务敏捷开发的解决方案。

图2为本发明实施例提供的用户开户方法流程图。本实施例提供了一种用户开户方法，该方法具体步骤如下：

S101、所述提交申请微服务获取订单中心发送的开户申请预订单，所述开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据所述开户申请预订单与所述产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占。

在本实施例中，业务系统的提交申请微服务对接订单中心或cBSS营业受理前台，对外进行接口请求的解析，接收订单中心发送的开户申请预订单，其中开户申请预订单包括用户身份信息、用户所选号码和产品类型，例如可包括产品、属性、费用、用户、客户、账户等信息。

提交申请微服务内部还包括报文拼装、规则校验、入表、号码预占等功能，提交申请微服务本身也可以为微服务架构，将上述功能分别以微服务形式实现。进一步的，提交申请微服务在接收到开户申请预订单后根据所述开户申请预订单与所述产品类型对应的产品详细数据获取报文。具体的，提交申请微服务获取开户申请预订单中的用户身份信息、用户所选号码和产品类型；然后获取与产品类型对应的产品详细数据；再将用户身份信息、用户所选号码、产品类型及与产品类型对应的产品详细数据进行报文拼接，从而获得所述报文。在获取报文后可对用户所选号码进行资源预占。

进一步的，提交申请微服务在获取订单中心发送的开户申请预订单后还可通过规则校验对用户身份信息进行校验，其中校验规则可预存数据库中，在进行规则校验时从数据库中获取对应的校验规则。此外，在校验通过后还可将上述各类信息通过入表服务存储到数据库中。

其中规则校验可以通过规则校验微服务实现，可根据业务要求配置校验规则，例如可包括黑名单校验、产品元素工号权限校验、产品元素互斥依赖关系校验、实名制校验、特殊限制校验等。

S102、所述开户提交微服务解析所述报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统。

在本实施例中，开户提交微服务解析报文，并进行费用处理，获取交易信息，如收费项、应收费用、减免金额等，并与用户完成交易过程，从而确定用户开户，进而进行订单状态处理服务和免填单打印服务，并将开户信息提交到业务支撑系统cBSS。

S103、所述写卡数据查询微服务根据所述开户信息获取写卡数据，并存储到白卡中。

在本实施例中，通过写卡数据查询微服务实现写卡功能，同时也能够对白卡数据进行查询。具体的，所述写卡数据查询微服务判断是否需要调拨，根据判断结果调用对应的获取写卡数据接口，进行写卡数据的获取，并存储到白卡中。也即写卡数据查询微服务首先根据入参判断是否为调拨，如果为调拨则调用白卡资源调拨专用获取写卡数据接口，如果为非调拨则调用获取写卡数据接口。如果后续流程异常需要重新调用写卡数据查询微服务则入参传入重复写卡标识，调用重复读卡接口，删除作废数据，插入新的写卡数据。

S104、所述卡数据同步微服务对用户所选号码进行资源实占，并进行开户订单回写，从而在所述业务支撑系统完成用户开户。

在本实施例中，通过卡数据同步微服务实现资源实占、开户订单回写、免填单打印、订单推送kafka等功能，卡数据同步微服务调用资源实占接口或号码占用接口进行资源实占，进一步的，开户提交微服务调用开户订单回写微服务进行台账资源表、台账费用表、以及台账属性表回写，获取正式订单，并进行订单状态变更。卡数据同步微服务还可调用免填单打印微服务，调用路由处理微服务，将订单推送kafka。此外开户订单回写微服务还可进行卡数据的加密、解密以及卡数据资料维护等功能。

本实施例提供的用户开户方法，通过提交申请微服务获取订单中心发送的开户申请预订单，开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据开户申请预订单与产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占；开户提交微服务解析报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统；写卡数据查询微服务根据开户信息获取写卡数据，并存储到白卡中；卡数据同步微服务对用户所选号码进行资源实占，并进行开户订单回写，从而在业务支撑系统完成用户开户。本实施例的方法加强了对2I2C业务的IT支撑与创新，以服务化、中心化的方式去支撑，去掉AOP中间环节直接对接新老订单中心，实现集中化管理、线上线下一体化的支撑，业务支撑范围准确快捷，服务划分解耦且独立部署，在需求变动或新功能迭代需修改应用代码时，服务间互不影响，且可在线部署，提高了业务稳定性、可用性。

在上述实施例的基础上，所述业务系统还包括写卡结果通知微服务；所述写卡结果通知微服务检测完成写卡后的写卡数据，返回将写卡结果通知。

在本实施例中，写卡结果通知微服务调用写卡结果通知接口判断是否有坏卡卡号，如果是则调用写卡失败通知接口，如果否则调用写卡成功通知接口，更新写卡数据状态。

进一步的，所述业务系统还包括完工微服务；

所述方法还包括：所述完工微服务根据正式订单的数据生成三户资料数据，并通过微服务接口把所述三户资料数据发送给账户管理微服务。

在本实施例中，开户订单在支撑系统返回完工通知时，直接调用完工微服务生成所需数据，避免了传统的通过BO(Business Object，业务对象层)-调用CRM(CustomerRelationship Management，客户关系管理)流程-调用开户lcu完工模式，简化处理流程。当然也可由BO判断是否走原有完工流程，如果是则调用原有的完工接口，如果否则根据业务类型调用对应的完工微服务接口，根据订单插表生成三户资料数据，调用账户管理微服务，把所述三户资料数据发送给账户管理微服务，进行账户管理和维护。

进一步的，所述方法还包括通过一证五户微服务、超限校验微服务、工号产品权限校验微服务来实现对一证五户、工号数据权限、受理业务限制等业务实现校验的目的，通过更细化配置，过滤一次业务必要校验的数量，缩短业务流程；数据集的方式，多个校验共用基础数据，减少与数据库交互；通过用动态脚本语言groovy来替代原来用SQL语句在数据库中进行校验的方式；校验规则的可配置、集中化管理。

进一步的，所述提交申请微服务获取订单中心发送的开户申请预订单，包括：

所述提交申请微服务采用预定灰度发布机制获取订单中心发送的开户申请预订单。

在本实施例中，通过灰度发布将本发明的业务系统首先提供给一部分目标人群使用，具体可以提供如下至少一种灰度发布机制：参数灰度，权重灰度和自定义http header灰度。其中，参数灰度是基于参数选择目标人群，例如按省分地市灰度，例如url(UniformResource Locator，统一资源定位符)里含有11地区使用灰度版本，其他使用正式版本，或者按号码灰度，例如132开头的号码访问灰度版本，其他访问正式版本。权重灰度以服务crm_userinfo为例，权重灰度上线新版本，标签完全与新版本一样，版本控制的策略为按新旧实例数比访问新旧版本，即旧服务实例数:新服务实例数＝访问旧服务次数:访问新服务次数。自定义http header灰度根据客户端请求携带特定的http header的不同，按灰度版本服务发布时配置的关于http header的策略，挑选一部分满足条件的人访问灰度版本服务，例如按员工编号和部门编号灰度，如员工号为hasc-yusl5并且部门为76b0lso访问微服务灰度版本，其他访问正式版本。通过灰度发布可以保证整体业务系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

进一步的，本实施例中还提供一种自动化测试方案，开发人员先进行单元测试自测，单元测试通过后进入集成测试阶段，集成测试在单元测试基础上，按照接口详细设计文档中的要求将所有测试接口组装起来，进行接口间集成测试。最后再进行UI(UserInterface，用户界面)测试。

其中，在集成测试阶段采用自顶向下集成的方式进行测试，按照接口服务执行顺序，自上而下深度优先的方式对各个服务一边组装一边进行测试。具体例如对于写卡数据查询微服务，将开户处理提交微服务中成功调用的场景，继续调写卡数据查询微服务信息选择调拔、白卡业务类型、新开户、首次读卡，HTTP返回码＝200，成功返回服务请求结果描述、服务流水号、大卡卡号、IMSI等内容；对于写卡结果通知微服务，正常发送写卡通知，检查返回报文；对于卡数据同步微服务，正常发送请求，检查返回报文。

本实施例中自动化测试工具采用Postman+Newman+Jenkins，实现微服务自动化的回归测试，其中，Postman用于编写测试用例，导出测试脚本(.json文件)；Newman命令行方式执行postman导出的测试脚本；Jenkins实现测试的自动化。以ecs_userinfo为例，主要分为以下步骤：使用Postman编写测试用例；导出成*.json，上传到测试环境对应文件如下：

10.124.XX.XX:/data/v01/functest/ecs_userinfo

在测试环境统一管理平台(http://10.124.XX.XX:8680/microservadmin/)上点击新建测试项目，新建成功在列表中找到该测试项目{服务名}_functest,点击立即构建执行功能测试，在构建日志中查看功能测试结果。

本发明实施例还提供一种如图1所示的微服务架构的业务系统，所述业务系统包括提交申请微服务、开户提交微服务、写卡数据查询微服务及卡数据同步微服务。

其中，所述提交申请微服务用于获取订单中心发送的开户申请预订单，所述开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据所述开户申请预订单与所述产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占；所述开户提交微服务用于解析所述报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统；所述写卡数据查询微服务用于根据所述开户信息获取写卡数据，并存储到白卡中；所述卡数据同步微服务用于对用户所选号码进行资源实占，并进行开户订单回写，从而在所述业务支撑系统完成用户开户。

本实施例提供的的业务系统可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

图3为本发明另一实施例提供的业务系统的结构示意图。本发明实施例提供的业务系统可以执行用户开户方法实施例提供的处理流程，如图3所示，业务系统30包括存储器31、处理器32、计算机程序和通讯接口33；其中，计算机程序存储在存储器31中，并被配置为由处理器32执行以上实施例所述的用户开户方法。

图3所示实施例的业务系统可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，此处不再赘述。

另外，本发明实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行以实现上述实施例所述的用户开户方法。

在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (9)

1.一种用户开户方法，其特征在于，应用于微服务架构的业务系统，所述业务系统包括提交申请微服务、开户提交微服务、写卡数据查询微服务及卡数据同步微服务，所述方法包括：

所述提交申请微服务获取订单中心发送的开户申请预订单，所述开户申请预订单包括用户身份信息、用户所选号码和产品类型，并根据所述开户申请预订单与所述产品类型对应的产品详细数据获取报文，并对用户所选号码进行资源预占；

所述开户提交微服务解析所述报文并进行费用处理，得到开户信息，并将开户信息提交到业务支撑系统；

所述写卡数据查询微服务根据所述开户信息获取写卡数据，并存储到白卡中；

所述卡数据同步微服务对用户所选号码进行资源实占，并进行开户订单回写，从而在所述业务支撑系统完成用户开户；

所述根据所述开户申请预订单与所述产品类型对应的详细数据获取报文，包括：

所述提交申请微服务获取所述开户申请预订单中的用户身份信息、用户所选号码和产品类型；

所述提交申请微服务获取与所述产品类型对应的产品详细数据；

所述提交申请微服务将用户身份信息、用户所选号码、产品类型及与所述产品类型对应的产品详细数据进行报文拼接，获得所述报文。

2.根据权利要求1所述的方法，其特征在于，所述提交申请微服务获取订单中心发送的开户申请预订单后，还包括：

所述提交申请微服务通过规则校验对用户身份信息进行校验。

3.根据权利要求1所述的方法，其特征在于，所述业务系统还包括写卡结果通知微服务；

所述写卡结果通知微服务检测完成写卡后的写卡数据，返回写卡结果通知。

4.根据权利要求3所述的方法，其特征在于，所述写卡数据查询微服务根据所述开户信息获取写卡数据，并存储到白卡中，包括：

所述写卡数据查询微服务判断是否需要调拨；

所述写卡数据查询微服务根据判断结果调用对应的获取写卡数据接口，进行写卡数据的获取，并存储到白卡中。

5.根据权利要求1所述的方法，其特征在于，所述业务系统还包括开户订单回写微服务；

所述进行开户订单回写，包括：

所述开户提交微服务调用开户订单回写微服务进行台账资源表、台账费用表、以及台账属性表回写，获取正式订单，并进行订单状态变更。

6.根据权利要求5所述的方法，其特征在于，所述业务系统还包括完工微服务；

所述方法还包括：

所述完工微服务根据正式订单的数据生成三户资料数据，并通过微服务接口把所述三户资料数据发送给账户管理微服务。

7.根据权利要求1所述的方法，其特征在于，所述提交申请微服务获取订单中心发送的开户申请预订单，包括：

所述提交申请微服务采用预定灰度发布机制获取订单中心发送的开户申请预订单。

8.一种业务系统，其特征在于，包括：

存储器；

处理器；以及

计算机程序；

其中，所述计算机程序存储在所述存储器中，并被配置为由所述处理器执行以实现如权利要求1-7中任一项所述的方法。

9.一种计算机可读存储介质，其特征在于，其上存储有计算机程序；

所述计算机程序被处理器执行时实现如权利要求1-7中任一项所述的方法。

Images