CN113486099A - 一种内存计算服务框架及实现*** - Google Patents

一种内存计算服务框架及实现*** Download PDF

Info

Publication number
CN113486099A
CN113486099A CN202110702160.0A CN202110702160A CN113486099A CN 113486099 A CN113486099 A CN 113486099A CN 202110702160 A CN202110702160 A CN 202110702160A CN 113486099 A CN113486099 A CN 113486099A
Authority
CN
China
Prior art keywords
service
query
framework
service framework
message
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
Application number
CN202110702160.0A
Other languages
English (en)
Inventor
罗文辉
张俊
何涛
梁祖韬
***
张龙
陈珍珍
陈星�
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huatai Securities Co ltd
Original Assignee
Huatai Securities Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huatai Securities Co ltd filed Critical Huatai Securities Co ltd
Priority to CN202110702160.0A priority Critical patent/CN113486099A/zh
Publication of CN113486099A publication Critical patent/CN113486099A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22Indexing; Data structures therefor; Storage structures
    • G06F16/2228Indexing structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • G06F16/24552Database cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083Techniques for rebalancing the load in a distributed system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/546Message passing systems or structures, e.g. queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00Indexing scheme relating to G06F9/00
    • G06F2209/54Indexing scheme relating to G06F9/54
    • G06F2209/547Messaging middleware

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开一种内存计算服务框架及实现***。所述服务框架以Nats作为服务间通信的消息总线;所述服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic;所述服务框架使用Hazelcast缓存服务状态,提供统一的持久化和查询服务进行内存状态持久化和查询;使用SQL统一表达查询和订阅条件,并且创造性引入Q&S订阅模式,确保消息消费不丢不重。通过预定义存储模型和统一的存储查询服务,将数据存储和查询与业务逻辑解耦并实现读写分离,通过引入SQL,Q&S等技术解决了数据交互易用性和可靠性问题,主要应用于交易、风控、仓位、实时监控、实时指标计算等场景,可作为内存计算服务标准框架推广。

Description

