背景：
最近开发一个大型的仓储管理平台项目，项目的前身是无数个版本的历史悠久的基于CS模式的Windows桌面程序。然后对于每一个客户，我们可能需要为之定制比较个性化的特殊功能。于是，有一个核心研发团队，以一两年为周期开发一个核心功能版本的软件；然后拿出去推广销售，每每销售成功，做售前的同事都是拿了一大堆定制化的需求回来的；然后一场在核心功能上的定制和个性化扩展就开始了，完成开发就可以去客户现场实施了；最后，就会有部分维护的同事将这个客户的系统纳入他们的日常工作清单中。周而复始。诚然，这种方式在大多数软件公司都能看到，但是我公司是一个有想法的公司，怎么可能让这样的套路进行到底呢！？
这里把关于为什么要做平台的描述省略，总之就是要做平台了，搞SaaS了，不买软件卖账号了。但是这个时候产生了一个关乎用户体验的事情：从前使用CS程序，在每个客户端缓存了大量数据（通常有数G），所以客户对于信息的检索非常的快速；如果换成BS架构，咱可没地方存那么大量的数据，而且通过SaaS的方式会把所有客户的数据都存放在平台端，事情发展到这里，好像项目的失败已经注定。
就在大家焦头烂额，苦闷不堪的时候，我们发现了一种已经在江湖上良好发展的技术：搜索引擎。虽然没用过，但是听过嘛！于是一段围绕着搜索引擎的工作便就此展开。
搜索引擎：
*给出了这样的定义：搜索引擎指自动从因特网搜集信息，经过一定整理以后，提供给用户进行查询的系统。
工作原理：
1、搜集信息：搜索引擎的信息搜集基本都是自动的。搜索引擎利用称为网络蜘蛛的自动搜索机器人程序来连上每一个网页上的超鏈接。机器人程序根据网页链到其中的超链接，就象日常生活中所说的“一传十，十传百”一样，从少数几个网页开始，连到数据库上所有到其他网页的链接。理论上，若网页上有适当的超链接，机器人便可以遍历绝大部分网页。
2、整理信息：搜索引擎整理信息的过程称为“建立索引”。搜索引擎不仅要保存搜集起来的信息，还要将它们按照一定的规则进行编排。这样，搜索引擎根本不用重新翻查它所有保存的信息而迅速找到所要的资料。想象一下，如果信息是不按任何规则地随意堆放在搜索引擎的数据库中，那么它每次找资料都得把整个资料库完全翻查一遍，如此一来再快的计算机系统也没有用。
3、接受查询：用户向搜索引擎发出查询，搜索引擎接受查询并向用户返回资料。搜索引擎每时每刻都要接到来自大量用户的几乎是同时发出的查询，它按照每个用户的要求检查自己的索引，在极短时间内找到用户需要的资料，并返回给用户。目前，搜索引擎返回主要是以网页链接的形式提供的，这样通过这些链接，用户便能到达含有自己所需资料的网页。通常搜索引擎会在这些链接下提供一小段来自这些网页的摘要信息以帮助用户判断此网页是否含有自己需要的内容。
正确的方向：
通过背景和搜索引擎的原理描述，初步可以判断，方向是正确的。
第一、搜集信息。我们的信息来自于仓储管理平台的日常业务，这些数据本身便存储在平台的数据库，搜索引擎要做的搜集信息，应该是能够想办法把业务系统中的数据搜集过来。无论方法采用主动还是被动，总之信息是要搜集的，只不过范围由整个互联网变成了我们自建的平台。
第二、整理信息。平台的数据存储是遵循RMDBS的，形式上有其固有特点，是否利于检索，至少在开始正儿八经做搜索的时候是有待商榷的。在这个假定的基础上，我们一定需要对搜索引擎搜集到的信息进行编排和整理的。
第三、接受查询。毫无疑问，这是我们最终的目标，也是用户能够感受到的唯一功能---查询，而且是高效的查询。
怎么选？
随着互联网技术的发展。开源的搜索引擎实在数不胜数，诸如Lucene、Sphinx、Xapian、Nutch、Datapark Search、Zettair、Indri、Terrier、Galago、Zebra、Solr、ElasticSearch、Whoosh等。我们选择的范围也基本确定在这里面。结合公司实际情况附加如下原则：
1、应用广泛（别人把坑踩得差不多了）
2、易于使用（节省学习时间和成本）
3、社区活跃（不用担心过几天它从江湖上消失）
4、技术跨度不大（降低学习成本）
综上、最后初步选定了Solr作为项目的第一候选方案。主要因为，它建立在Lucene之上；基于全文索引；提供RESTful API；使用门槛并不高；已经在市场上有广泛的应用。
愿景：
在开始了解Solr方面的资料的时候，查了很多网站但是中文信息很少，而且大多是讲解如何安装入门的，实际用处并不大。我希望能结合我项目的实际使用，把这次经历记录下来，同时尽可能丰富中文关于中文方面的资料。后面的分享会围绕Apache Solr 6.3开始。