CN111768322A - 慈善服务平台系统 - Google Patents

Abstract

本申请提供了一种慈善服务平台系统，其中，该系统包括：前端服务层，用于接收多个不同界面产生的访问请求；其中，不同界面对应的用户群体不同；业务层，用于根据访问请求所请求的内容，通过分布式服务调度对应的微服务模块；其中，所述微服务模块用于提供各类慈善相关功能；其中，由不同界面生成的针对相同功能的访问请求，所调用的微服务模块相同；数据存储层，用于实时存储所述前端服务层和所述业务层产生的数据。在本申请实施例中，不同界面可以共用微服务模块，从而提高了数据处理的效率，降低了平台构建的复杂度。采用分布式微服务框架可以提供高效的数据融合服务，并且各个服务之间可以互相彼此独立地进行调整，以满足新的服务需求。

Description

慈善服务平台系统

技术领域

本申请涉及大数据处理技术领域，特别涉及一种慈善服务平台系统。

背景技术

目前慈善组织通常是亲自上门、电话、互联网以及邮件宣传等方式寻求个人和商家的支持，获得各种形式的募捐。当前慈善组织的信息化建设并不完善，包括志愿者招募、物资募捐等在内的一些业务活动均需要线下进行，耗时长，流程较为繁琐。并且由于现有技术采用线下募捐的方式，因此，导致募捐得到的物资信息公开透明程度较差，从而使得慈善组织缺乏公信力。并且会导致慈善组织缺乏捐款来源，受捐形式单一，捐赠活动、志愿者活动等缺乏持久性。由此可见，采用现有技术中的技术方案无法高效的对多个业务活动进行线上的整合，以使用户可以便捷地参与慈善活动。

针对上述问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种慈善服务平台系统，以解决现有技术中无法高效的对多个业务活动进行线上的整合，以使用户可以便捷地参与慈善活动的问题。

本申请实施例提供了一种慈善服务平台系统，包括：前端服务层，用于接收多个不同界面产生的访问请求；其中，不同界面对应的用户群体不同；业务层，用于根据访问请求所请求的内容，通过分布式服务调度对应的微服务模块；其中，所述微服务模块用于提供各类慈善相关功能；其中，由不同界面生成的针对相同功能的访问请求，所调用的微服务模块相同；数据存储层，用于实时存储所述前端服务层和所述业务层产生的数据。

在一个实施例中，所述业务层包括：平台服务层和应用服务层，其中，所述平台服务层，用于利用渠道管理模块确定所述访问请求发出的渠道和所述访问请求所请求的内容，并根据所述访问请求发出的渠道和所述访问请求所请求的内容，通过分布式服务调度平台服务层和/或应用服务层中对应的微服务模块。

在一个实施例中，所述前端服务层和所述应用服务层采用软件即服务技术部署；所述平台服务层采用平台即服务技术部署。

在一个实施例中，所述数据存储层采用设施即服务技术部署。

在一个实施例中，所述微服务模块包括：捐赠模块、基金管理模块、志愿者管理模块和活动管理模块；其中，所述捐赠模块，用于实时记录用户在所述慈善服务平台中捐赠的物资；所述基金管理模块，用于利用区块链技术对基金进行管理，以实时公示所述慈善服务平台中捐赠物资的流向明细；所述志愿者管理模块，用于接收所述用户提交的志愿者请求和第三方发布的志愿者招募信息，根据所述志愿者请求确定所述用户的用户画像，根据所述用户画像将所述用户与志愿者招募信息进行匹配；活动管理模块，用于对所述慈善服务平台上发布的各类项目、活动进行全生命周期的管理，以实时评估、监控所述各类项目、活动的过程。

在一个实施例中，所述微服务模块还包括：定制服务模块，用于根据所述用户的定制化请求确定所述用户的用户画像，根据所述用户的用户画像为所述用户提供定制化服务。

在一个实施例中，所述微服务模块还包括：大数据分析模块，用于调用所述数据存储层中的数据分析所述用户的行为特征，根据所述行为特征确定向所述用户推送的信息。

