CN111159133A - 一种基于微服务的分布式论坛系统 - Google Patents

Abstract

本发明涉及一种基于微服务的分布式论坛系统。该系统包括分布式存储子系统和分布式搜索引擎子系统；分布式存储子系统包括跟踪服务器和存储服务器；跟踪服务器管理和调度所有的存储服务器，存储服务器采用分组的组织形式，每个组内含有若干存储服务器；客户端向跟踪服务器请求进行文件上传、下载，通过跟踪服务器调度最终由存储服务器完成文件上传和下载；分布式搜索引擎子系统采用Elasticsearch引擎进行检索。本发明运用BBS论坛技术，通过与IDICS平台集成，为平台开发者之间技术交流、资源共享、问题讨论和经验分享提供交流场所，并提供开放、专业的在线使用等服务，构建INDICS开发者论坛，促进开发者生态的形成。

Description

一种基于微服务的分布式论坛系统

技术领域

本发明属于网络技术、软件技术领域，具体涉及一种基于微服务的分布式论坛系统。

背景技术

网络论坛是一个和网络技术有关的网上交流场所。BBS(Bulletin Board System，电子公告板)最早是用来公布股市价格等类信息的，当时BBS连文件传输的功能都没有，而且只能在苹果计算机上运行。早期的BBS与一般街头和校园内的公告板性质相同，只不过是通过电脑来传播或获得消息而已。一直到个人计算机开始普及之后，有些人尝试将苹果计算机上的BBS转移到个人计算机上，BBS才开始渐渐普及开来。近些年来，由于爱好者们的努力，BBS的功能得到了很大的扩充。因为现在的网络知识流行太快，每个行业都有一个自己在网络中进行交流的一块区域，BBS论坛则是最好的地方。

国内的BBS站，按其性质划分，可以分为2种：一种是商业BBS站，如新华龙讯网；另一种是业余BBS站，如天堂资讯站。由于使用商业BBS站要交纳一笔费用，而商业站所能提供的服务与业余站相比，并没有什么优势，所以其用户数量不多。多数业余BBS站的站长，基于个人关系，每天都互相交换电子邮件，渐渐地形成了一个全国性的电子邮件网络ChinaFidoNet。于是，各地的用户都可以通过本地的业余BBS站与远在异地的网友互通信息。这种跨地域电子邮件交流正是商业站无法与业余站相抗衡的根本因素。由于业余BBS站拥有这种优势，所以使用者都更乐意加入。其BBS论坛目的是为了推动中国计算机网络的健康发展，提高广大计算机用户的应用水平，论坛更有利学习互动交流。

BBS多用于大型公司或中小型企业，开放给客户交流的平台，对于初识网络的新人来讲，BBS就是用于在网络上交流的地方，可以发表一个主题，让大家一起来探讨，也可以提出一个问题，大家一起来解决等，是一个人与人语言文化共享的平台，具有实时性、互动性。论坛的发展也如同网络，雨后春笋般的出现，并迅速的发展壮大。现在的论坛几乎涵盖了我们生活的各个方面，几乎每一个人都可以找到自己感兴趣或者需要了解的专题性论坛，而各类网站，综合性门户网站或者功能性专题网站也都青睐于开设自己的论坛，以促进网友之间的交流，增加互动性和丰富网站的内容。

综合类的论坛包含的信息比较丰富和广泛，能够吸引几乎全部的网民来到论坛，但是由于广便难于精，所以这类的论坛往往存在着弊端即不能全部做到精细和面面俱到；专题类的论坛，能够吸引真正志同道合的人一起来交流探讨，有利于信息的分类整合和搜集，但是专题性论坛往往在单独的一个领域里进行版块的划分设置，这类论坛往往对用户的局限性较高，用户种类较为单一；地方性论坛是论坛中娱乐性与互动性最强的论坛之一，不论是大型论坛中的地方站，还是专业的地方论坛，都有很热烈的网民反向，比如百度长春贴吧、北京贴吧或者是清华大学论坛、一汽公司论坛等，地方性论坛能够更大距离的拉近人与人的沟通，另外由于是地方性的论坛，所以对其中的用户也有了一定行的地域局限性，信息来源较为集中和单一；交流性的论坛重点在于论坛会员之间的交流和互动，所以内容也较丰富多样，有供求信息，交友信息，线上线下活动信息，新闻等，这样的论坛是将来论坛发展的大趋势。

