1.本发明涉及大数据入库
技术领域：
：，尤其涉及一种利用分布式多线程技术进行大数据入库的云平台系统。
背景技术：
：：2.大数据处理技术涉及到的知识面非常广泛，且可以利用的语言和工具也非常多。针对不同数量级的大数据信息，使用的大数据技术架构也千差万别。因此，如何通过数据量级以及具体业务逻辑判断选型出一个更合理的大数据处理架构至关重要。3.当前新能源电力信息化系统中，处理大数据量入库技术一般都是搭建hadoop集群或者使用一些nosql数据库进行批量存储。此类架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大。4.在这个背景下，考虑到新能源电力系统针对不同量级的大数据处理平台技术多样化，且适用性不是很强。技术实现要素：5.(一)解决的技术问题6.针对现有技术的不足，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。7.(二)技术方案8.本发明提供如下技术方案：一种利用分布式多线程技术进行大数据入库的云平台系统，包括服务注册模块，所述服务注册模块电信连接有服务调用模块，所述服务调用模块电信连接有服务熔断模块，所述服务熔块模块电信连接有敷在均衡模块，所述敷在均衡模块电信连接有服务降级模块，所述服务降级模块电信连接有服务消息模块。9.通过本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统能够便于对数据进行查询，且相对于普通的云平台系统，本发明所提供的平台系统具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。10.在一种可能的实施方式中，所述服务消息模块电信连接有配置管理模块，所述配置管理模块电信连接有服务网关模块，所述服务网网关模块电信连接有服务监控模块，所述服务监控模块电信连接有链路追踪模块，所述链路追踪模块电信连接有自动化构建模块，所述自动化构建模块电信连接有服务定时调度模块。11.通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。12.对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。13.在一种可能的实施方式中，所述服务注册模块和配置管理模块使用的技术解决方案为阿里巴巴开的开源产品nacos。14.在一种可能的实施方式中，所述服务降级模块和服务熔断模块使用阿里巴巴开源的产品sentinel。15.在一种可能的实施方式中，所述服务消息模块所使用的技术解决方案为apacherocketmq。16.在一种可能的实施方式中，所述服务网关模块使用的技术解决方案为spring提供的服务网关组件gateway。17.在一种可能的实施方式中，所述服务监控模块与链路追踪模块使用的技术解决方案是springcloudsleuth。18.在一种可能的实施方式中，所述服务调用模块使用的技术解决方案是spring自研的openfeign服务，服务开发使用的技术解决方案是springboot框架。19.服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。20.与现有技术相比，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，具备以下有益效果：21.1、本发明通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。22.2、本发明服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。23.3、本发明对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。24.应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。附图说明25.图1为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的执行原理示意图；26.图2为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的springcloudstream的架构图；27.图3为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的云平台总体示意流程图；28.图4为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的平台构成图。具体实施方式29.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。30.所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。31.在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。32.在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。33.如图1-4所示，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，包括服务注册模块，所述服务注册模块电信连接有服务调用模块，所述服务调用模块电信连接有服务熔断模块，所述服务熔块模块电信连接有敷在均衡模块，所述敷在均衡模块电信连接有服务降级模块，所述服务降级模块电信连接有服务消息模块。34.通过本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统能够便于对数据进行查询，且相对于普通的云平台系统，本发明所提供的平台系统具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。35.在一种可能的实施方式中，所述服务消息模块电信连接有配置管理模块，所述配置管理模块电信连接有服务网关模块，所述服务网网关模块电信连接有服务监控模块，所述服务监控模块电信连接有链路追踪模块，所述链路追踪模块电信连接有自动化构建模块，所述自动化构建模块电信连接有服务定时调度模块。36.通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。37.对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。38.在一种可能的实施方式中，所述服务注册模块和配置管理模块使用的技术解决方案为阿里巴巴开的开源产品nacos。39.在一种可能的实施方式中，所述服务降级模块和服务熔断模块使用阿里巴巴开源的产品sentinel。40.在一种可能的实施方式中，所述服务消息模块所使用的技术解决方案为apacherocketmq。41.在一种可能的实施方式中，所述服务网关模块使用的技术解决方案为spring提供的服务网关组件gateway。42.在一种可能的实施方式中，所述服务监控模块与链路追踪模块使用的技术解决方案是springcloudsleuth。43.在一种可能的实施方式中，所述服务调用模块使用的技术解决方案是spring自研的openfeign服务，服务开发使用的技术解决方案是springboot框架。44.服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。45.如图1所示：该方案的核心为1id三组件，其说明分别如下：46.1id指的就是全局唯一的事务id，即transactionidxid；47.全局唯一的事务id用于标注某些操作数据同一个事务的；不管你这个操作涉及到几个数据库，最终都数据一套事务操作；48.分布式事务三组件分别是tc(transactioncoordinator)-事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。49.tm(transactionmanager)-事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。即控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议；50.rm(resourcemanager)-资源管理器：管理分支事务处理的资源，与tc交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。即控制分支事务，负责分支注册、状态汇报，并接受事务协调器的指令，驱动分支(本地)事务的提交和回滚；51.rm就可以理解为数据库；52.其处理流程如下：tm向tc申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的xid；53.xid在微服务调用链路的上下文中传播；54.rm向tc注册分支事务，将其纳入xid对应全局事务的管辖；55.tm向tc发起针对xid的全局提交或回滚决议；56.tc调度xid下管辖的全部分支事务完成提交或回滚请求。57.如图2所示：springcloudstream是用于构建与共享消息传递系统连接的高度可伸缩的事件驱动微服务框架，该框架提供了一个灵活的编程模型，他建立在已经建立和熟悉的spring术语和最佳实践上，包括支持持久化的发布/订阅、消息组以及消息分区这三个核心概念；58.如上图所示，为springcloudstream的架构图，他大致的模型，如下介绍：59.binder组件为一个很方便的连接中间件，屏蔽mq具体实现产品之间的差异；60.channel组件，该部分为通道，是队列queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过channe对队列进行配置；61.source和sink简单的可将其理解为参照对象，是springcloudstream自身，从stream发布消息就是输出，接受消息就是输入。62.通过对设计模式的封装，使项目中的代码更加规范，符合了如下七大原则:63.单一职责原则:64.对类来说的，即一个类应该只负责一项职责；65.接口隔离原则，即：interfacesegregationprinciple66.所谓的接口隔离原则，即：客户端不应该依赖他不需要的接口，即一个类对另外一个类的依赖应该建立在最小的接口上；67.依赖倒转原则:68.依赖倒转原则dependenceinversionprinciple是指：69.高层模块不应该依赖底层模块，二者都应该依赖其抽象；70.抽象不应该依赖细节，细节应该依赖抽象；71.依赖倒转(倒置)的中心思想是面向接口编程；72.依赖倒转原则是基于这样的设计理念：相对于细节的多边形，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类；73.使用接口或抽象类的目的是制定好规范，而不设计任何具体的操作，把展现细节的任务交给他们的实现类去完成；74.这里也体现出了一点，接口和抽象类的价值在于设计，而在使用设计模式的时候，其接口和抽象类就会起到很重要的作用。75.里式替换原则:76.如果有一个类型为t1的对象o1，都有类型为t2的对象o2，使得以t1定义的所有程序p在所有的对象o1都代换成o2时，程序p的行为没有发生变化，那么类型t2是类型t1的子类型。换句话说，所有引用基类的地方必须能够透明的使用其子类的对象；77.在使用继承的时候，遵循里氏替换原则，在子类中尽量不要去重写父类的方法；78.里氏替换原则，继承实际上是让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。79.开闭原则:80.开闭原则，即openclosedprinciple，是编程中最基础、最重要的设计原则；前面所提到的所有原则，都是为了开闭原则做准备的；开闭原则可以总结为以下几点:81.一个软件实体，如类、模块、函数，应该对拓展开放(针对提供方)，对修改关闭(针对使用方)。即，拓展的时候，不对已经在使用的代码进行改动；也就是说，当拓展功能的时候，尽量不要去修改代码，而是新增代码；因为你正在修改的代码，有可能是别的地方正在使用的代码，这样就会造成意想不到的bug；但是对于新增的类或者方法来说，因为是新增的，所以一般不会对原有的功能造成破坏；用抽象构建框架，用实现拓展细节；82.当软件需要变化时，尽量通过拓展软件实体的行为来实现变化，而不是通过修改已有的代码来实现；83.在编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则；开闭原则其实就是编程思想的核心。84.迪米特法则:85.迪米特法则，可以简单归纳为以下几点：86.一个对象应该对其他对象保持最少的了解；87.类与类关系越密切，耦合度越大；88.迪米特法则(demeterprinciple)又叫做最少知道原则，即一个对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息；89.迪米特法则还有个更简单的定义：只与直接的朋友通讯；90.每个对象都会与其他对象产生耦合关系，只要两个对象之间有耦合关系，就说这两个对象之间是朋友关系。耦合的方式很多，如依赖、关联、组合、聚合等。其中，称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。91.合成复用原则:92.合成复用原则指的是尽量使用合成、聚合的方式，而不是使用继承；93.在本应用中主要使用到了如下设计模式：94.工厂设计模式：95.该模式将将实例化对象的代码抽取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦，从而提高项目的拓展和维护性；工厂模式常用的有简单工厂模式、抽象工厂模式和工厂方法模式。96.单例设计模式：97.该模式采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法，该方法一般为静态方法；98.如hibernate中的sessionfactory，他充当数据存储源的代理，并负责创建session对象，sessionfactory并不是轻量级的，一般情况下，一个项目通常只需要创建一个sessionfactory就够用了，这时就会使用到单例设计模式；99.在本应用中，将需要频繁的进行创建和销毁的对象，创建对象耗时过多或消耗资源过多，即重量级对象，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象，如数据源、session工厂等对象都以单例模式进行实现。100.策略设计模式：101.策略模式的关键是：分析项目中变化部分与不变部分；102.策略模式的核心思想是：多用组合/聚合，少用继承；用行为类组合，而不是行为的继承，这样的设计使代码更有弹性；103.体现了“对修改关闭，对扩展开放”原则，客户端增加行为不用修改原有代码，只要添加一种策略(或者行为)即可，避免了使用多重转移语句(if..elseif..else)；104.该模式提供了可以替换继承关系的办法：策略模式将算法封装在独立的strategy类中使得你可以独立于其context改变它，使它易于切换、易于理解、易于扩展；105.需要注意的是：每添加一个策略就要增加一个类，当策略过多是会导致类数目庞大。106.享元模式:107.因系统中有大量对象，这些对象消耗大量内存，并且对象的状态大部分可以外部化，在此选用享元模式来对其进行实现；108.用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用hashmap/hashtable存储；109.享元模式大大减少了对象的创建，降低了程序内存的占用，提高效率；但享元模式提高了系统的复杂度，需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着内部状态的改变而改变，这是使用享元模式需要注意的地方；110.使用享元模式时，注意划分内部状态和外部状态，并且需要有一个工厂类加以控制；111.享元模式经典的应用场景是需要缓冲池的场景，比如string常量池、数据库连接池。112.模板方法设计模式：113.该模式的基本思想是，算法只存在于一个地方，也就是在父类中，容易修改。需要修改算法时，只要修改父类的模板方法或者已经实现的某些步骤，子类就会继承这些修改；114.这种设计模式实现了最大化代码复用，父类的模板方法和已实现的某些步骤会被子类继承而直接使用，既统一了算法，也提供了很大的灵活性。父类的模板方法确保了算法的结构保持不变，同时由子类提供部分步骤的实现；115.该模式的不足之处是每一个不同的实现都需要一个子类实现，导致类的个数增加，使得系统更加庞大；116.一般模板方法都加上final关键字，防止子类重写模板方法；117.模板方法模式使用场景与数据入库是相吻合的，即当要完成在某个过程，该过程要执行一系列步骤，这一系列的步骤基本相同，但其个别步骤在实现时可能不同，通常考虑用模板方法模式来处理。118.代理模式：119.该模式为一个对象提供一个替身，以控制对这个对象的访问，即通过代理对象访问目标对象，这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能。120.被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象。121.代理模式有不同的形式,主要有三种:静态代理、动态代理(动态代理又称之为jdk代理、或接口代理)和cglib代理(可以在内存动态的创建对象，而不需要实现接口，他是属于动态代理的范畴)。122.如图3所示：每天采购、预测、回传、收资产生的各场站测风塔、光辐照仪、预测功率数据、预测气象数据、实际功率数据、光伏实际功率数据、超短期预测功率数据、风机状态数据、生产记录数据、上报记录数据，将会被记录在待入库数据表中，该表记录上述文件的基本信息，包括文件名称、原始文件存放目录等。123.任务调度服务，定期调用执行任务，通过读取待入库信息表中的记录信息，获取文件基本信息，根据文件基本信息对文件进行验证，验证失败的将相应的错误信息保存到入库失败信息记录表；验证成功的将对其进行解析，解析成功后将数据入库，入库成功后，将待入库信息转存到入库成功信息记录表；解析失败的将相应的错误信息保存到入库失败信息记录表。124.如图4所示：应用由两个独立部署的工程构成，一部分是任务调度应用平台，另一部分是数据服务平台；任务调度平台以高可用集群形式部署，所有任务信息在每个节点上以全量方式保存在一个列表中，对外只有master对外提供服务，当master主机出现故障时，通过选举机制，从其他的slave中选出新的master继续对外提供服务；以此消除服务的单点故障，保证服务的高可用。125.数据服务平台对外服务，通过nacos实现负载均衡，大数据入库服务通过自研算法实现组内高可用和组外负载均衡；组内节点在主机正常的情况下，由主机提供服务，当主机出现问题时，由从机接管；每组服务通过服务标识加载相应的数据，所有数据均摊在每个组中，实现组外负载均衡。126.尽管已经示出和描述了本发明实施的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。127.需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。128.下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。当前第1页12当前第1页12
技术领域：
：，尤其涉及一种利用分布式多线程技术进行大数据入库的云平台系统。
背景技术：
：：2.大数据处理技术涉及到的知识面非常广泛，且可以利用的语言和工具也非常多。针对不同数量级的大数据信息，使用的大数据技术架构也千差万别。因此，如何通过数据量级以及具体业务逻辑判断选型出一个更合理的大数据处理架构至关重要。3.当前新能源电力信息化系统中，处理大数据量入库技术一般都是搭建hadoop集群或者使用一些nosql数据库进行批量存储。此类架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大。4.在这个背景下，考虑到新能源电力系统针对不同量级的大数据处理平台技术多样化，且适用性不是很强。技术实现要素：5.(一)解决的技术问题6.针对现有技术的不足，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。7.(二)技术方案8.本发明提供如下技术方案：一种利用分布式多线程技术进行大数据入库的云平台系统，包括服务注册模块，所述服务注册模块电信连接有服务调用模块，所述服务调用模块电信连接有服务熔断模块，所述服务熔块模块电信连接有敷在均衡模块，所述敷在均衡模块电信连接有服务降级模块，所述服务降级模块电信连接有服务消息模块。9.通过本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统能够便于对数据进行查询，且相对于普通的云平台系统，本发明所提供的平台系统具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。10.在一种可能的实施方式中，所述服务消息模块电信连接有配置管理模块，所述配置管理模块电信连接有服务网关模块，所述服务网网关模块电信连接有服务监控模块，所述服务监控模块电信连接有链路追踪模块，所述链路追踪模块电信连接有自动化构建模块，所述自动化构建模块电信连接有服务定时调度模块。11.通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。12.对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。13.在一种可能的实施方式中，所述服务注册模块和配置管理模块使用的技术解决方案为阿里巴巴开的开源产品nacos。14.在一种可能的实施方式中，所述服务降级模块和服务熔断模块使用阿里巴巴开源的产品sentinel。15.在一种可能的实施方式中，所述服务消息模块所使用的技术解决方案为apacherocketmq。16.在一种可能的实施方式中，所述服务网关模块使用的技术解决方案为spring提供的服务网关组件gateway。17.在一种可能的实施方式中，所述服务监控模块与链路追踪模块使用的技术解决方案是springcloudsleuth。18.在一种可能的实施方式中，所述服务调用模块使用的技术解决方案是spring自研的openfeign服务，服务开发使用的技术解决方案是springboot框架。19.服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。20.与现有技术相比，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，具备以下有益效果：21.1、本发明通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。22.2、本发明服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。23.3、本发明对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。24.应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本发明。附图说明25.图1为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的执行原理示意图；26.图2为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的springcloudstream的架构图；27.图3为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的云平台总体示意流程图；28.图4为本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统的平台构成图。具体实施方式29.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。30.所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。31.在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。32.在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通或两个元件的相互作用关系。对于本领域的普通技术人员而言，可以根据具体情况理解上述术语在本发明中的具体含义。33.如图1-4所示，本发明提供了一种利用分布式多线程技术进行大数据入库的云平台系统，包括服务注册模块，所述服务注册模块电信连接有服务调用模块，所述服务调用模块电信连接有服务熔断模块，所述服务熔块模块电信连接有敷在均衡模块，所述敷在均衡模块电信连接有服务降级模块，所述服务降级模块电信连接有服务消息模块。34.通过本发明所提供的一种利用分布式多线程技术进行大数据入库的云平台系统能够便于对数据进行查询，且相对于普通的云平台系统，本发明所提供的平台系统具备提升新能源电力信息化系统处理大数据入库效率、提高系统功能可拓展性、易维护行、稳定性以及降低运维成本等优点，用于解决现有技术中架构虽然能有效的进行数据存储，但数据使用方面不是很方便，并且后期运维难度和工作量相对较大，对于技术人员水平要求较高，成本非常大的问题。35.在一种可能的实施方式中，所述服务消息模块电信连接有配置管理模块，所述配置管理模块电信连接有服务网关模块，所述服务网网关模块电信连接有服务监控模块，所述服务监控模块电信连接有链路追踪模块，所述链路追踪模块电信连接有自动化构建模块，所述自动化构建模块电信连接有服务定时调度模块。36.通过为保证数据入库操作的幂等性，在数据库表结构上，使用联合主键对其进行控制，在数据的处理逻辑上，每个节点根据自己的标识去处理相应的数据，保证数据的处理操作有且仅有一次，以开源架构springboot为基础架构，快速的构建数据服务应用。37.对于数据的查询服务和可视化服务，按不同场景将服务封装到一个个单独的springboot应用中，构建微服务应用，对于某些热点服务，将以集群的方式进行部署，以提高并发能力和稳定性。38.在一种可能的实施方式中，所述服务注册模块和配置管理模块使用的技术解决方案为阿里巴巴开的开源产品nacos。39.在一种可能的实施方式中，所述服务降级模块和服务熔断模块使用阿里巴巴开源的产品sentinel。40.在一种可能的实施方式中，所述服务消息模块所使用的技术解决方案为apacherocketmq。41.在一种可能的实施方式中，所述服务网关模块使用的技术解决方案为spring提供的服务网关组件gateway。42.在一种可能的实施方式中，所述服务监控模块与链路追踪模块使用的技术解决方案是springcloudsleuth。43.在一种可能的实施方式中，所述服务调用模块使用的技术解决方案是spring自研的openfeign服务，服务开发使用的技术解决方案是springboot框架。44.服务定时调度模块使用开源的xxl-job架构，对任务进行全方面的监控和调度，便于实现任务的横向拓展，在数据量增大的时候，依托springboot应用的便携性，可以快速部署应用节点，同时在任务调度平台上对其进行配置，使各节点均摊服务，达到负载均衡效果；在逻辑实现方面，封装了工厂设计模式和策略设计模式，使代码更加简洁，便于维护和二次开发。45.如图1所示：该方案的核心为1id三组件，其说明分别如下：46.1id指的就是全局唯一的事务id，即transactionidxid；47.全局唯一的事务id用于标注某些操作数据同一个事务的；不管你这个操作涉及到几个数据库，最终都数据一套事务操作；48.分布式事务三组件分别是tc(transactioncoordinator)-事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。49.tm(transactionmanager)-事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。即控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议；50.rm(resourcemanager)-资源管理器：管理分支事务处理的资源，与tc交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。即控制分支事务，负责分支注册、状态汇报，并接受事务协调器的指令，驱动分支(本地)事务的提交和回滚；51.rm就可以理解为数据库；52.其处理流程如下：tm向tc申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的xid；53.xid在微服务调用链路的上下文中传播；54.rm向tc注册分支事务，将其纳入xid对应全局事务的管辖；55.tm向tc发起针对xid的全局提交或回滚决议；56.tc调度xid下管辖的全部分支事务完成提交或回滚请求。57.如图2所示：springcloudstream是用于构建与共享消息传递系统连接的高度可伸缩的事件驱动微服务框架，该框架提供了一个灵活的编程模型，他建立在已经建立和熟悉的spring术语和最佳实践上，包括支持持久化的发布/订阅、消息组以及消息分区这三个核心概念；58.如上图所示，为springcloudstream的架构图，他大致的模型，如下介绍：59.binder组件为一个很方便的连接中间件，屏蔽mq具体实现产品之间的差异；60.channel组件，该部分为通道，是队列queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过channe对队列进行配置；61.source和sink简单的可将其理解为参照对象，是springcloudstream自身，从stream发布消息就是输出，接受消息就是输入。62.通过对设计模式的封装，使项目中的代码更加规范，符合了如下七大原则:63.单一职责原则:64.对类来说的，即一个类应该只负责一项职责；65.接口隔离原则，即：interfacesegregationprinciple66.所谓的接口隔离原则，即：客户端不应该依赖他不需要的接口，即一个类对另外一个类的依赖应该建立在最小的接口上；67.依赖倒转原则:68.依赖倒转原则dependenceinversionprinciple是指：69.高层模块不应该依赖底层模块，二者都应该依赖其抽象；70.抽象不应该依赖细节，细节应该依赖抽象；71.依赖倒转(倒置)的中心思想是面向接口编程；72.依赖倒转原则是基于这样的设计理念：相对于细节的多边形，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类；73.使用接口或抽象类的目的是制定好规范，而不设计任何具体的操作，把展现细节的任务交给他们的实现类去完成；74.这里也体现出了一点，接口和抽象类的价值在于设计，而在使用设计模式的时候，其接口和抽象类就会起到很重要的作用。75.里式替换原则:76.如果有一个类型为t1的对象o1，都有类型为t2的对象o2，使得以t1定义的所有程序p在所有的对象o1都代换成o2时，程序p的行为没有发生变化，那么类型t2是类型t1的子类型。换句话说，所有引用基类的地方必须能够透明的使用其子类的对象；77.在使用继承的时候，遵循里氏替换原则，在子类中尽量不要去重写父类的方法；78.里氏替换原则，继承实际上是让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。79.开闭原则:80.开闭原则，即openclosedprinciple，是编程中最基础、最重要的设计原则；前面所提到的所有原则，都是为了开闭原则做准备的；开闭原则可以总结为以下几点:81.一个软件实体，如类、模块、函数，应该对拓展开放(针对提供方)，对修改关闭(针对使用方)。即，拓展的时候，不对已经在使用的代码进行改动；也就是说，当拓展功能的时候，尽量不要去修改代码，而是新增代码；因为你正在修改的代码，有可能是别的地方正在使用的代码，这样就会造成意想不到的bug；但是对于新增的类或者方法来说，因为是新增的，所以一般不会对原有的功能造成破坏；用抽象构建框架，用实现拓展细节；82.当软件需要变化时，尽量通过拓展软件实体的行为来实现变化，而不是通过修改已有的代码来实现；83.在编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则；开闭原则其实就是编程思想的核心。84.迪米特法则:85.迪米特法则，可以简单归纳为以下几点：86.一个对象应该对其他对象保持最少的了解；87.类与类关系越密切，耦合度越大；88.迪米特法则(demeterprinciple)又叫做最少知道原则，即一个对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息；89.迪米特法则还有个更简单的定义：只与直接的朋友通讯；90.每个对象都会与其他对象产生耦合关系，只要两个对象之间有耦合关系，就说这两个对象之间是朋友关系。耦合的方式很多，如依赖、关联、组合、聚合等。其中，称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。91.合成复用原则:92.合成复用原则指的是尽量使用合成、聚合的方式，而不是使用继承；93.在本应用中主要使用到了如下设计模式：94.工厂设计模式：95.该模式将将实例化对象的代码抽取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦，从而提高项目的拓展和维护性；工厂模式常用的有简单工厂模式、抽象工厂模式和工厂方法模式。96.单例设计模式：97.该模式采取一定的方法保证在整个的软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法，该方法一般为静态方法；98.如hibernate中的sessionfactory，他充当数据存储源的代理，并负责创建session对象，sessionfactory并不是轻量级的，一般情况下，一个项目通常只需要创建一个sessionfactory就够用了，这时就会使用到单例设计模式；99.在本应用中，将需要频繁的进行创建和销毁的对象，创建对象耗时过多或消耗资源过多，即重量级对象，但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象，如数据源、session工厂等对象都以单例模式进行实现。100.策略设计模式：101.策略模式的关键是：分析项目中变化部分与不变部分；102.策略模式的核心思想是：多用组合/聚合，少用继承；用行为类组合，而不是行为的继承，这样的设计使代码更有弹性；103.体现了“对修改关闭，对扩展开放”原则，客户端增加行为不用修改原有代码，只要添加一种策略(或者行为)即可，避免了使用多重转移语句(if..elseif..else)；104.该模式提供了可以替换继承关系的办法：策略模式将算法封装在独立的strategy类中使得你可以独立于其context改变它，使它易于切换、易于理解、易于扩展；105.需要注意的是：每添加一个策略就要增加一个类，当策略过多是会导致类数目庞大。106.享元模式:107.因系统中有大量对象，这些对象消耗大量内存，并且对象的状态大部分可以外部化，在此选用享元模式来对其进行实现；108.用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象，用hashmap/hashtable存储；109.享元模式大大减少了对象的创建，降低了程序内存的占用，提高效率；但享元模式提高了系统的复杂度，需要分离出内部状态和外部状态，而外部状态具有固化特性，不应该随着内部状态的改变而改变，这是使用享元模式需要注意的地方；110.使用享元模式时，注意划分内部状态和外部状态，并且需要有一个工厂类加以控制；111.享元模式经典的应用场景是需要缓冲池的场景，比如string常量池、数据库连接池。112.模板方法设计模式：113.该模式的基本思想是，算法只存在于一个地方，也就是在父类中，容易修改。需要修改算法时，只要修改父类的模板方法或者已经实现的某些步骤，子类就会继承这些修改；114.这种设计模式实现了最大化代码复用，父类的模板方法和已实现的某些步骤会被子类继承而直接使用，既统一了算法，也提供了很大的灵活性。父类的模板方法确保了算法的结构保持不变，同时由子类提供部分步骤的实现；115.该模式的不足之处是每一个不同的实现都需要一个子类实现，导致类的个数增加，使得系统更加庞大；116.一般模板方法都加上final关键字，防止子类重写模板方法；117.模板方法模式使用场景与数据入库是相吻合的，即当要完成在某个过程，该过程要执行一系列步骤，这一系列的步骤基本相同，但其个别步骤在实现时可能不同，通常考虑用模板方法模式来处理。118.代理模式：119.该模式为一个对象提供一个替身，以控制对这个对象的访问，即通过代理对象访问目标对象，这样做的好处是:可以在目标对象实现的基础上,增强额外的功能操作,即扩展目标对象的功能。120.被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象。121.代理模式有不同的形式,主要有三种:静态代理、动态代理(动态代理又称之为jdk代理、或接口代理)和cglib代理(可以在内存动态的创建对象，而不需要实现接口，他是属于动态代理的范畴)。122.如图3所示：每天采购、预测、回传、收资产生的各场站测风塔、光辐照仪、预测功率数据、预测气象数据、实际功率数据、光伏实际功率数据、超短期预测功率数据、风机状态数据、生产记录数据、上报记录数据，将会被记录在待入库数据表中，该表记录上述文件的基本信息，包括文件名称、原始文件存放目录等。123.任务调度服务，定期调用执行任务，通过读取待入库信息表中的记录信息，获取文件基本信息，根据文件基本信息对文件进行验证，验证失败的将相应的错误信息保存到入库失败信息记录表；验证成功的将对其进行解析，解析成功后将数据入库，入库成功后，将待入库信息转存到入库成功信息记录表；解析失败的将相应的错误信息保存到入库失败信息记录表。124.如图4所示：应用由两个独立部署的工程构成，一部分是任务调度应用平台，另一部分是数据服务平台；任务调度平台以高可用集群形式部署，所有任务信息在每个节点上以全量方式保存在一个列表中，对外只有master对外提供服务，当master主机出现故障时，通过选举机制，从其他的slave中选出新的master继续对外提供服务；以此消除服务的单点故障，保证服务的高可用。125.数据服务平台对外服务，通过nacos实现负载均衡，大数据入库服务通过自研算法实现组内高可用和组外负载均衡；组内节点在主机正常的情况下，由主机提供服务，当主机出现问题时，由从机接管；每组服务通过服务标识加载相应的数据，所有数据均摊在每个组中，实现组外负载均衡。126.尽管已经示出和描述了本发明实施的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。127.需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。128.下面将结合本发明中的附图，对本发明中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