在一个实施例中，业务层和所述数据存储层利用区块链技术进行数据处理和存储。

在一个实施例中，所述业务层提供有负载均衡机制。

在一个实施例中，所述业务层提供有Nginx反向代理服务。

本申请实施例提供了一种慈善服务平台系统，可以通过采用前端服务层、业务层和数据存储层的三层结构构建慈善服务平台系统。其中，前端服务层可以用于接收多个不同界面产生的访问请求，其中，不同界面对应的用户群体不同，从而使得不同的用户群体可以通过不同的界面访问慈善项目、活动等，实现公益筹款筹物统一受理。业务层可以用于访问请求所请求的内容，通过分布式服务调度对应的微服务模块，其中，所述微服务模块用于提供各类慈善相关功能。采用分布式微服务框架可以提供高效的数据融合服务，并且各个服务之间可以互相彼此独立地进行调整，以满足新的服务需求，进而可以满足高速发展需要的高性能、高可靠性和高可扩展性。其中，由不同界面生成的针对相同功能的访问请求，所调用的微服务模块相同，从而不同界面可以共用微服务模块，提高了数据处理的效率，降低了平台构建的复杂度。上述数据存储层可以用于实时存储前端服务层和业务层产生的数据，从而可以保证数据的实时性和可追溯性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，并不构成对本申请的限定。在附图中：

图1是根据本申请实施例提供的慈善服务平台系统的结构示意图；

图2是根据本申请具体实施例提供的慈善服务平台系统的示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本申请的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本申请，而并非以任何方式限制本申请的范围。相反，提供这些实施方式是为了使本申请公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域的技术人员知道，本申请的实施方式可以实现为一种系统、装置设备、方法或计算机程序产品。因此，本申请公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

请参阅图1，本实施方式可以提供一种慈善服务平台系统。该慈善服务平台系统可以用于利用云计算技术和分布式服务框架构建得到慈善服务平台，以使用户可以便捷的使用平台中集合的各个功能。上述慈善服务平台系统可以包括：前端服务层100、业务层200和数据存储层300。

上述前端服务层100，可以接收多个不同界面产生的访问请求；其中，不同界面对应的用户群体不同。

上述业务层200，可以用于根据访问请求所请求的内容，通过分布式服务调度对应的微服务模块；其中，所述微服务模块用于提供各类慈善相关功能；其中，由不同界面生成的针对相同功能的访问请求，所调用的微服务模块相同。

上述数据存储层300，可以用于实时存储所述前端服务层和所述业务层产生的数据。

在本实施方式中，用户可以为上述慈善服务平台的使用者，上述用户群体可以包括：公益用户、慈善机构管理员、业务人员、平台运营人员。进一步的，上述慈善服务平台的整体业务流程的参与者还可以细分为六类用户群体，包括：慈善机构管理员、捐赠者、项目受益人、志愿者、业务人员、平台运营人员。

在本实施方式中，慈善服务平台可以为不同的用户群体提供不同的展示界面，例如：可以向慈善组织、志愿者、受益人等提供门户网站标准版界面，界面中可以包含核心业务、新闻动态、组织概况、个人中心、关于我们、政务公开等功能模块，主要体现慈善组织核心业务、品牌影响力传播；可以向网站内容运营人员、网站运行维护人员提供门户网站管理定制界面，界面中可以包含门户功能导航管理、新闻动态管理发布、报送监管、门户首页管理、祈福社交策划、政务公开管理发布、定制功能管理维护、个人中心管理等功能模块，根据客户业务定制客户想要的业务。当然可以理解的是，还可以按照其它方式为不同的用户群体提供定制化的界面，具体的可以根据实际情况确定，本申请对此不作限定。

在本实施方式中，上述前端服务层可以是由至少一个前端服务器组成的，该前端服务器可以与多个终端设备相连。上述前端服务器可以为单一的服务器，也可以是服务器集群，当然，服务器的功能也可以是通过云计算技术实现的。业务层200可以是由至少一个服务器组成的，可以为单一的服务器，也可以是服务器集群，当然，服务器的功能也可以是通过云计算技术实现的。上述数据存储层300可以是具备一个强大的银行信息集库的服务器或者服务器集群。