INDICS(Industrial intelligent cloud system，工业智能云系统)开发者论坛主要为各类产品提供云端在线使用门户入口，并且汇聚了平台所有对外开放的技术、产品和服务，提供从接入、开发、部署到运维的全方位服务和支持，所有开发者可对使用过程中遇到的问题进行意见反馈，同时对问题快速找到解决方案，为平台开发者提供涵盖从设备接入、管理到应用开发、部署的全面工业互联网服务。重要的是，INDICS开发者论坛为INDICS平台的企业和个人开发者提供线上交流和学习的平台，通过开放的社区对外提供问题探讨、经验分享、资源共享、相互学习等服务。用户可以通过文字、图片、视频等多种形式在论坛中发布需求和分享，不仅能得到有益的教诲和启发，对于有益或具备价值的观点，能被科学合理的采纳，这也为工业互联网的发展作出了巨大的贡献。通过论坛，开发者用户得以更方便的交流和互动，更便捷的发表自己的观点，而且发布信息都是通过有记录的文字来进行，所以这样也避免了精华内容的流失。通过论坛来征得自己想要的信息，有更高的效率和时效性，也最节约成本和资源。

但在INDICS开发者论坛构建方面，目前主要存在着以下问题：

(1)数据类型多样性：来自论坛的数据种类多种多样，用户发布例如文本、视频、图片等多种类型的数据，占用存储资源较高，需要具备高可靠、高性能的大容量存储系统才能满足社区论坛用户的业务需求；

(2)用户体验：由于论坛用户来自多个工业互联网平台，所以用户的需求会较为多样化，且不同用户之间的个性化需求差异较大，需要具备功能完善的搜索引擎，在满足用户搜索需求的同时，确保用户获取数据的时效性，提升用户体验度。

发明内容

针对数据类型多样化、用户差异较大等问题，本发明主要解决的问题如下：

(1)采用分布式存储分布式文件系统来解决大容量的数据存储问题；

(2)运用实时分布式搜索和分析引擎来满足不同用户的海量个性化需求，提升论坛数据获取时效性和准确性。

本发明基于BBS论坛系统，运用微服务和分布式存储技术，从平台全局考虑业务流程与架构设计，建立基于微服务的分布式论坛，打造高品质的开发者社区平台版块，从大量的可行调度策略中选出最优策略，丰富开发者运营模式，提升开发者活跃度，辅助平台构建完整的开发者生态。

本发明采用的技术方案如下：

一种基于微服务的分布式论坛系统，包括分布式存储子系统和分布式搜索引擎子系统；

所述分布式存储子系统包括跟踪服务器和存储服务器；所述跟踪服务器负责管理和调度所有的存储服务器，所述存储服务器采用分组的组织形式，每个组内含有若干存储服务器，一个组内的若干存储服务器中的数据互为备份；客户端向跟踪服务器请求进行文件上传、下载，通过跟踪服务器调度最终由存储服务器完成文件上传和下载；

所述分布式搜索引擎子系统采用Elasticsearch实时分布式搜索和分析引擎进行检索，满足不同用户的海量个性化需求。

进一步地，每个存储服务器在启动后连接跟踪服务器，告知自己所属的组，并保持周期性心跳；跟踪服务器根据存储服务器的心跳信息，建立组与存储服务器的映射表。

进一步地，通过增加跟踪服务器扩展为跟踪服务器集群，其中每个跟踪服务器之间是完全对等的，所有的跟踪服务器都接受存储服务器的心跳信息，生成元数据信息来提供读写服务。

