到目前为止，我们知道了Lucene提供了强大的搜索库，用以支持文档索引的建立，执行查询，以及对结果进行排序。还有，利用schema.xml，你可以灵活的定义索引结构，只需要修改XML配置即可，不需要针对LuceneAPI进行编程。 接下来你需要能够通过网络来获取这些服务。所以在下一节，我们就来学习Solr作为Java web应用是如何运行的，以及她是如何通过XML，JSON,HTTP等标准技术来与其他系统集成在一起的。
1.1.3 Java web应用
Solr作为一个Java web应用，既可以运行在任意一个现代JAVA Servlet引擎之上，比如Jetty或是Tomcat，也可以运行在JBoss或是Oracle AS之类的完整的J2EE应用服务器上。图1.3展示了Solr服务器的主要软件模块。
图1.3可能在第一眼看上去时显得内容有点多。我们可以花点时间先过一遍，先熟悉熟悉名词和术语。如果有看不懂的术语或是概念也不用担心，等你读完本书的时候，图1.3中的所有概念和术语你都会有很深的理解。
正如我们在本章开头介绍中所提到的那样， Solr的设计者们指出Solr非常适合集成到现有的系统中，作为现有系统的一个有力补充。事实上，你很难找出一个Solr无法集成进去的系统。正如我们将在第二章里看到的那样，你在下载Solr之后只需要花上几分钟，就可以启动一个示例的Solr系统了。
为了达到易于集成的目标，Solr的核心服务需要能够被不同的应用和编程语言访问。Solr提供简单的类REST服务，支持XML，JSON，HTTP等标准。顺便说一句，我们并不使用RESTFul一词来描述Solr基于HTTP的 API，因为它并不严格遵守所有的REST(Representatonal state transfer)原则。例如，在Solr中会用到HTTP POST来删除文档，而不是用HTTP DELETE。
类REST的接口对于基本功能来说已经足够好用了，但是开发者们经常会希望能够用自己熟悉的编程语言来编写一些调用网络服务和处理返回的模版化工具。好消息是针对许多流行的编程语言，Solr都提供了相应的库，包括Python， JAVA, .NET, 还有Ruby等等。
1.1.4 同一服务器上建立多份索引
现代软件应用架构的一个显著特点就是面对快速变化的需求的灵活性。Solr在这方面有个很有用的特性，就是你不必只通过一份单一的索引来完成Solr中所有的任务。Solr支持在单一的Solr 引擎上运行多个Solr 核心。在图1.3中， 我们描述了多个solr核心在同一个Java web应用环境中作为不同的层同时运行的场景。
每一个核心都有一个独立的索引和配置，在一个Solr实例中可以存在多个Solr 核心。这样你只需要一个Solr服务器就可以管理多个核心， 可以方便的实现服务器资源共享，以及及监控维护服务的共享。Solr有专门的API用于创建和管理多个Core。
Solr多核心支持功能的一个应用是数据分区，比如用一个core来负责最近更新的文档，而用另外的core来处理之前生成的文档，这个功能被称为按时间顺序分片。
在我们的房地产搜索应用中，我们也可以使用多个core来分别处理不同的类型的房屋资源，每一类用一个单独的索引文件来管理。比如说针对农村用地的房地产信息来说，买一块农业用地的流程和买一套商品房的流程是不同的，我们完全可以用一个单独的索引来管理农业用地的相关信息，将其保存在一个单独的core里。
1.1.5 可扩展性（通过插件扩展功能）
图1.3展示了Solr种最主要的三个子系统：文档管理，查询处理，和文本分析。当然，这些子系统是对Solr中复杂的子系统所做的宏观抽象，我们会在稍后的章节中一一研究这些子系统。这其中的每一个都是由一系列功能模块的流水线串成的，你可以在流水线中串入新的功能模块。这意味着如果你想给solr加入新的功能的话，根本不需要重写整个查询处理引擎，只需要在合适的位置串入自己的新功能模块即可。这样一来Solr的核心功能模块扩展和定制起来都很方便，可以完全按照你的特定应用需求进行定制。
1.1.6 可伸缩性
Lucene是一个查询速度非常快的搜索库，而Solr完全发挥出了Lucene的强劲性能。
但是抛开Lucene的性能不谈，作为一个服务器来说，由于CPU和I/O的限制，同一时刻能够响应的用户数和请求数都是有限制的。
Solr实现可伸缩性的第一张牌是灵活的cache管理功能。该功能可以避免服务器重复进行耗费资源的操作。具体来说就是Solr预先设置了一些cache来节省开销很大的重复计算，比如Solr会缓存查询过滤器的计算结果。我们会在第四章学习Solr的缓存管理功能。
缓存的作用是有限的，为了处理更多的文档和获得更高的查询吞吐能力，你需要能够通过扩展服务器来横向扩展系统的性能。现在我们来研究一下Solr扩展时最常见的两个方面。第一个是查询的吞吐能力扩展，也就是你的引擎每秒钟可以处理的最大查询数是多少。虽然Lucene可以非常快的处理每一个查询请求，单台服务能够同时并发处理的请求出还是会限制整体的查询吞吐能力。如果需要得到更高的查询吞吐能力，你需要增加查询服务器和索引的拷贝数量，以便让更多的服务器来同时处理更多的请求。这意味着如果你的索引复制到了三台服务器上，那么你每秒钟大约可以处理原来三倍的请求数量，因为每台服务器现在的负荷是总的查询量的三分之一。在实际应用中很少能够获得如此完美的现行扩展能力，所以使用三台服务器可能大约能达到原来2.5倍左右的性能。
另一个扩展维度是被索引的文档数。如果你正在处理海量的文档， 那么当单个Solr实例中索引的文件数量多到一定程度的时候，查询性能的瓶颈也会出现。解决的方案是可以把索引文件切分成一个个被称为“分片”的小块，然后把查询请求分布到这些分片上进行操作。
使用虚拟化的商用硬件进行扩展
现代计算机技术的一个趋势就是构建可以在虚拟化的商用硬件上进行横向扩展的软件架构。简单来说，就是可以通过添加普通的商用机服务器就可以处理更多的流量。类似于Amazon EC2这样的云计算服务提供商通过使用虚拟化的商用硬件来满足这种趋势的需求。虽然Solr可以再虚拟化硬件上运行，但是需要注意的是Solr对于I/O和内存很敏感。因此，如果在你的企业中搜索性能被放到了最高优先级来考虑，那你应该考虑在配备有高性能磁盘（比如SSD固态硬盘）的高端硬件上去部署Solr。部署Solr时硬件方面需要考虑的问题将会在第13章中进行讨论。
可伸缩性很重要，但是出错后的自动恢复能力在现代系统中也很重要。在下一节中，我们来讨论一下Solr是如何处理软件和硬件中的错误的。
1.1.7 容错性
除了可伸缩性，我们还需要考虑如果当server中的一个或多个出了问题时应该怎么处理。尤其是你准备把Solr部署到虚拟化的商用硬件上时更要考虑这个问题。最低的要求是你至少要打算去处理这些错误。即便是使用高端的硬件配上最优秀的架构，错误还是会发生的。
我们假定你的系统中一共有4个分片的情况。如果2号分片所在的服务器断电了，那么此时Solr就不能继续正常的建立文档索引了，