在本实施方式中，用户可以利用终端设备或者可以是能运行于上述终端设备中的软件等多种渠道发出访问慈善服务平台的请求。上述终端设备可以包括：智能手机、平板电脑、笔记本电脑、台式计算机、智能手表或者其它可穿戴设备等终端设备，也可以是机器人设备等。上述能运行于上述终端设备中的软件可以包括：银行系统应用、支付应用、浏览器、微信小程序、公众号等应用软件。

上述访问请求可以为登录慈善服务平台的请求或者访问慈善服务平台中某一服务或者功能的请求，上述登录慈善服务平台的请求中可以包括：用户的IP地址、用户发出请求的渠道、用户发出请求的时间、用户的账户号、用户的账户密码等。上述访问慈善服务平台中某一服务或者功能的请求中可以包括：用户的IP地址、用户发出请求的渠道、用户的账户号、用户请求访问的内容、用户发出请求的时间等。

在本实施方式中，用户每次登录上述慈善服务平台的相关信息以及登录上述慈善服务平台后的浏览足迹等都会实时地存入数据存储层300中，以备后续查询浏览、大数据分析时有所依据。

在本实施方式中，上述业务层200可以用于接收并响应多个不同界面产生的访问请求，上述业务层200与前端服务层100之间可以通过互联网进行通信连接。虽然各个访问请求的来源界面可能会存在差异，但是不同界面生成的针对相同功能的访问情况所调用的微服务模块可以是相同的，即业务层200中的微服务模块是共享的，不需要根据不同的界面进行设置，从而有效提高了效率。

在一个实施方式中，由于不同界面对应的请求来源渠道可能会存在差异，即不同用户可以是通过多种不同的渠道访问慈善服务平台的，不同渠道的接入会存在一些差别，例如：用户通过微信公众号登录平台时需要进行扫码验证。并且在一些情况下不同的渠道对应的向用户展示的页面也是不同的，例如：在PC端与在微信小程序中展示页面的尺寸是不一样的，对应的页面排版、展示方向必然会存在差异。

因此，可以对通过不同渠道发出请求分别进行管理，即业务层200在接收访问请求时，可以先通过业务层200中的渠道管理模块确定用户发出上述请求的渠道。在确定用户发出请求的渠道后可以根据用户发出请求的渠道和所请求的内容，通过Spring Cloud分布式服务调度对应的微服务模块，从而可以向用户展示用户使用的渠道所对应的页面，使用户便捷地访问对应页面中的功能或者服务。其中，业务层200中可以包含多个微服务模块，每个微服务模块可以对应平台中的一种慈善相关的功能，每个微服务模块之间是相对独立的。

在本实施方式中，上述Spring Cloud是致力于分布式系统、云服务的微服务框架，相比Dubbo等RPC框架，上述Spring Cloud可以全套的分布式系统解决方案。其中，微服务框架的风格就像是把小的服务开发成单一应用的形式，使其运行在其自己的进程中，并采用轻量级的机制进行通信(一般是HTTP资源API)。这些服务都是围绕业务能力来构建，通过全自动部署工具来实现独立部署。这些服务，其可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。

在本实施方式中，上述数据存储层300可以用于实时存储前端服务层100和业务层200产生的数据。在一些实施例中，上述业务层200也可以根据业务需求从数据存储层300中调用所需的数据。上述数据存储层中可以包括：云服务器、数据库、云磁盘、内容分发模块、对象存储模块等，从而可以实现数据的实时存储和分发。

上述数据存储层可以是利用公有云和私用云构建的，其中，公有云(PublicCloud)是指第三方提供商用户能够使使用的云，公有云可以通过Internet使用。此外，由于为了兼顾行业(如金融、保险行业)和客户私隐，不可能将重要数据存放到公共网络上，因此，对于一些私密数据需要采用私有云。上述私有云(Private Clouds)可以是为一个用户单独使用而构建的，可以提供对数据、安全性和服务质量的最有效控制。其中，公有云和私有云之间可以通过外联适配器相连以交换信息。