进一步地，将不同应用数据存到不同的组以隔离应用数据，同时根据应用的访问特性来将应用分配到不同的组来实现负载均衡。

进一步地，存储服务器中配置多个数据存储目录，存储服务器接受到写文件请求时，根据配置好的规则选择其中一个存储目录来存储文件；为了避免单个目录下的文件数太多，在存储服务器第一次启动时，在每个数据存储目录里创建2级子目录，每级256个，总共65536个文件，新写的文件以hash的方式被路由到其中某个子目录下，然后将文件数据作为本地文件存储到该目录中。

进一步地，所述分布式存储子系统的上传过程包括：

(1)选择跟踪服务器：当集群中不只一个跟踪服务器时，客户端在上传文件时任意选择一个跟踪服务器；

(2)选择存储的组：当跟踪服务器接收到上传文件的请求时，为该文件分配一个可以存储该文件的组；

(3)选择存储服务器：当选定组后，跟踪服务器会在组内选择一个存储服务器给客户端：

(4)选择storage path：当分配好存储服务器后，客户端向存储服务器发送写文件请求，存储服务器会为文件分配一个数据存储目录；

(5)生成Fileid：选定存储目录之后，存储服务器为文件生成一个Fileid；

(6)选择两级目录：每个存储目录下有两级256*256的子目录，存储服务器会按文件Fileid进行两次hash匹配，路由到其中一个子目录，然后将文件以Fileid为文件名存储到该子目录下；

(7)生成文件名：当文件存储到某个子目录后，即认为该文件存储成功，为该文件生成一个文件名，文件名由组、存储目录、两级子目录、fileid、文件后缀名拼接而成。

进一步地，所述分布式存储子系统的文件同步过程包括：

写文件时，客户端将文件写至组内一个存储服务器即认为写文件成功，存储服务器写完文件后，由后台线程将文件同步至同组内其他的存储服务器；

每个存储服务器写文件后，同时会写一份二进制文件，其中不包含文件数据，只包含文件名等元信息，这份二进制文件用于后台同步，存储服务器会记录向组内其他存储服务器同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，并保证集群内所有存储服务器的时钟保持同步；

存储服务器的同步进度作为元数据的一部分汇报到跟踪服务器上，跟踪服务器在选择读存储服务器的时候以同步进度作为参考。

进一步地，所述分布式存储子系统的文件下载过程包括：客户端选择任意一个跟踪服务器；客户端发送下载请求给某个跟踪服务器，必须带上文件名信息，跟踪服务器从文件名中解析出文件的组、大小、创建时间，然后为该请求选择一个存储服务器用来服务读请求。

本发明的有益效果如下：

本发明的关键在于微服务、分布式存储和Elasticsearch搜索引擎技术，将论坛系统与工业互联网平台业务相结合，能够为开发者提供开放、专业的在线交流与学习平台，助力开发者生态的形成。本发明运用BBS论坛技术，通过与IDICS平台集成，为平台开发者之间技术交流、资源共享、问题讨论和经验分享提供交流场所，并提供开放、专业的在线使用等服务，构建INDICS开发者论坛，促进开发者生态的形成。

附图说明

图1是本发明的基于微服务的分布式论坛系统的工作流程图。

图2是分布式存储架构示意图。

图3是分布式存储的上传过程示意图。

图4是文件存储成功后为文件生成的文件名示意图。

图5是分布式存储的文件下载过程示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面通过具体实施例和附图，对本发明做进一步详细说明。

本发明的主要内容包括：

1)提供话题模块，完善了开发者线上交流和技术分享。

2)提供问答模块，方便开发者及时进行问题反馈和解答。

3)通过分布式存储技术，满足用户对不同多媒体介质的交流。

4)提供加精、置顶功能，方便运营者进行产品的推广和宣传。

5)提供互相评论功能，活跃用户之间沟通和交流。