一种内存计算服务框架及实现***
技术领域
本发明属于内存计算领域,涉及一种内存计算服务框架及实现***。
背景技术
数字化大潮的背景下,随着数据生产速度和数据量的增长,以及对数据处理实时性要求的提高,已经不能接受“先落地,再处理”的传统数据处理模式,数据必须在产生时以极短时间进行分析处理,然后输出结果作为其他***的输入,数据库不再处于实时数据处理的中心,而是退回到了幕后,作为数据落地后进行分析和运营的载体。但凡对实时性有要求的***,其关键路径上已很难看到数据库的影子,大多都是基于内存计算的架构,但内存计算并不是万能的,依旧存在诸多痛点等待解决。
经检索发现,CN106021484A的中国发明于2016年10月12日公开了一种基于内存计算的可定制多模式大数据处理***,包括:数据存储层模块、基于内存的数据共享和管理层模块、基于内存计算的通用执行框架层模块以及访问接口层模块;其中,采用了数据的分布式内存抽象机制、位置感知性调度机制、分布式混合列式存储机制。该发明构建了海量数据存储,提供面向集群并发计算的内存数据管理和共享框架,并提供高效、按需定制的大数据多模式通用处理框架,支持批处理、实时数据流计算,对数据的灵活分析与深度利用提供支撑。但是由于缺少消息总线,上游消息在逻辑上和物理上都需要依赖其他服务,无法实现逻辑解耦和物理解耦,总任务的执行时间比较长;并且在接口定义,调用方式,存储模型等方面没有形成统一的规范和实践。因此在数据处理实时性要求大幅提高的前提下,需要统一的服务框架来提供服务管理,消息路由,订阅发布,数据存储查询等基础能力。
公开号为CN105426504A的中国发明于2016年3月23日公开了一种基于内存计算的分布式数据分析处理方法,包括如下步骤:1)提供一个类SQL解析器,将传入的查询分析文本解析为相应的逻辑计划,并进行初步优化;2)提供一个任务转换器,将类SQL解析器生成的逻辑计划转换为可为大数据内存计算模型识别的计算表达式,包含多个自定义的转化类;3)提供一个查询优化器,将传入的内存计算模型可识别的表达式转化为逻辑计划同时对逻辑计划进行优化,然后转化为物理执行计划。针对传统大数据处理在数据查询分析处理上的空缺,该发明提供了一种基于内存计算的分布式数据分析处理方法,继承了内存计算模型在数据处理方面的优势,使得数据查询分析的编程语言更加简单。但是数据仍然分散在各业务***中,外部***的查询请求必须由业务***处理,无法做到读写分离,影响了优先级更高的业务请求的处理以及服务整体稳定性,需要对数据分析处理方法加以改进。
目前部门交易业务相关各团队自研的交易、风控、仓位、实时监控、实时指标计算等***均是基于内存计算的思路而搭建,其性能相比于数据库***有了数量级的提升,但同时也存在如下一些问题:
(1)服务各自为战,在接口定义,调用方式,存储模型等方面没有形成统一的规范和实践;
(2)数据分散在各业务***中,外部***的查询请求必须由业务***处理,无法做到读写分离,大数据量查询可能引发较长时间GC停顿,甚至服务整体不可用,影响了优先级更高的业务请求的处理以及服务整体稳定性;
(3)服务间数据交互成本高,必须事先定义好订阅和查询的API,新的查询请求必然要新增API才能满足,因此,存在灵活性不足的问题;
(4)消息消费时的可靠性机制不完善,大部分服务还是通过订阅、轮询、去重来保证状态的最终一致性,增加了网络带宽消耗和数据生产者的负载;
(5)在平台建设过程中,既涉及通过RPC调用对接已有自研***,又要基于点对点私有通信协议的订单管理***进行二次开发,以及与供应商的第三方***打通,***交互错综复杂,涉及不同调用方式、中间件和数据模型。
由于存在以上种种问题,亟需一个统一的服务框架来提供服务管理,消息路由,订阅发布,数据存储查询等基础能力,提高内存计算的性能,在解放业务生产力的同时,也需要提供内存计算服务的标准开发规范。
发明内容
为克服上述现有技术的不足,本发明提供一种内存计算服务框架,既解决了接口定义、调用方式、存储模型无法形成统一规范的问题,又解决了各业务***中数据无法完成读写分离的问题。
本发明在一方面,提供了一种内存计算服务框架,所述服务框架以Nats作为服务间通信的消息总线;所述服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic;所述服务框架使用Hazelcast缓存服务状态。
上述技术方案中,内存计算服务框架通过Nats作为服务间通信的消息总线,提高了整体的吞吐能力,并且保证了消息传输的速率。Nats是一个开源的高性能消息中间件,可以达到每秒百万吞吐,同时保证毫秒以内的端到端消息传输时延。基于broker(消息代理)的服务通信被诟病的重要一点在于引入了较大的通信延时,而Nats的延时表现远超其他同类broker,仅比点对点通信稍慢,因此Nats极高的性能是选择它作为消息总线的重要原因之一。另一方面,Nats提供了filter表达式,为所述服务框架的消息路由、负载均衡能力提供了基础。Nats提供的精细粒度的消息iilter表达式(A.B.*.C形式),也是Nats区别于其他所有同类broker的特性,所述服务框架中,消息路由、负载均衡等能力均是基于这一特性构建。同时,所有发布者和订阅者均通过Nats进行通信,服务互相之间不直连,为***的扩展性提供了很好的支撑。同时,在开源的Nats基础上,引入了topic,实现了基于topic的服务发现和通信机制,通过topic管理实现所述服务框架的核心管理能力。所有服务通过订阅指定的topic来触发业务逻辑处理,处理完成后再以消息形式发布其内存状态到指定topic,供其他服务消费。所述服务框架使用Hazelcast进行服务状态的缓存,为读写分离的架构提供了基础。Hazelcast是一个开源的分布式缓存,具有索引创建和维护以及类SQL的查询能力,这两个特性构成了所述服务框架中读写分离架构的基础。Hazelcast作为全局缓存,保存了最近一段时间所有服务的状态以及变更历史,服务状态通过持久化服务写入Hazelcast并自动维护索引,通过查询服务以SQL方式提供查询能力,而业务服务无需提供查询功能,因此大大减轻了业务服务的负担。
优选的,所述服务框架中,服务使用topic基于Nats进行pub-sub模式的通信,每个topic包含以下属性:名称、类型、topic上传输信息的编码方式、topic的创造者或所有者、模板;当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK会根据topic的模板属性抽取消息中相应字段值形成subject,Nats根据所述subject以及订阅条件进行消息路由。所述服务框架中,服务都是使用topic基于Nats进行pub-sub模式的通信。topic是Nats框架中最核心的概念之一,每个topic包含如下属性:name(名称),type(类型),encoding(topic上传输的消息的编码方式),owner(topic的创建者或所有者),template(模板);其中,type支持business和system,encoding可以是json或pb,template用来做消息路由和filter的元数据;而template是其中最关键的属性,对于一个template的定义:{tradingAccount}.{securityId}.{exchange}.{serviceName},当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK会根据此topic的template属性抽取消息中相应字段值形成subject,Nats根据所述subject以及订阅条件进行消息路由。所述服务框架中topic的定义结合Nats根据subject进行消息分发的特点,可以形成非常灵活的业务设计。通过按照任意维度进行组合形成订阅条件,可以大幅提升所述服务框架的灵活性,同时,业务层也可以基于所述业务设计的特性进行负载均衡设计。
进一步的,基于所述服务框架的服务开发,首先梳理服务的输入和输出,再定义创建的topic、订阅的topic,以及在所述创建和订阅的topic上传输的消息格式。通过梳理服务的输入和输出是什么,再据此定义创建哪些topic,订阅哪些topic,以及在这些topic上传输的消息格式,达到约束形成所述服务框架的服务集成规范的目的,在遵守同一套规范的前提下,框架层可以提供更多标准化的能力,助力业务的开发。因此,所述服务框架在接口定义,调用方式,存储模型等方面形成了统一的规范,提升了数据处理的性能,使服务形成了同一的规范。
优选的,所述服务框架包括一个管理中心节点Monitor,用于管理***中服务的状态,以及服务注册登录初始化操作;所述服务启动需要经过登录、注册、同步参数、检查依赖;所述Monitor对任何一个服务的状态变化进行广播。通过设置管理中心节点Monitor,实现对所述服务框架中所有服务的状态的管理,还能实现对服务注册登录等初始化操作的管理。Monitor会广播任何一个服务的状态变化,其他服务可以订阅到这些变化并作出相应决策,如果依赖的服务出现状态异常时,业务应用可以感知到并且进行相应处理。使管理者能够及时了解服务的运行状况,能够对不同状态的服务进行相应的处理,提高了所述服务框架整体运行的稳定性。
进一步的,服务启动为INIT状态需要经过a)登录、b)注册、c)同步参数、d)检查依赖等过程,初始化结束后,启动成功,状态更新为ACTIVE状态。服务本身和Monitor通过心跳维护自身状态,如果Monitor长时间收不到服务心跳,会判断服务状态异常,将服务状态更新为INACTIVE。ACTIVE状态的服务停止后,最终进入SHUTDOWN状态;INACTIVE状态的服务退出后,最终进入SHUTDOWN状态。设置不同的状态和相应的判断条件,保证了管理者对服务状态监控的准确性,避免出现误判或者漏检等问题。管理者能够及时了解服务的运行状况,能够对不同状态的服务进行相应的处理,进一步提高了所述服务框架整体运行的稳定性。
优选的,服务启动时的依赖检查通过服务状态是否满足依赖来校验,方法如下:a)如果应用配置了启动时依赖,若被依赖方状态不是ACTIVE,则应用的启动会一直等待,直到被依赖方恢复正常;b)如果应用配置了运行时依赖,则被依赖方出现状态变化时,应用收到通知,并进行处理。这种约束方式能够帮助管理者及时地发现互相依赖的服务之间出现的异常,及时掌握服务的运行状态,对出现异常的服务进行针对性的处理,进一步保证了所述服务框架整体运行的稳定性。
优选的,基于Hazelcast和数据库设置通用数据存储和查询服务,一个基于所述服务框架开发的应用服务在数据模型定义时通过注解指定需要持久化的数据,以及建立查询索引的字段,所述内存计算服务框架提供的存储和查询服务自动将数据进行持久化,并提供查询,减轻了服务的运行负担。现有技术中,由于缺少统一的存储模型和查询服务,大多数查询都需要数据生产者处理,而在所述服务框架中,基于Hazelcast和数据库设计了通用数据存储和查询服务,一个基于所述服务框架开发的应用服务,只需要在数据模型定义时通过注解指定哪些数据需要持久化,以及在哪些字段建立查询索引,所述服务框架提供的存储和查询服务会自动将数据进行持久化,并提供查询。所述服务框架中的数据存储和查询变成了一种通用能力,无需每个服务再关注。极大地降低了服务间数据交互的成本,同时也提高了服务框架的灵活性。
优选的,所述服务框架中,由Cache writer和DB writer服务订阅需要持久化的消息,并且同时独立地分别写入缓存和数据库中;查询请求由框架层的查询服务进行处理,对于实时性要求高的数据从缓存中查询,同时支持从数据库中进行查询。在这种架构模式下,实现了读写分离,业务服务不再需要处理大量的查询请求,大大减轻了服务的负担。
优选的,所述服务框架中,一个对象存在Key-Value和关系型两种存储模型,对外提供统一的SQL查询接口。SQL是一种结构化查询语言,通常与关系型存储模型结合使用,而在所述服务框架中,一个对象存在Key-Value(Hazelcast)和关系型(mysql)两种存储模型,利用Hazelcast支持类SQL查询的特性,对所述对象的接口进行了一层简单封装,对外提供了统一的sql查询接口,因此所述服务框架中存储的数据,不管是在缓存(HazelcastCache)还是在数据库(Database)中,都可以通过一条SQL查询出来,极大地降低了使用门槛,降低了业务开发成本。
优选的,所述服务框架通过对Nats API的封装,用SQL来表达订阅条件,将订阅和查询接口进行统一。除了查询外,应用层还会订阅所述服务框架中的实时数据,Nats提供的原生API需要调用者构造形如A.B.*.C这样的订阅表达式,易用性较低,所述服务框架通过对Nats API的封装,创造性地提出了并实现了用SQL来表达订阅条件,这就将订阅和查询接口统一了起来,进一步降低了业务开发门槛。对于同一条SQL语句,不同场景具有不同的语义。所述服务框架通过对不同的数据获取场景提供统一的SQL接口,是最具价值的创新点之一,既降低了业务开发成本,又能使第三方工具可以无缝接入,同时相同服务的不同实例又可以通过不同的订阅SQL实现负载均衡。
优选的,所述服务框架采用Query Service原子订阅模式。在实际应用中,有一类特殊的订阅场景,用户不仅需要收到对象状态在订阅生效之后的变更推送,还需要能收到所述对象在订阅之前的最新状态。针对这一特殊的订阅场景,所述服务框架采用QueryService原子订阅模式的解决方案。而在此之前,比较常用的解决方案是仅查询(Query)模式或仅订阅(Subscribe)模式:用户周期性地查询标的的行情数据,虽然也能获取到最新行情,但轮询不仅浪费了网络带宽,也给行情服务带来了一定的压力,相比之下,QueryService原子订阅模式不仅节约了网络带宽,也减轻了行情服务带来的压力,能够更加高效地处理用户的订阅需求。
本发明在另一方面,提供了一种内存计算服务框架实现***,包括:
接入层:支撑客户端的请求,通过消息总线与各个服务交互;
应用层:包括平台服务和业务服务,平台服务支撑业务***,业务服务通过内存计算服务框架SDK统一接入消息总线;
存储层:包括缓存和数据库,存储层专注数据持久化;
所述平台服务通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。
所述接入层以gateway为主,支撑客户端的请求,通过Nats与各个服务交互。应用层中的平台服务支撑所有业务***;业务服务通过内存计算服务框架SDK统一接入Nats。存储层专注数据持久化,对业务使用方透明。整个平台通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。通过所述***的设置,实现了读写分离,业务服务不再需要处理大量的查询请求,大大减轻了服务的负担。所述***实现内存计算服务框架的特性和功能:通过Nats作为服务间通信的消息总线,使用Hazelcast缓存服务状态,提供统一的持久化和查询服务进行内存状态持久化和查询,引入Q&S订阅模式,确保消息消费不丢不重。
与现有技术相比,本发明的有益效果在于:
(1)本发明的内存计算服务框架,涵盖了消息驱动、内存计算、读写分离、负载均衡等方面,完整地构建出支持内存计算的整套服务体系。本发明的内存计算服务框架以Nats作为服务间通信的消息总线,提高了服务框架的吞吐能力,同时也保证了消息传输的速率。所有发布者和订阅者均通过Nats进行通信,在开源的Nats的基础上,创造性地引入了topic,实现了基于topic的服务发现和通信机制,以及基于topic group特性的无状态服务负载均衡。所有服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic,供其他服务消费,服务互相之间不直连,为***的扩展性提供了很好的支撑。所述服务框架使用Hazelcast进行服务状态的缓存,为后续的读写分离架构提供了基础。
(2)本发明的内存计算服务框架,所有服务使用topic基于Nats进行pub-sub模式的通信,每个topic包含名称、类型、topic上传输信息的编码方式、topic的创造者或所有者、模板等属性;当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK会根据topic的模板属性抽取消息中相应字段值形成subject,Nats根据所述subject以及订阅条件进行消息路由。topic的定义结合Nats根据subject进行消息分发的特点,可以形成非常灵活的业务设计。通过按照任意维度进行组合形成订阅条件,可以大幅提升所述服务框架的灵活性,同时,业务层也可基于所述业务设计的特性进行负载均衡设计。
(3)本发明的内存计算服务框架,在开源的Hazelcast的基础上,构建了统一的存储和查询服务,将订阅和查询统一以SQL来表达,极大地降低了使用门槛,提升了所述服务框架的易用性,降低了其他SQL工具的集成成本,达到了读写分离的效果。一个基于所述服务框架开发的应用服务在数据模型定义时通过注解指定需要持久化的数据,以及建立查询索引的字段,所述内存计算服务框架提供的存储和查询服务自动将数据进行持久化,并提供查询。本发明的内存计算服务框架中的数据存储和查询变成了一种通用能力,无需对每个服务再关注。通过对Nats API的封装,创造性地提出了并实现了用SQL来表达订阅条件,这就将订阅和查询接口统一了起来,进一步降低了业务开发门槛。既降低了业务开发成本,又能使第三方工具可以无缝接入,同时相同服务的不同实例又可以通过不同的订阅SQL实现负载均衡。
(4)本发明的内存计算服务框架,创造性地提出了Query&Subscribe(Q&S)原子订阅模式,解决了应用层订阅消息可能会丢数据的痛点,同时也解决了消息订阅和查询间隔中会丢失消息的问题,此外,所述本发明的内存计算服务框架摒弃了从客户端不断轮询来保证数据一致性的低效做法,节约了网络带宽,也减轻了行情服务带来的压力,能够更加高效地处理用户的订阅需求。
(5)本发明的内存计算服务框架实现***,包括:接入层、应用层存储层,接入层用以支撑客户端的请求,通过消息总线与各个服务交互;应用层包括平台服务和业务服务,平台服务支撑业务***,业务服务通过内存计算服务框架SDK统一接入消息总线;存储层包括缓存和数据库,存储层专注数据持久化;平台服务通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。所述***使内存计算服务框架能够实现,解决了内存计算没有统一的规范和实践、无法做到读写分离、服务间的数据交互成本高、消息消费时的可靠机制不完善等诸多共性问题,并且使服务框架具备较好的扩展能力,并提供了支持快速开发的SDK。
附图说明
图1是本发明实施例提供的内存计算服务框架实现***的组成框图;
图2是本发明实施例提供的内存计算服务框架支持业务发布、订阅场景框图;
图3是本发明实施例提供的内存计算服务框架的服务状态转换图;
图4是本发明实施例提供的内存计算服务框架的工具界面图;
图5是本发明实施例提供的内存计算服务框架的Q&S订阅实现机制框图。
具体实施方式
以下将结合附图对本发明各实施例的技术方案进行清楚、完整的描述,显然,所描述发实施例仅仅是本发明的一部分实施例,而不是全部的实施例。基于本发明的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例,都属于本发明所保护的范围。
实施例一
参见图1,本实施例提供一种内存计算服务框架,所述服务框架以Nats作为服务间通信的消息总线;所述服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic,供其他服务消费;所述服务框架使用Hazelcast缓存服务状态。
本实施例中,基于Hazelcast和数据库设置通用数据存储和查询服务;一个基于所述服务框架开发的应用服务在数据模型定义时通过注解指定需要持久化的数据,以及建立查询索引的字段,所述内存计算服务框架提供的存储和查询服务自动将数据进行持久化,并提供查询。
本实施例中,由Cache writer和DB writer服务订阅需要持久化的消息,并且同时独立地分别写入缓存和数据库中;查询请求由框架层的查询服务进行处理,对于实时性要求高的数据从缓存中查询,同时支持从数据库中进行查询。
本实施例提供的内存计算服务框架,涵盖了消息驱动、内存计算、读写分离、负载均衡等方面,完整地构建出支持内存计算的整套服务体系。以Nats作为服务间通信的消息总线,提高整体的吞吐能力,保证了消息传输的速率。此外,Nats提供的精细粒度的消息filter表达式(A.B.*.C形式),消息路由、负载均衡等能力均是基于这一特性构建。所有发布者和订阅者均通过Nats进行通信,所有服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic,供其他服务消费,服务互相之间不直连,为***的扩展性提供了很好的支撑。在开源的Nats基础上,引入了topic,实现了基于topic的服务发现和通信机制,通过topic管理实现所述服务框架的核心管理能力,以及基于topic group特性的无状态服务负载均衡。所述服务框架使用Hazelcast进行服务状态的缓存,为读写分离的架构提供了基础。
在缺少统一的存储模型和查询服务的情况下,大多数查询都需要数据生产者处理,而在本实施例的服务框架中,基于Hazelcast和数据库设计了通用数据存储和查询服务,一个基于所述服务框架开发的应用服务,只需要在数据模型定义时通过注解指定哪些数据需要持久化,以及在哪些字段建立查询索引,所述服务框架提供的存储和查询服务会自动将数据进行持久化,并提供查询。所述服务框架中的数据存储和查询变成了一种通用能力,无需每个服务再关注。由Cache writer和DB writer服务订阅需要持久化的消息,并且同时独立地分别写入缓存和数据库中;查询请求由框架层的查询服务进行处理,对于实时性要求高的数据从缓存中查询,同时支持从数据库中进行查询。在这种架构模式下,实现了读写分离,业务服务不再需要处理大量的查询请求,大大减轻了服务的负担。
本实施例提供一种内存计算服务框架实现***,包括:
接入层:支撑客户端的请求,通过消息总线与各个服务交互;
应用层:包括平台服务和业务服务,平台服务支撑业务***,业务服务通过内存计算服务框架SDK统一接入消息总线;
存储层:包括缓存和数据库,存储层专注数据持久化;
所述平台服务通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。
所述接入层以gateway为主,支撑客户端的请求,通过Nats与各个服务交互。应用层中的平台服务支撑所有业务***;业务服务通过内存计算服务框架SDK统一接入Nats。存储层专注数据持久化,对业务使用方透明。整个平台通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。通过所述***的设置,实现了读写分离,业务服务不再需要处理大量的查询请求,大大减轻了服务的负担。整套框架涵盖消息驱动、内存计算、读写分离、负载均衡等方面,可以完整构建出支持内存计算的整套服务体系。
实施例二
参见图2,本实施例提供的内存计算服务框架中,服务使用topic基于Nats进行pub-sub模式的通信,每个topic包含以下属性:名称、类型、topic上传输信息的编码方式、topic的创造者或所有者、模板;当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK会根据topic的模板属性抽取消息中相应字段值形成subject,Nats根据所述subject以及订阅条件进行消息路由。
本实施例中,服务都是使用topic基于Nats进行pub-sub模式的通信,topic管理是所述服务框架的一个核心管理能力。topic是Nats框架中最核心的概念之一,每个topic包含如下属性:name(名称),type(类型),encoding(topic上传输的消息的编码方式),owner(topic的创建者或所有者),template(模板);其中,type支持business和system,encoding可以是json或pb,template用来做消息路由和filter的元数据。而template是其中最关键的属性,对于一个template的定义:
{tradingAccount}.{securityId}.{exchange}.{serviceName},当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK会根据此topic的template属性抽取消息中相应字段值形成subject(例如001120.601688.SH.orderService),Nats根据此subject以及订阅条件进行消息路由。如果有消费者订阅了所有001120账户的订单请求(select*from order where tradingAccount=’001120’),则上述消息会被转发到此消费者处理。
所述服务框架中topic的定义结合Nats根据subject进行消息分发的特点,可以形成非常灵活的业务设计。在订单处理场景中,我们可以把交易账号(tradingAccount)和市场(exchange)等维度组合到subject中。traderA向order这个topic发布一个上交所订单,subject即traderA.SH,订阅者选择只订阅上海(*.SH)、或者只订阅traderA账号(traderA.*),均可以收到这条订单的推送,且不会收到其它账号或市场的推送。如图2,这些维度可以按照任意维度进行组合形成订阅条件,非常灵活,业务层也可基于该特性进行负载均衡设计。
因此,基于所述服务框架的服务开发,第一步就是梳理服务的输入和输出是什么,据此定义创建哪些topic,订阅哪些topic,以及在这些topic上传输的消息格式,以此约束形成了本实施例提供的服务框架的服务集成规范,在遵守同一套规范的前提下,框架层就可以提供更多标准化的能力助力业务开发。
实施例三
参见图3,本实施例提供的内存计算服务框架包括一个管理中心节点Monitor,此节点管理框架中所有服务的状态,以及服务注册登录等初始化操作。服务启动(INIT状态)需要经过a)登录、b)注册、c)同步参数、d)检查依赖等过程,最终启动成功(ACTIVE状态)。如图3,服务本身和Monitor通过心跳维护自身状态,如果Monitor长时间收不到服务心跳,会判断服务状态为INACTIVE。ACTIVE状态的服务停止后,最终进入SHUTDOWN状态;INACTIVE状态的服务退出后,最终进入SHUTDOWN状态。Monitor会广播任何一个服务的状态变化,其他服务可以订阅到这些变化并作出相应决策,如果依赖的服务出现状态异常时,业务应用可以感知到并且进行相应处理。
本实施例提供的内存计算服务框架中,应用启动时的依赖检查,是通过服务状态是否满足依赖来校验的:a)如果应用配置了启动时依赖,如果被依赖方状态不是ACTIVE,那么应用的启动会一直等待,直到被依赖方恢复正常;b)如果应用配置了运行时依赖,那么被依赖方出现状态变化时,应用会收到通知,从而进行针对性地处理。这种约束方式能够帮助管理员及时地发现互相依赖的服务之间出现的异常,及时掌握服务的运行状态,对出现异常的服务进行针对性的处理,从而提高了所述服务框架整体运行的稳定性。
实施例四
参见图4,本实施例提供的内存计算服务框架中,一个对象存在Key-Value和关系型两种存储模型,对外提供统一的SQL查询接口。SQL是一种结构化查询语言,通常与关系型存储模型结合使用,而在所述服务框架中,一个对象存在Key-Value(Hazelcast)和关系型(mysql)两种存储模型,利用Hazelcast支持类SQL查询的特性,对所述对象的接口进行了一层简单封装,对外提供了统一的SQL查询接口,因此所述服务框架中存储的数据,不管是在缓存(Hazelcast Cache)还是在数据库(Database)中,都可以通过一条SQL查询出来,极大地降低了使用门槛,降低了业务开发成本。
本实施例提供的内存计算服务框架中,所述服务框架通过对Nats API的封装,用SQL来表达订阅条件,将订阅和查询接口进行统一。除了查询外,应用层还会订阅所述服务框架中的实时数据,Nats提供的原生API需要调用者构造形如A.B.*.C这样的订阅表达式,易用性较低,所述服务框架通过对Nats API的封装,创造性地提出了并实现了用SQL来表达订阅条件,这就将订阅和查询接口统一了起来,进一步降低了业务开发门槛。解决了现有技术中服务间数据交互成本高的问题。在现有的内存计算中,由于订阅和查询的接口不统一,必须事先定义好订阅和查询的API、新的查询请求必然要新增API才能满足,因此,存在灵活性不足的痛点。
本实施例中,对于同一条SQL语句,不同场景具有不同的语义。所述服务框架通过对不同的数据获取场景提供统一的SQL接口,是最具价值的创新点之一,既降低了业务开发成本,又能使第三方工具可以无缝接入,同时相同服务的不同实例又可以通过不同的订阅SQL实现负载均衡。
现有平台在建设过程中,既会涉及通过RPC调用对接已有自研***,又要设计到基于点对点私有通信协议的订单管理***进行二次开发,以及与供应商的第三方***打通,***交互错综复杂,涉及不同调用方式、中间件和数据模型。在本实施例的内存计算服务框架中,利用Hazelcast支持类SQL查询的特性,对所述对象的接口进行了一层简单封装,因此,可以对外提供统一的SQL查询接口。SQL是一种结构化查询语言,通常与关系型存储模型结合使用。本实施例提供的内存计算服务框架中,每个对象存在Key-Value(Hazelcast)和关系型(mysql)两种存储模型,所以本实施例提供的服务框架中存储的数据,不管是在缓存中还是在数据库中,都可以通过一条SQL查询出来,极大降低了使用门槛。除了查询外,应用层还会订阅本实施例提供的内存计算服务框架中的实时数据,Nats提供的原生API需要调用者构造形如A.B.*.C这样的订阅表达式,易用性较低,本实施例提供的内存计算服务框架通过对Nats API的封装,创造性提出了并实现了用SQL来表达订阅条件,这就将订阅和查询接口统一了起来,进一步降低了业务开发门槛,既降低了业务开发成本,又能使第三方工具可以无缝接入,同时相同服务的不同实例又可以通过不同的订阅SQL实现负载均衡。例如,对于同一条SQL语句:select*from orderwhere tradingAccount=‘001120’and exchange=‘SH’,以下不同场景具有不同的语义:
查询。查询属于001120账户的所有上交所(SH)订单(order);
订阅。订阅所有001120账户发往上交所的(SH)订单(order)状态;
Q&S。查询满足条件的订单最新状态,并从最新状态之后接收新的状态变更推送。
本实施例的服务框架对不同的数据获取场景提供统一的SQL接口,是最具价值的创新点之一,既降低了业务开发成本,又能使第三方工具可以无缝接入,同时,相同服务的不同实例又可以通过不同的订阅SQL实现负载均衡。图4是本实施例的内存计算服务框架提供的订阅查询工具界面。在消息查询框中输入SQL语句“select*from orderBO whertradeDate=‘20201230’,可以搜索得到相应的交易信息,方便开发进行问题跟踪和排查;同时,还能通过SQL语句实现消息的查询,订阅和Q&S订阅,使不同的场景拥有了统一的接口,极大地降低了使用门槛。
在开源的Hazelcast的基础上,构建了统一的存储和查询服务,将订阅和查询统一以SQL来表达,极大地降低了使用门槛,提升了所述服务框架的易用性,降低了其他SQL工具的集成成本,达到了读写分离的效果。解决了现有内存计算技术中,服务各自为战,在接口定义,调用方式,存储模型等方面没有形成统一的规范和实践的问题;解决了数据分散在各业务***中,无法做到读写分离,大数据量查询可能引发较长时间GC停顿,甚至服务整体不可用,影响优先级更高的业务请求的处理以及服务整体稳定性的问题。
实施例五
参见图5,本实施例的服务框架采用Query Service原子订阅模式(Q&S订阅)。在实际应用中,有一类特殊的订阅场景,用户不仅需要收到对象状态在订阅生效之后的变更推送,还需要能收到所述对象在订阅之前的最新状态。以一个场景为例:用户A在上午11点订阅了“017856.IB”这只标的的行情,但此标的由于交易不活跃,其最近状态只在10:58变化过,下一次变化可能是1小时之后。此时用户A如果通过普通订阅,那么,由于10:58后1小时内不会有推送,就无法获取这只标的行情。而如果通过本实施例的服务框架查询服务QueryService,在订阅生效的同时用户A也会获取到标的在10:58的行情数据,这也是用户期望的***行为。Q&S订阅模式是本实施例中服务框架的解决方案,在此之前,常用的解决方案是仅查询(Query)模式或仅订阅(Subscribe)模式:用户A会周期性查询标的的行情数据,虽然也能获取到最新行情,但轮询不仅浪费了网络带宽,也给行情服务带来了一定的压力,相比之下,Q&S订阅的方案更加高效。
其实现思路如图5所示:在t=1,2,3…10,共10个时刻,标的的行情信息共有10个消息流。在普通订阅模式下,如果用户在t=6时刻查询这只标的的行情信息,则只能获取到此标的在t=1,2,3,4,5,6时刻的行情数据;如果用户在t=6时刻订阅这只标的的行情信息,则只能获取到t=6,7,8,9,10时刻此标的的行情信息,但无法获取到t=1,2,3,4,5时刻的行情信息。而在Q&S订阅模式下,如果用户在t=6时刻订阅了这只标的的行情信息,则该用户不仅能获取到订阅之后t=6,7,8,9,10时刻此标的的行情信息,还能获取到t=1,2,3,4,5,6时刻此标的的行情数据,这也是用户期望的***行为。在普通订阅模式下,用户只能通过周期性查询标的的行情数据,虽然也能获取到最新行情,但轮询不仅浪费了网络带宽,也给行情服务带来了一定的压力。因此,Query Service原子订阅模式不仅节约了网络带宽,也减轻了行情服务带来的压力,能够更加高效地处理用户的订阅需求。Q&S原子订阅模式高效地解决了消费者盘中重启、断线重连等一系列场景下的数据完整性问题。
现有内存计算中,消息消费时的可靠性机制不完善,大部分服务还是通过订阅、轮询、去重来保证状态的最终一致性,增加了网络带宽消耗和数据生产者的负载。本实施例的内存计算服务框架,创造性地提出了Query&Subscribe原子订阅模式(Q&S订阅),解决了应用层订阅消息可能会丢数据的痛点,同时也解决了消息订阅和查询间隔中会丢失消息的问题,此外,本实施例的内存计算服务框架摒弃了从客户端不断轮询来保证数据一致性的低效做法,节约了网络带宽,也减轻了行情服务带来的压力,能够更加高效地处理用户的订阅需求。
本实施例提供的服务框架统一的服务框架,提供了服务管理,消息路由,订阅发布,数据存储查询等基础能力,提高了内存计算的性能,在解放业务生产力的同时,也提供了内存计算服务的标准开发规范。主要应用于交易、风控、仓位、实时监控、实时指标计算等场景,可作为内存计算服务标准框架推广。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明技术原理的前提下,还可以做出若干改进和变形,这些改进和变形也应视为本发明的保护范围。
在本说明书的描述中,参考术语“一个实施方式”、“某些实施方式”、“示意性实施方式”、“示例”、“具体示例”、或“一些示例”等的描述意指结合所述实施方式或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施方式或示例中。在本说明书中,对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且,描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。
最后应说明的是:以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本实施例技术方案。