在一个实施方式中，上述微服务模块可以包括：渠道管理模块、捐赠模块、基金管理模块、志愿者管理模块等。当然可以理解的是，还可以根据实际情况设置更多的模块，具体的本申请对此不作限定。

在一个实施方式中，上述捐赠模块可以用于实时记录用户在慈善服务平台中捐赠的物资，上述捐献的物资可以包括：捐款资金、捐献的物品(血液、器官、生活用品等)。上述捐赠模块中还可以实时展示用户在慈善服务平台中捐献的物品的物流信息，以及对应的仓储管理情况。

在本实施方式中，上述基金管理模块可以用于利用区块链技术对基金进行管理，以实时公示慈善服务平台中捐赠物资的流向明细，从而可以保证整个募捐流程的实时性和透明性。其中，上述区块链技术(Blockchain technology，BT)是利用块链式数据结构来验证与存储数据、利用分布式节点共识算法来生成和更新数据、利用密码学的方式保证数据传输和访问的安全、利用由自动化脚本代码组成的智能合约来编程和操作数据的一种全新的分布式基础架构与计算范式，用区块链技术所串接的分布式账本能让两方有效纪录交易，且可永久查验此交易。区块链技术可以通过全网共同验证交易、维护数据库的方式实现去中心化的目的，从而解决现实场景中的信任问题。

在本实施方式中，上述志愿者管理模块可以用于接收所述用户提交的志愿者请求和第三方发布的志愿者招募信息，根据所述志愿者请求确定所述用户的用户画像，根据所述用户画像将所述用户与志愿者招募信息进行匹配。进一步的，还可以将匹配结果反馈给用户和第三方，上述匹配结果可以用于表征用户画像是否符合第三方对志愿者的要求，上述第三方可以为慈善机构管理员或者公益活动的发起方等。

上述志愿者请求中可以包括用户的基本信息和请求参与的志愿者活动信息等，上述用户的基本信息可以包括：身份证号码、电话号码、用户姓名、历史参加的志愿者活动、职业、居住地等。用户画像一种勾画目标用户、联系用户诉求的有效工具，可以将用户的每个具体信息抽象成标签，利用这些标签将用户形象具体化，从而为用户提供有针对性的服务。

在本实施方式中，为了确保慈善服务平台中各类项目、活动的可延续性和可追溯性，上述活动管理模块可以用于对慈善服务平台上发布的各类项目、活动进行全生命周期的管理，以实时评估、监控所述各类项目、活动的过程，从而可以对各类项目、活动的内容进行评估和监控，以确保各类项目、活动的品质。

从以上的描述中，可以看出，本申请实施例实现了如下技术效果：可以通过采用前端服务层、业务层和数据存储层的三层结构构建慈善服务平台系统。其中，前端服务层可以用于接收用户通过多种渠道发出的访问所述慈善服务平台的请求，从而使得用户可以通过多渠道利用平台访问项目、活动等，实现公益筹款筹物统一受理。业务层可以用于根据所述用户发出所述请求的渠道和所述请求的内容，通过Spring Cloud分布式服务调度对应的微服务模块，采用云计算技术和分布式微服务框架可以提供高效的数据融合服务，并且各个服务之间可以互相彼此独立地进行调整，以满足新的服务需求，进而可以满足高速发展需要的高性能、高可靠性和高可扩展性。上述数据存储层可以用于实时存储前端服务层和业务层产生的数据，从而可以保证数据的实时性和可追溯性。

在一个实施方式中，上述微服务模块还可以包括定制服务模块，可以用户根据用户的定制化请求确定上述用户的用户画像，并根据用户的用户画像为用户提供定制化的服务。上述定制化请求中可以包括：身份证号码、电话号码、用户姓名、用户账户号、期望定制的业务、定制诉求等。上述定制服务可以包括：产品配置，可以提供功能定制，例如：公开募捐、活动公布；可以提供流程定制，例：如项目审批流程、内部日常管理；可以提供个性化页面定制，例如：红十字会门户、基金会公众号首页等。当然在一些实施例中还可以提供其它的定制化服务，具体的可以根据实际情况确定，本申请对此不作限定。

