金控集团业务系统建设方案.docx
- 文档编号:12073863
- 上传时间:2023-04-16
- 格式:DOCX
- 页数:126
- 大小:5.24MB
金控集团业务系统建设方案.docx
《金控集团业务系统建设方案.docx》由会员分享,可在线阅读,更多相关《金控集团业务系统建设方案.docx(126页珍藏版)》请在冰豆网上搜索。
金控集团业务系统建设方案
一、项目概述
2.1背景
广州xx金融科技公司(简称“xx金科”)是广州xx金融控股集团有限公司的全资子公司。
xx金科致力于打造成为金融、互联网、大数据以及云计算领域的软硬件综合解决方案提供商和业务咨询专家。
现阶段结合xx集团各子公司业务发展需要,以小微金融服务平台为切入点,开展网络贷款产品的设计研发及平台搭建。
小微金融服务平台网络贷款业务最终将呈现给客户一款在线实时审核实时放款的信用贷款产品。
平台界限内按功能模块进行设计。
平台界限外持续拓展资金提供方、内部数据提供方、实名认证和征信数据等第三方数据提供方、短信通知等外部系统。
整个平台具备完善的系统拓展性确保整个系统的相对独立性、开放性和可扩充性,可使本项目不仅可满足当前的需求,还可以充分考虑充分性满足今后的需求,系统提供标准的数据接口,能与后续扩充的系统灵活对接,共享数据,最大限度避免资源和数据浪费。
二、业务理解
3.1金融业务模式及角色
从上图可以看出,构成xx金控主要业务有互联网信贷业务,未来会增加金融资产交易、大数据征信等服务。
同时也可以提供项目在互联网金融平台上由资金渠道(P2P)承销,形成新的互联网金融平台(B2B、B2C模式)。
3.1.1金融业务核心关注点
金融公司始终围绕着“找客户”、“找项目”、“找资金”三个核心来开展业务,过程控制的最终目标是风险控制。
3.1.2金融业务四大核心问题
金融业务需要解决的四大基础问题,客户、项目、资产、资金。
客户信息的对称、整合的问题。
流程的严谨和灵活的问题。
资产的客户、特殊性,例如同一类房产,地段差异。
资金资源的计划性和效率问题。
通过风险控制手段,降低操作风险,确保项目、资产、资金的安全。
3.2项目生命周期
保理、租赁、互联网小贷等业务均可以抽象成信贷业务,信贷业务可以分为三个大的阶段贷前、贷中、贷后业务。
贷前业务可以分为四大阶段,准入阶段、决策阶段、执行阶段以及放款阶段,当然也可以采用授用信方式简化准入和决策阶段。
贷中可以分为日常检查、质量管理、风险预警、解保、代偿追偿、逾期催收、资产处置、风险管理等过程化的管理。
贷后就是项目结清以及归档闭卷。
3.3互联网信贷平台基础建设核心功能
信息流——信息发布及产品交易管理
平台应具备金融相关产品及服务的信息发布和购买、转让等交易功能,是金融信息服务平台的基本信息流转功能。
资金流——资金结算通道及资金托管
平台应具有资金支付渠道功能,能支持平台上不同形式及多样化产品的购买、转让等资金支付结算要求。
信用风险评价——大数据征信及信用评价机制
平台应具有大数据征信及信用评价机制,能支持平台上有担保措施或纯信用相关资产类的客观信用评价,起到采用大数据进行资产全过程的风险控制及监控作用。
3.4风险控制平台基础建设核心功能
风险控制覆盖在业务的整个生命周期,利用风险监控的数据采集实现数据的整合。
例如央行征信系统、互联网数据、共享数据、政府数据以及其他数据。
利用数据实现模型化、规则化。
实现客户准入、审查审批、放款审批和风险预警的风险支持,确保项目全周期的风险管理、预警。
三、技术解决方案
4.1核心设计思想
4.1.1规范标准、统一管理
标准与规范体系是保障整个项目成功的软性因素,也是系统成功实施最重要的一环,本项目除了贯彻国家有关的标准外,还包括系统整合、集成、协同的实施规范。
通过统一的功能设计规范、统一的业务流程协作规范、统一的数据定义与编码规范、统一的数据交换标准,建立统一的标准规范体系。
这些规范的应用将大大降低实施难度,并可以大大降低日后的维护成本。
管理集中指对系统配置和信息资源的集中化管理,包括组织机构管理、用户管理、身份验证、权限管理、系统管理、配置管理等。
就是采用应用系统集中部署模式。
4.1.2模型驱动、灵活扩展
模型驱动是将系统中易变的部分知识化的一种方法,模型驱动的设计将使得系统拥有柔性的结构,更好地适应需求的不断变化,从而大大提高系统的生命周期。
模型驱动在设计期提供系统的灵活性,其设计结果就是系统的可配置能力和二次开发能力,从而保证系统具有灵活的扩展性。
4.1.3面向对象、J2EE体系
本系统的建设将采用先进的面向对象和组件化的设计思想,在应用软件的设计开发上均应使用目前国际上最成熟、较先进的技术,采用开放的国际标准和规范。
本系统建设基于J2EE技术思想,选择业界领先的、性能稳定的应用服务器,建立以应用服务器为中心的多层体系结构,实现系统数据逻辑、业务逻辑、应用逻辑和表现逻辑的分离,这既保证了系统扩展性,也大大增强了系统的可靠性和安全性。
4.1.4技术成熟、架构开放
系统建设需要采用成熟的技术,确保设计出的系统具有良好的稳定性。
在基于J2EE技术体系结构标准的基础之上,选择开放性、优秀的技术架构解决方案,结合系统的技术要求,建立一个成熟、稳定、可扩展的基础平台。
系统架构的开放性不仅体现在平台的无关性,同时体现在架构的源码开放性上,这样不仅可以提高系统的可维护性,而且降低可能发生的技术风险,确保项目的成功。
4.1.5安全保障、贯穿始终
安全保障体系包括个人身份认证服务、基本安全防护、故障恢复及容灾等整个系统各个层面的安全。
安全保障被体现在硬件、网络、应用系统等各个层面。
在应用层,安全保障措施包括用户认证、权限控制以及系统日志等安全审计手段。
4.2构架设计的关键特性
4.2.1系统灵活性
由于目前互联网金融系统的信息化建设刚起步,很多配套建设尚不成熟,很多业务也有待梳理。
随着信息化建设的深入,不断会有新的需求、新的业务产生,这就要求信息系统不断地进行创新和调整以适应行业的变化,也就是要求系统具有良好的灵活性。
如何保证系统的灵活性,使之能够随着最终用户需求的不断变化而相应的变化,是在本系统规划和设计时需要重点考虑的问题。
本系统是从以下几个方面来考虑的:
◆业务需求的前瞻性
所有的系统都是建立在实实在在的需求上的,我们不能期望一个从来没有被考虑过的需求,能够在将来的某一天在系统中得到很好的支持。
所以要使得系统有最大的灵活性,就必须对业务需求做一个预测,对将来需求的变化考虑得越多,判断得越准确,就能够使得系统拥有更大得灵活性。
在互联网金融系统中,我们多年来一直紧跟学习与研究担保行业发展趋势,不断对创新担保品种保持高度关注,力求这些需求的变化能够较好地在互联网金融系统中得到体现。
◆业务模型的抽象
业务模型是真正决定一个系统对未来需求变化的适应能力,与参数化设计不同的是:
业务模型能决定什么样的业务可以融入到系统中。
我们基于多年在担保行业的经验对担保业务的办理过程进行了抽象和业务建模,初步形成了担保业务模型体系。
◆系统设计的参数化
系统的参数化设计也是一个保证系统灵活性的重要手段,和业务模型的抽象不一样,参数化设计的灵活性体现在对可以预料的需求的变化的处理,譬如说,对流程的参与者的设置,对业务的使用者的授权,以及用户的个性化设置可进行参数化设置等。
4.2.2系统高效性
在集中模式下,由于直接访问系统用户数增多,如何能够保证系统的处理性能成为一个相当突出的问题。
如果这个问题不解决,集中处理模式就无法有效实行。
在集中模式下,影响系统性能的因素主要有以下这些:
◆多层次的网络结构中的数据传输
在集中的模式下,如果传输数据较多,并发用户又多,将造成在通讯数据在网络上的拥挤现象,使得业务处理的响应速度变慢。
◆数据库的数据读取和更新
在大并发业务处理量的情形下,数据库的读写速度将是主要的效率瓶颈。
因为同时对数据库的读写必定涉及到数据库的独占访问,也就是一个业务进程在写数据库记录的时候,其他的业务进程读写该记录时都必须等待,直到该进程写完数据库才能继续执行。
◆系统负载的层级加重
在集中模式下,越往上级,系统处理的数据量便越大,业务量也越大,系统的负载便越重,这是在系统设计时必须考虑到的问题。
在互联网金融系统中,我们采用了多种设计方法来解决以上问题。
这些方法包括:
制定数据传输策略,尽量减少数据在网络上的传输量。
在各级部门采用不同的软硬件配置以适应不同的系统负载。
在集团级采用集群方式以及高性能商业应用服务器实现大并发和大数据量的访问。
采用应用基础框架保证系统的性能。
应用系统的优化。
采用合理的数据库设计,根据不同的数据表类型,对运行过程中只读表、经常需要更新的表和很少需要更新的表进行分别处理。
同时,采用应用服务器,利用数据库缓冲池和容器等特性保证事务处理和并发响应。
另外,我们将在系统设计和开发中不断进行性能测试和调优,以满足对系统的性能指标要求。
4.2.3系统的可伸缩性
系统的可伸缩性是指随着业务的发展,系统需要处理的业务量越来越大,系统如何能够适应这种变化的一种系统特性。
在业务处理量增大的情况下,如果原有的系统无法保证所需的处理能力,一般可以采取以下的几种办法:
调整系统允许的硬件设施,这包括增加内存,使用主频更高的CPU,增加CPU的数量,使用存取速度更快的硬盘和磁盘阵列,申请更大的网络带宽,或者更换成更高档的机器。
但是这些变动都是只能影响到一台机器之上,其调整所能够达到的程度有一个极限,超过了这个极限这种调整就无法进行了。
通过集群的方法。
当需要更大的处理能力的时候,可以通过简单的增加一个机器加入的集群中去,并把其中的一部分功能分布到这台机器上,就能成倍的提高系统的处理能力。
而且这种增加系统可伸缩性的能力理论上是不受限制的。
但是这种集群方法一般是需要系统支持的。
在本系统中,为保证系统可伸缩性,我们在系统基础框架中使用了EJB作为开发系统的载体,使用这种技术J2EE规范可以保证这些EJB可以使用集群的方式来提高系统的可伸缩性。
这样就能适应业务发展的需求,从而保护系统投资。
4.2.4系统的稳定性和可靠性
系统的稳定性和可靠性是指系统在一段时间内,平均出现故障时间的比例。
系统稳定性和高可用性对互联网金融系统是非常关键的,因为一旦系统出现了故障,并且如果不能很快的进行恢复,那么势必对繁忙的担保业务造成严重的影响,而数据的丢失更是不能允许的。
为保证系统的稳定性和可用性,应用平台的选择和应用框架的选择非常重要,因为这是业务允许的基础框架,只有基础框架稳定,才能保证上面允许的信息系统稳定。
在互联网金融系统中,我们采用了Java语言作为实现语言,J2EE作为底层容器,工作流系统作为系统的应用开发框架。
采用Java语言作为实现语言,可用避免在C/C++语言中绝大部分由于指针或者内存访问等引起的系统崩溃等问题,从而大大的提高系统的稳定性;采用J2EE架构是因为J2EE架构提供了对应用透明的并发连接处理、多线程调度、安全性控制、交易事务等底层的功能,采用工作流作为信息系统的应用开发框架,保证业务的流程和业务处理本身的分离,使得开发人员可以集中精力解决业务处理本身的逻辑,而把复杂的业务流程处理留给工作流系统处理,从而使得造成系统稳定性的可能减到最小,最终提供系统的稳定性。
除了选择合理的应用平台和开发框架外,本系统将采用完全面向对象的分析和设计方法进行开发,从需求、分析、设计到实现,开发中的每一个过程都将经过严格的验证,并且经过多轮的压力测试和破坏性测试,使得系统稳定性从一开始就得到了重视,并一直贯穿在整个开发过程中。
4.3系统整体设计
4.3.1系统总体架构设计
整体系统包括如下几部分组成,各部分通过金控基础平台有效整合在在一起,
金控基础平台系统,互联网信贷系统,互联网金融系统,接口系统,移动应用系统等几部分
基于金融平台和互联网金融平台为基础,结合基础工具,流程引擎、规则引擎、报表工具、门户及接口系统等,满足xx金控互联网信贷业务需求。
4.3.2系统逻辑架构设计
供应链金融服务平台作用体现为供应链金融和互联网技术融合之下更好地服务于企业、机构服务。
其总体逻辑结构图如下:
平台通过互联网信贷业务发掘融资需求,构建信用风险评估体系,为企业以及个人提供融资服务、信贷服务等相关金融服务:
⏹前台门户网站:
主要为公司开展的信贷业务以及互联网融资业务分域名进行前端展示及用户管理,用户进入角色分为,企业用户、合作机构用户、个人用户。
互联网金融网站设计做到界面简洁清晰,色彩搭配合理,力求交互人性化。
⏹后台管理系统
后台管理中包含支撑业务开展的风险管理系统、产品定义/核算平台、电子支付平台、基础框架平台等子平台。
以下为后台管理中子平台的相关解释;
1.授信审查审批:
类似商业银行授信业务系统,包括授权管理的审计、凭证和记录的审计、授信业务操作环节的审计等;
2.交易反欺诈:
对接交易反欺诈系统,包括用户行为风险识别引擎,征信系统,黑名单系统等组成;
3.贷后管理:
主要是还款统计、逾期追踪和催收管理;
4.产品定义/核算平台:
贷款产品工厂,这里可根据业务需求生成不同的产品;
5.工作流引擎是产品的基础应用部分,可自由根据角色、分工和条件的不同提供信息流转、内容等级等功能。
工作流引擎包括流程的节点管理、流向管理、流程样例管理等;
6.规则引擎是产品中的基础应用部分,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。
接受数据输入,解释业务规则,并根据业务规则做出业务决策;
7.安全审计是产品中的基础应用部分,系统产品可按需进行安全漏洞扫描,加固产品安全等级,防止恶意的网络攻击。
另一方面具有完备的客户端和运营端日志记录,方便业务安全审计;
8.报表引擎:
基于资金数据、产品数据、交易数据、运营数据等数据,提供业务所需要的统计报表;
9.门户框架:
前台门户网站及移动端框架设置;
10.岗位权限:
用户角色,权限管理;
11.数据管理:
通过元数据的支持和标准化的数据要求,对业务流程进行有效、准确的支撑;
12.公共管理:
通过ETL调度管理保证数据抽取系统流程自动化,并有自动调度功能;抽取的数据及时、准确、完整;利用在线监控管理和安全管理统对平台业务流程进行实时监控管理,保证系统运行的安全性和稳定性
⏹数据接口
1.用于对接外部数据,可对接企业ERP、OA、财务系统、物联网以及外部征信系统,如央行征信系统等;
2.对于非结构化资源,我们将通过相应的资源采集工具完成数据的统一管理与维护。
对于结构化资源,我们将通过全面的接口管理体系进行相应资源搭建,数据经过有效的资源审核和分析处理后进入到平台;
⏹大数据平台
支持标准Hadoop发型版本的常用特性(包括HDFS、Pig、Hive、Map-Reduce,Kafka等),又加入了一些自主优化和开发的组件,借助一种动态流水线机制直接运行于Hadoop中的HDFS之上,具有流式计算框架和即时计算框架等特点。
4.3.3系统技术架构设计
下图对本次项目整体开发架构进行了设计,从图我们可以看出,本次项目整体建设内容应当包含了相关体系架构的搭建、应用功能完善可开发、应用资源全面共享与管理。
⏹业务展现层
整体应用功能将通过门户方式进行展现,架构分别设计了内网门户和外网门户,不同的应用人员通过登录可以实现相关系统的应用和资源的浏览查询操作;统一的基于标准实体模型的视图模型定义;基于标准的js框架的页面动作定义;基于标准视图模型与实体模型的通用控制层。
⏹技术组件层
技术架构采用行业内主流J2EE开源技术进行高度封装、形成便于公司管理产品研发应用的开发平台。
提供了基于Web的企业应用的设计、开发、调试、部署、管理和维护的一体化开发、运行、管理监控环境。
开发平台封装的主流技术如下:
SOA:
系统采用SOA及组件化
工作流:
ZDSWorkFlow封装行业流行、稳定的工作流引擎
安全框架:
SpringSecurity
规则引擎:
ZDSDrools
消息框架:
ActiveMQ
报表引擎:
帆软报表工具
ZDSWorkFlow工作流引擎可自由根据角色、分工和条件的不同提供信息流转、内容等级等功能,并包括流程的节点管理、流向管理、流程样例管理等。
ZDSDrools规则引擎实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策;接受数据输入,解释业务规则,并根据业务规则做出业务决策。
通过工作流工具和规则引擎的配置管理,可灵活适应政府机构、政策调整的变动。
平台具有高可扩展性、技术先进性,不仅满足目前项目的功能建设,也满足未来业务发展对系统功能扩充的需求,插件式开发模式,将各个业务模块进行解耦,达到各个业务组件能够独立运行和集成运行。
统一标准的业务模块定义;统一标准的实体模型定义;多样化的实体模型组件(如树形实体、日期维度实体、规则实体、指标实体);统一标准的业务服务定义及管理;统一的数据访问接口和数据交互支持;实现复杂的调度任务配置,在多产品使用调度组件时,可以做到数据权限配置功能。
平台具有岗位权限管理功能,实现用户角色、权限的可视化管理。
⏹数据处理层
封装底层数据库操作接口,将需要事务处理进行明确声明;支持多数据库数据源管理
功能上简单灵活,易于管理;对结构化数据和非结构化数据进行调度和存储。
结构化数据包括:
XML和DBMS。
非结构化数据包括:
文本文件、音视频文件、office系列文件、图形图像文件及ZIP、PDF、SWF等其他格式文件等;大数据平台集成了市场流行的Storm、Spark和Mapreduce三种计算框架,以及HDFS、Hbase、MySQL、pig、hive数据存储服务,并具有高效、稳定、高性能、易扩展的特点;成熟的大数据技术与管理平台,高性能的实时与离线计算能力,丰富的算法库及业务模型。
HDFSHadoop核心组件,海量数据的分布式文件系统。
HBaseHadoop上的NoSQL数据库,支持海量数据高速存取。
MySQL流行的开源关系数据库,特别适合Web应用。
pig允许对分布式数据集进行类似SQL的查询,Pig可以简化Hadoop的使用。
hive可以通过类SQL语句快速实现简单的MapReduce统计,十分适合数据仓库的统计分析。
⏹应用服务层
支持主流应用中间件,如Weblogic,Websphere,Tomcat等,单一部署和集群部署。
⏹数据存储层
支持各种非结构化(如HDFS、互联网数据)和结构化关系型数据库(如Oracle、Mysql等)数据物理存储。
4.3.4系统运行架构设计
运行架构关注进程、线程、中断服务程序等运行时控制流,以及相关的并发、同步、通信等问题。
运行架构的设计(及其所依赖的物理架构设计)对运行期质量属性有重大影响,例如性能、可伸缩性、持续可用性和安全性等。
1.用户通过门户系统或者移动端APP接入业务系统、在线分析、查询、报表等平台功能。
2.系统对外统一提供标准化接口,各子模块,如计算资源,存储资源和网络资源子模块通过相应的API接口服务对外提供服务。
3.结构化和非结构化资源分别通过ETL到相应的物理存储和数据缓存区。
4.元数据管理服务为系统平台提供更快速、高效的技术和业务支持。
5.批处理服务和通用服务保障整个平台运行的安全性、稳定性和可容错性。
另外,系统运营满足如下要求:
1、采用可靠、稳定的商业化技术架构,以保证系统的安全、稳定。
2、根据系统运行要求等级,该系统满足7*24小时的服务要求。
3、系统内保留用户所有的浏览痕迹,并提供分析报表。
4、提供用户页面监控在线用户数和用户清单。
5、系统服务有独立日志,并提供日志察看、分析工具,错误日志可分类检索,系统故障类型在程序中需有较完善定义。
6、系统配备完善的文档,包括但不限于:
系统设计方案、系统部署文档、系统操作手册、系统源代码说明等。
4.3.5系统数据架构设计
⏹数据源
1.结构化数据:
传统关系型数据库中记录的数据,包括外部征信系统,核心财务系统,核心ERP系统,物流系统等数据。
2.非结构化数据:
相对于关系型数据,主要包括业务处理过程中产生的文本、图像、声频,还包括外部的社交媒体和网络数据。
⏹数据交换层
1.批量交换:
用于产生层与整合层和应用层间非实时的、大数据量的数据交互。
2.实时交换:
用于交易系统间少量、实时或者准实时的数据交互。
⏹数据交换层
1.缓存数据:
缓存从交换层接收的所有源系统数据,是后续数据处理的基础。
2.操作型数据:
作为源系统的镜像,支持快速应用和联机查询。
3.公共汇总:
后续应用的共性加工,减少重复加工和口径不一致。
4.非结构化数据统一处理:
利用Hadoop技术处理非结构化,完成结构化处理和汇总。
⏹数据访问层
1.通过数据缓存、数据发布、数据交付、数据链接等业务功能为数据服务层提供更快速、稳定的业务支持。
⏹数据访问层
1.上下游系统:
下游经销商、上游供应商企业等业务系统
2.固定报表:
结果展现有规定的格式或固定的查询方法。
3.多维分析:
随意的组合维度和指标间的关系,从而更灵活的对数据进行分析。
4.灵活查询:
用户通过查询工具和平台自由、快速的获取其关心的信息。
5.数据导出:
提供数据格式化导出,以满足较小数据量的临时性分析以及外部监管要求所需的接口数据。
6.数据挖据:
由数据使用的专业人士,通过根据不同的业务场景选择不同的挖掘算法,从现有数据挖掘和探索数据背后影藏的规则,从而进行业务预测和归类。
4.3.6系统部署架构设计
⏹物理拓扑结构
数据库和大数据计算服务分别部署到5台服务器上,数据库并采用集群方式,大数据计算服务采用分布式方式,ETL采用单独服务器,应用服务器按照互联网融资2台集群和商业保理2台集群的方式,Web服务器按照互联网融资2台集群和商业保理2台集群的方式,Web服务器部署网站服务和移动服务。
具体拓扑结构如下图:
⏹系统运行建议配置
需要设备
数量
设备配置
备注
数据服务器
5台
2C8核\64G内存\1T硬盘
数据库服务器,数据计算与存储
Web服务器
4台
2C8核\32G内存\500G硬盘
提供对互联网的web服务
应用服务器
4台
2C8核\32G内存\500G硬盘
发布应用服务、报表服务
ETL
1台
2C8核\32G内存\500G硬盘
ETL服务
⏹系统部署
系统在架构部署上一方面将数据库服务器以及应用服务器采用集群的方式,保证单台机器出现故障不影响业务开展。
另一个层面是系统软件设计层面上考虑高可用性,如系统功能升级扩展、系统故障及时排除、系统备份恢复策略、系统稳定性、系统响应性能等角度在系统设计及实现上进行充分考虑。
⏹软件环境配置
环境名称
软件版本
操作系统
LinuxCentOS5.0以上版本(支持WindowsServer2008)
客户端浏览器
IE8.0~10.0、Firefox
数据库
MySQL5.5以上版本(支持Oracle/SQLServer)
Java环境
JDK1.6以上版本
应用中间件
开源支持:
JBoss、Tomcat、Jetty等
商业支持:
Weblogic、WebSphere等
⏹互联网云服务器模式
系统支持多种互联网云服务器部署,如在阿里云等运营服务商租用云虚拟服务器,由云服务商负责服务器及安全维护,每年会产生服务器租用费用,支持移动办公接入或手机接入,安全性较高,服务器配置可根据应用需求动态弹性调整。
4.3.7系统扩容技术设计
系统采用“垂直扩展”和“横向扩展”技术。
垂直扩展是在同一个逻辑单位添加资源以增加容量,如升级服务器的CPU,如在RAID/SAN存储设备上增加硬盘;横向扩展是增加多个逻辑单元资源并且使他们作为一个整体在工作。
集群解决方案通过主从实时同步技术实现集群服务器之间的数据实时同步工作,如分布式文件系统,负载均衡和
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 集团 业务 系统 建设 方案