6)采用elasticsearch搜索引擎技术，实现快速、精准、丰富的检索。

在本系统采用微服务的架构，每个模块就相当于一个单独的项目，这种架构使得不同的微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。有效的拆分应用，实现敏捷开发和部署。

图1为本发明的基于微服务的分布式论坛系统的工作流程图。用户通过社区系统的话题模块可以分享和学习来自不同工业互联网平台的产品教学。同时可以通过问答模块，对相关问题进行在线解疑。针对不同用户的需求，为解决大容量存储和负载均衡问题，在充分考虑冗余备份、负载均衡、线性扩容等机制及高可用、高性能等指标后，本系统选择通过分布式存储分布式文件系统提供以文本为载体的在线服务，包括视频、图片的存储及阅览。比如图1中对图片、视频采取fastdfs文件分布式存储技术，单文件大学建议范围4kb-500M。

为应对当前数据量爆炸式增长的挑战和优化用户体验，本系统选用Elasticsearch实时分布式搜索和分析引擎，将全文搜索、结构化搜索和分析集成到一种服务内，提供实时文件存储，每个字段都可被索引并可被搜索，满足用户个性化需求；提供实时分析搜索引擎，达到亿级数据秒级搜索，同时支持扩展到上百台服务器，处理PB级结构化或非结构化数据。为用户提供快速、稳定、可靠的搜索服务。

下面首先说明主题目录和对象中的属性，作为对整个系统的基本属性及数据结构的概述，然后再说明本发明的分布式文件存储方案。

1.主题目录

主题目录是指整个bbs系统的结构。主题必备目录有以下几个：

simple

├──comment

├──tag

├──topic

└──user

其中，simple表示简要结构，comment表示评论，tag表示标签，topic表示话题，user表示用户。上面列出来的文件夹和文件都是必备的。若习惯封装，可以跟default主题里一样，将通用的代码块封装成component，放在一个文件夹里(比如default主题里的组件文件夹就是components，此为非必须步骤)

2.对象中的属性。对象是主要指存储对象，具体属性如表1所示。属性的类型全都是String，可根据自己需要将值转成int或者boolean。

3.分布式文件存储方案。

分布式存储架构包括跟踪服务器Tracker server和存储服务器Storage server，如图2所示。客户端请求Tracker server进行文件上传、下载，通过Tracker server调度最终由Storage server完成文件上传和下载。

1)跟踪服务器Tracker Server

主要做调度工作，起到均衡的作用；负责管理所有的Storage server和group(组，一个组内含有多个Storage server)，每个Storage server在启动后会连接Trackerserver，告知自己所属group等信息，并保持周期性心跳。Tracker server根据Storageserver的心跳信息，建立group＝＝>[storage serverlist]的映射表。

Tracker server需要管理的元信息很少，会全部存储在内存中；另外Trackerserver上的元信息都是由Storage server汇报的信息生成的，本身不需要持久化任何数据，这样使得Tracker server非常容易扩展，直接增加Tracker server机器即可扩展为Tracker Server Cluster(跟踪服务器集群)来服务，cluster里每个Tracker server之间是完全对等的，所有的Tracker server都接受Storage server的心跳信息，生成元数据信息来提供读写服务。

表1.属性列表

2)存储服务器Storage Server

主要提供容量和备份服务；以group为单位，每个group内可以有多台Storageserver，数据互为备份。以group为单位组织存储能方便的进行应用隔离、负载均衡、副本数定制(group内Storage server数量即为该group的副本数)，比如将不同应用数据存到不同的group就能隔离应用数据，同时还可根据应用的访问特性来将应用分配到不同的group来做负载均衡；缺点是group的容量受单机存储容量的限制，同时当group内有机器坏掉时，数据恢复只能依赖group内地其他机器，使得恢复时间会很长。