在一个实施例中，为了向用户提供更加人性化的服务，上述微服务模块还可以包括大数据分析模块。上述大数据分析模块可以调用上述数据存储层300中的与上述用户相关的历史数据，并根据与用户相关的历史数据分析上述用户的行为特征，进一步的，可以根据用户的行为特征确定向用户推送的信息。上述用户的行为特征可以用于表征用户的行为偏好，具体的可以包括：用户经常访问的页面、用户最近一次参加的活动或者项目、用户捐款的频率、用户是否参加过志愿者活动等。上述向用户推送的信息可以为慈善服务平台上正在招募志愿者的活动、需要进行捐献的活动等，具体的可以根据实际情况确定，本申请对此不作限定。

在一个实施方式中，上述业务层可以包括：平台服务层和应用服务层，上述平台服务层主要提供微服务，应用服务层主要提供功能性管理。上述平台服务层可以用于利用渠道管理模块确定所述访问请求发出的渠道和所述访问请求所请求的内容，并根据所述访问请求发出的渠道和所述访问请求所请求的内容，通过分布式服务调度平台服务层和/或应用服务层中对应的微服务模块。

在本实施方式中，上述慈善服务平台可以采用至少包括：IaaS(设施即服务，Infrastructure-as-a-service)、PaaS(平台即服务，Platform-as-a-service)、SaaS(软件即服务，Software-as-a-service)等方式进行部署以提供云计算服务。其中，前端服务层和应用服务层采用软件即服务技术部署，平台服务层采用平台即服务技术部署，数据存储层采用设施即服务技术部署。采用上述部署方式，平台的各参与方无须另行购买物理设备，采用驱动即可整合公益行业客户需求。

在本实施方式中，SaaS是一种软件交付方式，常见的形式是提供Web端应用，也就是开发好的应用软件。用户不需要考虑任何软件开发、部署，也不用担心服务器硬件、带宽，直接购买即可使用，有效减少了本地部署需要的大量前期投入，大大提高了平台优化推广的效率。上述SaaS可以包括以下特性：互联网特性：捐赠人可以通过互联网方式使用慈善组织定制的服务，平台管理员可以通过浏览器实现运营管理。使得平台具备快速实施、便捷交付的特点；多重租赁特性：平台集成了慈善组织常用核心功能模块，不同组织之间的数据、前端页面、配置等要素相互隔离，保证数据的安全与隐私，也满足不同客户在界面、业务逻辑、数据结构等的个性化需求；服务特性：SAAS部署的平台以互联网为载体的服务形式被客户使用，慈善组织可以按需定制服务，有效减少了不必要的资源开销；可拓展性特性：基于分布式应用架构的平台，在高并发的情况下可实现资源扩展，如存储、带宽、数据库连接、计算资源等。

PaaS提供软件部署平台，开发者只需要关注自己的业务逻辑，不需要关注底层。常见的表现形式是提供托管的应用引擎(App Engine)。PaaS层可以被理解为在IaaS层提供的硬件服务之上，还额外搭建好了服务器环境、中间件、数据库等。开发者用户只需要将代码上传部署，网站就可以运行起来了，既降低了IT运维成本，还省去了大量的开发与运维工作量。PaaS平台目标的产品包括谷歌的App Engine、百度的Baidu App Engine(BAE)、新浪的Sina App Engine(SAE)等。

IaaS是云服务的最底层，主要提供一些基础资源，常见形式是硬件服务器租用。IaaS与PaaS的区别是，用户需要自己控制底层，实现基础设施的使用逻辑。提供IaaS的服务商会提供场外服务器、虚拟化、存储和网络硬件供用户租用，为用户节省维护成本和办公场地，用户可以在任何时候利用这些硬件来运行其应用。IaaS产品包括亚马逊的AWS云服务、微软的Microsoft Azure、阿里巴巴的阿里云、腾讯的腾讯云等。