Claims (10)

1.一种内存计算服务框架,其特征在于,所述服务框架以Nats作为服务间通信的消息总线;所述服务通过订阅指定的topic来触发业务逻辑处理,处理完成后以消息形式发布所述服务框架的内存状态到指定的topic;所述服务框架使用Hazelcast缓存服务状态。
2.根据权利要求1所述的一种内存计算服务框架,其特征在于,服务使用topic基于Nats进行pub-sub模式的通信,每个topic包含以下属性:名称、类型、topic上传输信息的编码方式、topic的创造者或所有者、模板;当数据生产者向指定topic发布一条消息时,内存计算服务框架SDK根据topic的模板属性抽取消息中的字段值形成subject,Nats根据所述subject以及订阅条件进行消息路由。
3.根据权利要求1所述的一种内存计算服务框架,其特征在于,所述服务框架包括一个管理中心节点Monitor,用于管理***中服务的状态,以及服务注册登录初始化操作;所述服务启动需要经过登录、注册、同步参数、检查依赖;所述Monitor对任何一个服务的状态变化进行广播。
4.根据权利要求3所述的一种内存计算服务框架,其特征在于,服务启动时的依赖检查通过服务状态是否满足依赖来校验,方法如下:a)如果应用配置了启动时依赖,若被依赖方状态不是ACTIVE,则应用的启动会一直等待,直到被依赖方恢复正常;b)如果应用配置了运行时依赖,则被依赖方出现状态变化时,应用收到通知,并进行处理。
5.根据权利要求1所述的一种内存计算服务框架,其特征在于,基于Hazelcast和数据库设置通用数据存储和查询服务;一个基于所述服务框架开发的应用服务在数据模型定义时通过注解指定需要持久化的数据,以及建立查询索引的字段,所述服务框架提供的存储和查询服务自动将数据进行持久化,并提供查询。
6.根据权利要求5所述的一种内存计算服务框架,其特征在于,所述服务框架中,由Cache writer和DB writer服务订阅需要持久化的消息,并且同时独立地分别写入缓存和数据库中;查询请求由框架层的查询服务进行处理,对于实时性要求高的数据从缓存中查询,同时支持从数据库中进行查询。
7.根据权利要求1所述的一种内存计算服务框架,其特征在于,所述服务框架中,一个对象存在Key-Value和关系型两种存储模型,对外提供统一的SQL查询接口。
8.根据权利要求1所述的一种内存计算服务框架,其特征在于,所述服务框架通过对Nats API的封装,用SQL来表达订阅条件,将订阅和查询接口进行统一。
9.根据权利要求1所述的一种内存计算服务框架,其特征在于,所述服务框架采用Query Service原子订阅模式。
10.一种内存计算服务框架实现***,其特征在于,包括:
接入层:支撑客户端的请求,通过消息总线与各个服务交互;
应用层:包括平台服务和业务服务,平台服务支撑业务***,业务服务通过内存计算服务框架SDK统一接入消息总线;
存储层:包括缓存和数据库,存储层专注数据持久化;
所述平台服务通过消息事件驱动,由业务应用通过内存计算产生消息,由平台服务负责消息的存储和查询。
CN202110702160.0A 2021-06-23 2021-06-23 一种内存计算服务框架及实现*** Pending CN113486099A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110702160.0A CN113486099A (zh) 2021-06-23 2021-06-23 一种内存计算服务框架及实现***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110702160.0A CN113486099A (zh) 2021-06-23 2021-06-23 一种内存计算服务框架及实现***