group内每个Storage server的存储依赖于本地文件系统，Storage server可配置多个数据存储目录，比如有10块磁盘，分别挂载在/data/disk1-/data/disk10，则可将这10个目录都配置为Storage server的数据存储目录。Storage server接受到写文件请求时，会根据配置好的规则选择其中一个存储目录来存储文件。为了避免单个目录下的文件数太多，在Storage server第一次启动时，会在每个数据存储目录里创建2级子目录，每级256个，总共65536个文件，新写的文件会以hash的方式被路由到其中某个子目录下，然后将文件数据作为本地文件存储到该目录中。

3)分布式存储的存储策略

为了支持大容量，存储节点(即存储服务器Storage server)采用了分卷(或分组)的组织方式，即上文中的group。存储系统由一个或多个卷组成，卷与卷之间的文件是相互独立的，所有卷的文件容量累加就是整个存储系统中的文件容量。一个卷可以由一台或多台存储服务器Storage server组成，一个卷下的存储服务器中的文件都是相同的，卷中的多台存储服务器起到了冗余备份和负载均衡的作用。

在卷中增加存储服务器时，同步已有的文件由系统自动完成，同步完成后，系统自动将新增服务器切换到线上提供服务。当存储空间不足或即将耗尽时，可以动态添加卷。只需要增加一台或多台服务器，并将它们配置为一个新的卷，这样就扩大了存储系统的容量。

4)分布式存储的上传过程

分布式存储向使用者提供基本文件访问接口，比如upload(上传)、download(下载)、append(添加)、delete(删除)等，以客户端库的方式提供给用户使用。

Storage Server会定期的向Tracker Server发送自己的存储信息。当TrackerServer Cluster中的Tracker Server不止一个时，各个Tracker Server之间的关系是对等的，所以客户端上传时可以选择任意一个Tracker Server。

当Tracker Server收到客户端上传文件的请求时，会为该文件分配一个可以存储文件的group，当选定了group后就要决定给客户端分配group中的哪一个Storage server。当分配好Storage server后，客户端向Storage server发送写文件请求，Storage server将会为文件分配一个数据存储目录。然后为文件分配一个Fileid，最后根据以上的信息生成文件名存储文件。

分布式存储的上传过程如图3所示，包括以下步骤：

(1)选择Tracker Server

当集群中不止一个Tracker Server时，由于Tracker Server之间是完全对等的关系，客户端在上传文件时可以任意选择一个Tracker Server。

(2)选择存储的group

当Tracker Server接收到上传文件的请求时，会为该文件分配一个可以存储该文件的group，支持如下选择group的规则：1.Round robin，所有的group间轮询；2.Specifiedgroup，指定某一个确定的group；3.Load balance，剩余存储空间多的group优先。

(3)选择Storage server

当选定group后，Tracker Server会在group内选择一个Storage server给客户端，支持如下选择Storage server的规则：1.Round robin，在group内的所有Storageserver间轮询；2.First server ordered by ip，按Storage server的ip排序；3.Firstserver ordered by priority，按Storage server的优先级排序(优先级在Storageserver上配置)。

(4)选择storage path

当分配好Storage server后，客户端将向Storage server发送写文件请求，Storage server将会为文件分配一个数据存储目录，支持如下规则：1.Round robin，多个存储目录间轮询；2.剩余存储空间最多的优先。图3中file content是指文件内容，metadata是指元数据。

(5)生成Fileid

选定存储目录之后，Storage server会为文件生成一个Fileid，由Storageserver ip、文件创建时间、文件大小、文件crc32和一个随机数拼接而成，然后将这个二进制串进行base64编码，转换为可打印的字符串。

(6)选择两级目录

当选定存储目录之后，Storage server会为文件分配一个Fileid，每个存储目录下有两级256*256的子目录，Storage server会按文件Fileid进行两次hash匹配，路由到其中一个子目录，然后将文件以Fileid为文件名存储到该子目录下。

(7)生成文件名

当文件存储到某个子目录后，即认为该文件存储成功，接下来会为该文件生成一个文件名，文件名由group、存储目录、两级子目录、fileid、文件后缀名(由客户端指定，主要用于区分文件类型)拼接而成。如图4所示。