在一个实施方式中，为了保证全业务流程的实时、透明、公信，业务层200和数据存储层300可以利用区块链技术进行数据处理和存储。从而使得在慈善服务平台中，慈善组织可以对财务支出明细实时公示，并对慈善干系人之间的交易往来实时监管，并生成监管报表。捐献环节中的任意参与方可通过慈善服务平台选择某一笔或某一批捐赠款，查看资金流通全流程所有关键信息。当资金通过慈善机构拨付给项目受益人后，该资金信息即为已拨付状态；当资金被项目受益人使用后，该资金信息即为已使用状态，即用户可查询资金的具体用途。

在一个实施方式中，为了提供平台的数据处理能力，上述业务层200可以提供有负载均衡机制。负载均衡(Load Balance)是建立在现有网络结构之上，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。采用负载均衡机制可以将平台中大量的并发访问或数据流量分担到多台节点设备上分别处理，以减少用户等待响应的时间；或者，将单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后将结果汇总，并返回给用户，以使系统处理能力得到大幅度提高。在一个实施例中，可以通过HAProxy进行负载均衡操作。

在一个实施方式中，为了确保用户每次访问，服务器集群中的每个服务器压力趋于平衡，以避免了服务器崩溃的情况，上述业务层200可以提供有Nginx反向代理服务。其中。反向代理和正向代理的区别就是：正向代理代理客户端，反向代理代理服务器。Nginx反向代理服务会给用户分配服务器压力小的去访问，具体的用户访问网站的时候首先会访问Nginx服务器，然后Nginx服务器再从服务器集群中选择压力较小的服务器，将该访问请求引向该服务器。

在一个具体实施例中，上述慈善服务平台系统可以如图2中所示，可以包括：慈善云服务平台、区块链服务平台以及提供第三方支付服务的线上捐赠模块。其中，P1为客户渠道；P2为员工渠道；STM为智慧柜员机；P4为服务注册中心；ESB为企业消息总线；P1SVC为客户渠道服务；P3为用户服务；P5为外联前置；P6-P8为客户信息组件，新一代开放平台；P9为数据中心；P10-P12为企业报表；EDA为消息订阅。

在本实施例中，上述慈善云服务平台、区块链服务平台是基于公有云建立的，上述线上捐赠模块是基于私有云建立的，用于进行线上捐赠渠道管理(包含网银、手机银行、微信、支付宝、银联、龙支付等)，公有云和私有云之间通过外联适配器进行数据交互。上述线上捐赠模块可以提供多渠道的第三方支付服务、支付结算、收单、记录客户信息、代理理财、现金管理、代收代付、客户回馈、贵金属等微服务模块，此外还可以提供隐私数据(用户账户信息等)的存储服务。

在本实施例中，慈善干系人可以通过前端服务层利用PC/小程序/公众号互动交流，进行公益金融产业链合作，提出场景化的业务需求。慈善云服务平台整合公益行业的客户需求，在应用服务层进行相应部署实现社交管理、捐赠中心、人员管理、活动管理、门户网站标准/定制，红十字会三献一捐等功能，例如：志愿者招募、慈善组织登录终端、发布活动、志愿者通过手机或者网站登录查找活动、填写信息、申请志愿者活动。慈善组织收到申请后进行信息审核，通过志愿者图像可以精准招募，并且实现线上流程化。在区块链服务平台中，利用区块链对数据进行实时存储和处理，以使慈善组织对财务支出明细公开，干系人之间交易往来实时监管，并生成监管报表。捐赠者或环节中的任意参与方，可通过慈善组织服务平台，选择某一笔或某一批捐赠款，查看资金流通全流程所有关键信息；慈善机构需对资金流向进行实时公示。当资金通过慈善机构拨付给项目受益人后，该资金信息即为已拨付状态；当资金被项目受益人使用后，该资金信息即为已使用状态，并可查询资金的具体用途。

