《
网站建设众包需求书 【2】 系统架构》文章地址：http://www.tfxk.com/zixun/040S61132013.htm
前一篇，咱们先容了导购网站的页面及基础业务流程。根本业务有以下四项，
1. 系统管理员发帖。发帖包括从电脑本地硬盘中，上传图片，以及简短的文字叙述。
2. 普通用户看帖。用户看到的页面中，可能有多个帖子，每个帖子包括图片和文字描述,
网站制作。
3. 普通用户搜索。搜索结果页面中，也包含多个帖子，每个帖子也包括图片和文字描写。
4.
系统主动统计。系统治理员在什么时光，发过哪些帖子。哪位一般用户在什么时候，看过哪些帖子，珍藏了哪些帖子，从什么帖子转接到哪家电商等等。
系统机能要求，
1. 逐日上传图片不超过 500 张，每张图片不超过 5 MB。
2. 顶峰时段每秒钟普通用户看帖的 PV 不超过 1000 次。
3. 体系刚上线时，业务逻辑可能会频繁修正，所以必需坚持数据库 schema的柔性，不仅便于增添新的 tables，而且每个
table 的 column 数目跟属性也会变更。
4.
系统刚上线时，尽可能少用服务器，以便下降本钱。但是系统必须存在可扩大性，当存储的内容数据逐渐增多时，并且用户人数逐渐增加时，通过增加服务器数量，使全部系统的容量随之增大。系统扩容时，不需要修改数据库设计，不需要大幅度修改代码。
图一刻画了系统部署的计划。
【2】 系统架构" TITLE="
网站建设众包需要书 【2】 系统架构" />
图一. 系统部署图。
整个系统占用两台服务器，两台服务器都使用 Centos 操作系统。
前端服务器中，部署了 Nginx Web Engine。网页用 PHP 编写。
1. 使用 Nginx Web Engine，而不是 Tomcat 或者 Apache。起因是 Nginx
并发性好，并且轻易使用。
2. 使用 PHP 的理由，是 PHP 插件丰硕，便于开发，性能也不错。不使用 Struts+Spring
的原因，是因为后者更使用于业务流程庞杂，但是对于并发性和性能要求不太高的企业利用。
PHP 通过 Thrift 通信框架，与业务逻辑引擎，交流指令以及内容数据，内容数据不仅包括文本内容，也包括图片。
业务逻辑引擎，用 Java 实现。在初期的系统部署中，Java 业务逻辑引擎，与 Nginx Web Engine，还有
MemCached，安排在统一台服务器。在系统上线初期，业务流量压力不大的情况下，这样部署，目标是节俭服务器的应用量。
今后如果业务流量逐步增大以后，Java 业务逻辑引擎可以与 Web Engine
离开，独立运行于其它服务器上。做这个分离时，不需要修改代码，只要要修改 PHP Thrift 的设置即可。
但是用 Thrift 来沟通 PHP 与 Java，也有缺点。主要顾虑是数据传输的性能。
另一种可能的设计是，在 PHP 中直接调用 Java，免去 Thrift 的旁边环节。我们不选用这种设计，原因有三。
1. 这种设计导致 Web Engine 与业务逻辑引擎，严密耦合。不利于未来向散布式系统演变。
2. 在 PHP 中直接调用 Java时，暗藏着数据的序列化与反序列化，所以数据传输的性能，未必会比使用 Thrift
快良多。
3. Thrift 在处理多线程 NIO 数据传输时，手腕丰盛而且稳定性好。在 PHP 中直接调用
Java时，担忧当流量较大，内存占用过高时，会涌现数据丧失。
今后业务流量增大当前，MemCached 缓存，也能够与 Web Engine 分别，独破运行于其它服务器之上。PHP 调用
MemCached 的设置参数，不是写逝世在 PHP 中，而是由 PHP 向 Java 业务逻辑引擎征询。
PHP 在读帖子时，先向 Java 业务逻辑引擎读取帖子的 MetaData，然后根据这些 MetaData数据，向
MemCached 读取内容数据。
兴许有人问，为什么不把 MemCached 挂在 Java 业务引擎身后？换句话说，另外一种设计是，PHP ->
Java -> MemCached -> MongoDB/GridFS 。
我们之所以把 Java 业务引擎，与 MemCached 分离，重要目的在于分离指令流与数据流。
1. 在用户读帖子时，PHP 把恳求转交给 Java 业务引擎，Java 业务引擎回应的是帖子的
MetaData，这个数据往来是指令流，数据量较少，但是来往次数可能较多。
2. PHP 收到帖子的 MetaData以后，依据MetaData，从 MemCached
中获取相干文字和图片内容。这一次是数据流，数据量较大，所以尽可能减少交往次数。
或者有人问，今后业务流量增长以后，不仅须要把 MemCached 与 Web Engine 分离，而且Web Engine 和
MemCached 分辨运行在多台服务器上，怎么办？
先前我们提到，PHP 调用 MemCached 的设置参数，不是写死在 PHP 中，而是由 PHP 向 Java 业务引擎咨询。所以
Java 业务引擎，可以承当起调度的职责，实现系统的负载平衡。
后盾服务器用于存储文本和图片内容，以及搜索。在系统的初期部署中，搜索引擎与数据库运行在同一台服务器。今后业务流量增大以后，两者可以分离，各自运行在不同的服务器上。
之所以使用 NoSQL 的 MongoDB，而不使用 MySQL 之类 RDBMS，是由于导购网站上线初期，业务逻辑尚不稳定。用
NoSQL 数据库，可以保持数据库设置保持柔性，便于修改。
但是选用 MongoDB 也会带来一些问题。
1. MongoDB 的稳固性不如 MySQL，但是鉴于导购网站自身并不波及现金交易，所以对于稳定性的要求并不太高。
2. MongoDB 多个 Replica 之间的同步效力，业界有不少质疑。但是对于这个导购网站来说，临时不需要
Replica。内容数据如果丢失，不会对业务有太大影响。
3. MongoDB 自带的 GridFS 文件系统，性能并不算太好。但是对于导购网站来说，每日上传图片不超过 500
张，每张图片不超过 5 MB，高峰时段每秒钟 PV 不超过 1000 次。GridFS 的性能应当足够了[1]。
MongoDB 固然自带了搜索功效，然而导购网站对搜索的请求较高，所以决议在 MongoDB 体外，用 Lucene
另行建设搜索引擎。
但是用 Lucene 另建搜索引擎的也有隐患。
1. Lucene 索引与 MongoDB 的数据,
成都市网站建设，可能存在不迭时同步的问题。不外，即使呈现不同步的情形，成果是从 Lucene
中搜寻出来的成果，在 MongoDB 中并不存在。这个问题，可以由业务流程引擎辨认并处置。
2. 当数据文件越来越多时，Lucene 索引将越来越大。假如每次插入新的数据，便立即更新 Lucene 索引，那么更新 Lucene
索引的速度，将越来越慢。解决措施是树立两套 Lucene 索引，一个是 Main Index，包含所有数据，另一个是 Rapid
Index 只包括当日索引。用户搜索时，同时使用两套索引，而后合并搜索结果。天天夜间，把 Rapid Index 合并进 Main
Index，接着清空 Rapid Index。
图二是发帖、看贴、和搜索，这三个主要业务的内部数据流程，便利读者进一步懂得在这个系统架构下，数据的内部传输。
至于系统自动统计这项业务，由 Java 业务流程引擎把持。统计业务的内部数据流程，十分简略，这里就不胪陈了。
图二. 发帖、读贴、搜索三个业务的内部数据流程,
网站建设公司。
Reference
[1] Nginx + GridFS 的性能。
(责任编辑：网站建设)
网站建设众包需求书 【2】 系统架构相关文章