Publications (1)

Publication Number Publication Date
CN113486099A true CN113486099A (zh) 2021-10-08

Family

ID=77936039

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110702160.0A Pending CN113486099A (zh) 2021-06-23 2021-06-23 一种内存计算服务框架及实现***

Country Status (1)

Country Link
CN (1) CN113486099A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115665191A (zh) * 2022-10-09 2023-01-31 浪潮云信息技术股份公司 基于云存储***的用户信息同步方法及***

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107229639A (zh) * 2016-03-24 2017-10-03 上海宝信软件股份有限公司 分布式实时数据库的存储***
CN109241054A (zh) * 2018-08-02 2019-01-18 成都松米科技有限公司 一种多模型数据库***、实现方法以及服务器
CN109446216A (zh) * 2018-09-12 2019-03-08 珠海凡泰极客科技有限责任公司 一种支持sql语法的消息***
CN110333932A (zh) * 2019-06-13 2019-10-15 上海金融期货信息技术有限公司 基于容器云技术的服务编排与依赖关系管理方法和***
CN111966719A (zh) * 2020-10-21 2020-11-20 四川新网银行股份有限公司 一种分布式消费信贷***本地数据缓存实时刷新的方法
CN112532425A (zh) * 2020-11-04 2021-03-19 浙江大学 一种面向边缘计算的消息路由配置方法
CN112637305A (zh) * 2020-12-16 2021-04-09 平安消费金融有限公司 一种基于缓存的数据存储与查询方法、装置、设备及介质
CN112650767A (zh) * 2020-11-30 2021-04-13 中国科学院信息工程研究所 一种数据过滤前置的数据交换方法及***

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107229639A (zh) * 2016-03-24 2017-10-03 上海宝信软件股份有限公司 分布式实时数据库的存储***
CN109241054A (zh) * 2018-08-02 2019-01-18 成都松米科技有限公司 一种多模型数据库***、实现方法以及服务器
CN109446216A (zh) * 2018-09-12 2019-03-08 珠海凡泰极客科技有限责任公司 一种支持sql语法的消息***
CN110333932A (zh) * 2019-06-13 2019-10-15 上海金融期货信息技术有限公司 基于容器云技术的服务编排与依赖关系管理方法和***
CN111966719A (zh) * 2020-10-21 2020-11-20 四川新网银行股份有限公司 一种分布式消费信贷***本地数据缓存实时刷新的方法
CN112532425A (zh) * 2020-11-04 2021-03-19 浙江大学 一种面向边缘计算的消息路由配置方法
CN112650767A (zh) * 2020-11-30 2021-04-13 中国科学院信息工程研究所 一种数据过滤前置的数据交换方法及***
CN112637305A (zh) * 2020-12-16 2021-04-09 平安消费金融有限公司 一种基于缓存的数据存储与查询方法、装置、设备及介质

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
任友理: "《《大数据技术与应用》大数据技术与应用》", 西北工业大学出版社, pages: 121 - 124 *
刘继刚: "海量高性能分布式消息***的设计与实现", 《中国优秀硕士学位论文全文数据库信息科技辑》, no. 05, pages 13 - 81 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115665191A (zh) * 2022-10-09 2023-01-31 浪潮云信息技术股份公司 基于云存储***的用户信息同步方法及***