在本实施例中，可以利用平台的公益管理、智能服务、高效统计、数据分析、集中运营等特性通过门户、微信公众号等对外服务渠道为政府(G端)有效监管提供及时准确完整全面的数据，协助组织(B端)高效地整合相关各方资源，有利于用户(C端)将资源分配到正确的地方。

在本实施例中，慈善云服务平台可以将认证后的慈善机构信息、认证后的项目信息、项目受益人信息、捐款者的捐款信息、慈善机构对资金的使用信息、善款的拨付信息、受益人对善款的使用信息等在信息监管模块中进行公示，保证全业务流程的透明、公信。慈善云服务平台还可以提供捐赠公示、项目管理、信息公开、线上求助、三献管理(无偿献血、捐献造血干细胞、捐献遗体(角膜)器官)、定制化服务、志愿者管理、三救管理、知识学堂、定制化服务等功能。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

虽然本申请提供了如上述实施例或流程图所述的结构，但基于常规或者无需创造性的劳动在所述结构中可以包括更多或者更少的对象。应该理解，以上描述是为了进行图示说明而不是为了进行限制。通过阅读上述描述，在所提供的示例之外的许多实施方式和许多应用对本领域技术人员来说都将是显而易见的。因此，本申请的范围不应该参照上述描述来确定，而是应该参照前述权利要求以及这些权利要求所拥有的等价物的全部范围来确定。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请实施例可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种慈善服务平台系统，其特征在于，包括：

前端服务层，用于接收多个不同界面产生的访问请求；其中，不同界面对应的用户群体不同；

业务层，用于根据访问请求所请求的内容，通过分布式服务调度对应的微服务模块；其中，所述微服务模块用于提供各类慈善相关功能；其中，由不同界面生成的针对相同功能的访问请求，所调用的微服务模块相同；

数据存储层，用于实时存储所述前端服务层和所述业务层产生的数据。

2.根据权利要求1所述的系统，其特征在于，所述业务层包括：平台服务层和应用服务层，其中，所述平台服务层，用于利用渠道管理模块确定所述访问请求发出的渠道和所述访问请求所请求的内容，并根据所述访问请求发出的渠道和所述访问请求所请求的内容，通过分布式服务调度平台服务层和/或应用服务层中对应的微服务模块。

3.根据权利要求2所述的系统，其特征在于，所述前端服务层和所述应用服务层采用软件即服务技术部署；所述平台服务层采用平台即服务技术部署。

4.根据权利要求1所述的系统，其特征在于，所述数据存储层采用设施即服务技术部署。

5.根据权利要求1所述的系统，其特征在于，所述微服务模块包括：捐赠模块、基金管理模块、志愿者管理模块和活动管理模块；其中，

所述捐赠模块，用于实时记录用户在所述慈善服务平台中捐赠的物资；

所述基金管理模块，用于利用区块链技术对基金进行管理，以实时公示所述慈善服务平台中捐赠物资的流向明细；

所述志愿者管理模块，用于接收所述用户提交的志愿者请求和第三方发布的志愿者招募信息，根据所述志愿者请求确定所述用户的用户画像，根据所述用户画像将所述用户与志愿者招募信息进行匹配；

活动管理模块，用于对所述慈善服务平台上发布的各类项目、活动进行全生命周期的管理，以实时评估、监控所述各类项目、活动的过程。

6.根据权利要求1所述的系统，其特征在于，所述微服务模块还包括：定制服务模块，用于根据所述用户的定制化请求确定所述用户的用户画像，根据所述用户的用户画像为所述用户提供定制化服务。

7.根据权利要求1所述的系统，其特征在于，所述微服务模块还包括：大数据分析模块，用于调用所述数据存储层中的数据分析所述用户的行为特征，根据所述行为特征确定向所述用户推送的信息。

8.根据权利要求1所述的系统，其特征在于，业务层和所述数据存储层利用区块链技术进行数据处理和存储。

9.根据权利要求1所述的系统，其特征在于，所述业务层提供有负载均衡机制。

10.根据权利要求1所述的系统，其特征在于，所述业务层提供有Nginx反向代理服务。

Images