5)分布式存储的文件同步

写文件时，客户端将文件写至group内一个Storage server即认为写文件成功，Storage server写完文件后，会由后台线程将文件同步至同group内其他的Storageserver。

每个Storage server写文件后，同时会写一份binlog(二进制文件)，binlog里不包含文件数据，只包含文件名等元信息，这份binlog用于后台同步，Storage server会记录向group内其他Storage server同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，所以最好能保证集群内所有Storage server的时钟保持同步。

Storage server的同步进度会作为元数据的一部分汇报到Tracker server上，Tracker server在选择读Storage server的时候会以同步进度作为参考。

比如一个group内有A、B、C三个Storage server，A向C同步到进度为T1(T1以前写的文件都已经同步到B上了)，B向C同步到时间戳为T2(T2>T1)，Tracker server接收到这些同步进度信息时，就会进行整理，将最小的那个做为C的同步时间戳，本例中T1即为C的同步时间戳为T1(即所有T1以前写的数据都已经同步到C上了)；同理，根据上述规则，Trackerserver会为A、B生成一个同步时间戳。

6)分布式存储的文件下载

客户端上传文件成功后，会拿到一个Storage server生成的文件名，接下来客户端根据这个文件名即可访问到该文件。

分布式存储的文件下载流程如图5所示。与上传文件一样，在下载文件时客户端可以选择任意Tracker server。客户端发送下载请求给某个Tracker server，必须带上文件名信息，Tracker server从文件名中解析出文件的group、大小、创建时间等信息，然后为该请求选择一个Storage server用来服务读请求。

5.接口文档

1)获取token(令牌)

系统默认开启了cors(Cross-origin resource sharing，跨域资源共享)访问，任何源都可以访问/api/**下的资源，如果想关闭的话，可以通过修改源码的方式关闭，源码位置com.casic.bbs.config.WebMvcConfig。

有的接口请求要求带上用户的token参数，这个token是在用户注册的时候自动生成的，可以在个人设置页面重新生成。

2)请求接口示例

本系统上的接口风格已经全都换成RESTFUL(Representational StateTransfer，表述性状态转移)风格的了，调用方式也有了相应的调整：

(1)所有需要传token的接口，token参数要放在请求头里；

(2)所有需要传参数的接口，参数都以json的形式传递。

3)接口返回对象

返回对象的实体类是在程序里自定义的，共三个属性：

code:返回时的状态值，成功：200，失败：201。

description:失败时的一些描述信息放在这个属性里。

detail:一般放成功后的返回值，它是一个Object类型的属性，可以放任何对象。

4)接口返回分页对象

如果接口涉及到分页的话，就会返回Result(IPage)就是将查询后封装好的分页对象放在Result对象的detail属性里，再转成json返给前端。

IPage对象是MyBatis-Plus内置的一个分页对象，其中调用接口可能会用到的属性有如下几个：

records:查询出的列表对象；

pages:分页后的总页数；

total:总条数；

current:当前页数；

size:每页条数。

本发明未详细阐述的部分属于本领域技术人员的公知技术。

以上实施例仅用以说明本发明的技术方案而非对其进行限制，本领域的普通技术人员可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明的原理和范围，本发明的保护范围应以权利要求书所述为准。

Claims (10)

1.一种基于微服务的分布式论坛系统，其特征在于，包括分布式存储子系统和分布式搜索引擎子系统；

所述分布式存储子系统包括跟踪服务器和存储服务器；所述跟踪服务器负责管理和调度所有的存储服务器，所述存储服务器采用分组的组织形式，每个组内含有若干存储服务器，一个组内的若干存储服务器中的数据互为备份；客户端向跟踪服务器请求进行文件上传、下载，通过跟踪服务器调度最终由存储服务器完成文件上传和下载；

所述分布式搜索引擎子系统采用Elasticsearch实时分布式搜索和分析引擎进行检索，满足不同用户的海量个性化需求。

2.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，每个存储服务器在启动后连接跟踪服务器，告知自己所属的组，并保持周期性心跳；跟踪服务器根据存储服务器的心跳信息，建立组与存储服务器的映射表。

3.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，通过增加跟踪服务器扩展为跟踪服务器集群，其中每个跟踪服务器之间是完全对等的，所有的跟踪服务器都接受存储服务器的心跳信息，生成元数据信息来提供读写服务。

4.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，将不同应用数据存到不同的组以隔离应用数据，同时根据应用的访问特性来将应用分配到不同的组来实现负载均衡。

5.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，存储服务器中配置多个数据存储目录，存储服务器接受到写文件请求时，根据配置好的规则选择其中一个存储目录来存储文件；为了避免单个目录下的文件数太多，在存储服务器第一次启动时，在每个数据存储目录里创建2级子目录，每级256个，总共65536个文件，新写的文件以hash的方式被路由到其中某个子目录下，然后将文件数据作为本地文件存储到该目录中。

6.根据权利要求1或5所述的基于微服务的分布式论坛系统，其特征在于，所述分布式存储子系统的上传过程包括：

(1)选择跟踪服务器：当集群中不只一个跟踪服务器时，客户端在上传文件时任意选择一个跟踪服务器；

(2)选择存储的组：当跟踪服务器接收到上传文件的请求时，为该文件分配一个可以存储该文件的组；

(3)选择存储服务器：当选定组后，跟踪服务器会在组内选择一个存储服务器给客户端：

(4)选择storage path：当分配好存储服务器后，客户端向存储服务器发送写文件请求，存储服务器会为文件分配一个数据存储目录；

(5)生成Fileid：选定存储目录之后，存储服务器为文件生成一个Fileid；

(6)选择两级目录：每个存储目录下有两级256*256的子目录，存储服务器会按文件Fileid进行两次hash匹配，路由到其中一个子目录，然后将文件以Fileid为文件名存储到该子目录下；

(7)生成文件名：当文件存储到某个子目录后，即认为该文件存储成功，为该文件生成一个文件名，文件名由组、存储目录、两级子目录、fileid、文件后缀名拼接而成。

7.根据权利要求6所述的基于微服务的分布式论坛系统，其特征在于，选择组的规则为下列的一种：所有的组间轮询、指定某一个确定的组、剩余存储空间多的组优先；选择存储服务器的规则为下列的一种：在组内的所有存储服务器间轮询、按存储服务器的ip排序、按存储服务器的优先级排序。

8.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，所述分布式存储子系统的文件同步过程包括：

写文件时，客户端将文件写至组内一个存储服务器即认为写文件成功，存储服务器写完文件后，由后台线程将文件同步至同组内其他的存储服务器；

每个存储服务器写文件后，同时会写一份二进制文件，其中不包含文件数据，只包含文件名等元信息，这份二进制文件用于后台同步，存储服务器会记录向组内其他存储服务器同步的进度，以便重启后能接上次的进度继续同步；进度以时间戳的方式进行记录，并保证集群内所有存储服务器的时钟保持同步；

存储服务器的同步进度作为元数据的一部分汇报到跟踪服务器上，跟踪服务器在选择读存储服务器的时候以同步进度作为参考。

9.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，所述分布式存储子系统的文件下载过程包括：客户端选择任意一个跟踪服务器；客户端发送下载请求给某个跟踪服务器，必须带上文件名信息，跟踪服务器从文件名中解析出文件的组、大小、创建时间，然后为该请求选择一个存储服务器用来服务读请求。

10.根据权利要求1所述的基于微服务的分布式论坛系统，其特征在于，所述Elasticsearch实时分布式搜索和分析引擎，将全文搜索、结构化搜索和分析集成到一种服务内，每个字段都能够被索引并能够被搜索，满足用户个性化需求。

Images