Similar Documents

Publication Publication Date Title
US20150215386A1 (en) Management of data object sharing among applications
JP6266630B2 (ja) アーカイブされたリレーションを有する連続クエリの管理
US8027922B2 (en) Integration infrastructure
US20120323941A1 (en) Processing Queries for Event Data in a Foreign Representation
US9542708B2 (en) Event server using caching
WO2016123920A1 (zh) 支持多类型数据库操作的集成接口的实现方法及***
US20140136717A1 (en) Configuring cloud resources
WO2020238597A1 (zh) 基于Hadoop的数据更新方法、装置、***及介质
CN108536778B (zh) 一种数据应用共享平台及方法
Yongguo et al. Message-oriented middleware: A review
US10146814B1 (en) Recommending provisioned throughput capacity for generating a secondary index for an online table
US9201700B2 (en) Provisioning computer resources on a network
US8776062B2 (en) Determining desired job plan based on previous inquiries in a stream processing framework
CN110765165B (zh) 一种跨***数据同步处理的方法、装置及***
CN111984849A (zh) 一种信息查询方法、装置、设备及介质
US10951540B1 (en) Capture and execution of provider network tasks
US20180336078A1 (en) Concurrent services caching
CN113486099A (zh) 一种内存计算服务框架及实现***
CN112181950B (zh) 一种分布式对象数据库的构建方法
CN111161818A (zh) 一种基于大数据技术的医疗数据交换共享***及方法
Campbell Service oriented database architecture: App server-lite?
CN113051244B (zh) 数据访问方法和装置、数据获取方法和装置
CN112910980B (zh) 一种数据库访问***和方法
KR101888131B1 (ko) Dds-dbms 연동 도구의 실시간 변경 데이터 발간 서비스 수행 방법
Li Design and implementation of distributed asynchronous data aided computer information interaction system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination