这样的部署，给后期带来的问题是很多的。当服务程序死掉，那么整个网站就无法访问了。前台web程序的压力和后台服务程序的压力同在一台服务器上。很容易造成cpu、内存过于繁忙而导致运行效率低下。如果有上万人访问，这样的架构跑起来真是有些力不从心了。
虽然很多程序语言都已经提供了分布式业务处理的类，而且功能也非常的强大。但是操作起来过于复杂，很多个性化的需求都不能得到高效率的解决。很多功能使用起来也过于牵强。安全性问题由于其接口的透明性而变得比较脆弱（当然高手另当别论了）。
现在把我参与携购网（http://www.xiegoo.com）这个系统的开发来详细讲解下其部署。目前都流行把网站页面、服务程序、数据完全独立开来，这样的好处就不再累赘的讲述了。携购网的结构层我们可以分为以下几个部分：
1. 页面展示层
2. 前台数据处理层
3. 前台协议处理层
4. 前台数据传输层
5．后台数据传输层
6. 后台协议处理层
7. 后台数据处理层
8. 后台数据缓存层
9. 数据库
上面从宏观上可以看到，主要分成前台、后台。前台需要数据的时候，向后台发起操作协议。数据的传输是通过SOCKET 链接来完成的。关键的问题就是前台后台之间的协议。只有通过先前大家约定好的协议，后台才能知道前台需要的是什么样的操作。协议是前台与后台服务程序交互的基础。
协议可以有多种格式来定义：典型的有数据流格式、XML格式等。
数据流格式：如中国联通短信网关接口协议SGIP，就是约定好长度。比如前8个字节表示的数据的长度，紧跟着的10个字节表示企业的ID号等。
数据流格式的好处是，传输的数据少。冗余数据可以最小。缺点是：因为数据流的可读性非常差，所有一旦运行中出现错误时要找到问题的所在比较麻烦些。另外，由于各种编程语言在变量定义上存在差别，所以，如果使用结构体或者实体类的数据流的传送方法，可移植性也比较差。这种方法一般用于速度要求非常高的系统下，如果游戏系统等。
XML格式协议，这里我们特别强调这种协议格式，携购网使用的就是XML格式协议的传送。相对于数据流格式的传送，这种方法有很多的优点。虽然在传送的过程中增加了比较多的冗余数据，但是XML的可读性非常高，可扩张性也非常高。前台程序和后台程序可以使用完全不同的程序语言。只要该程序语言支持XML的读写，就可以与后台服务程序进行交互。因此，XML格式的协议通用性非常好。如果系统对速度要求不是非常苛刻的，建议使用该格式协议。具体的架构示意图如下：
图一 架构部署示意图
注意：
黄底色的区域做为一个整体不可分割，必须放在同一台服务器上，其他的就可以任意的放。建议放在同一段IP的局域网内，这样访问的速度可以更快。
当一个用户访问页面的时候，整个流程是这样走的：
- 当用户访问某个页面（我们假设这个页面不是已经生成好的静态页面，即：该页面需要访问数据库操作）。
- 页面展示层将调用本地“前台业务处理程序”，告知需要具体什么样的操作。
- 前台业务处理程序将用户的需求分解成对应的数据实体操作。同时将其交给协议解析层。
- 这里的协议解析层不仅仅是一个解析的过程，当该层得知需要从服务器获取数据时，它会将“业务处理层”的操作请求，转换成后台可以认识的XML格式协议。如果XML数据需要加密处理，那么在该层就将其加密处理。同时将其转交给“数据传送层”。
- 数据传输层接收到需要传送数据的命令后，它会从SOCKET链接缓存池里找到当前空闲的链接，进行与服务器之间的对接。这个过程中，数据传输层判断如果有多个后台服务程序可以供选择的时候，它会根据繁忙程度，找到最为空闲的一个服务进行传输。也就是说，数据传输层，先找到要传输的服务器地址。然后再找到与之对应的SOCKET链接缓存池里找最空的链接。
- 后台服务程序的“数据传送层”接收到前台发来的数据后，将其转交给协议解析层。
- “后台协议解析层”判断如果数据经过了加密处理，那么先对其进行解密处理，同时，将接收到的数据解析、转换后，提交给对应的后台业务处理程序，进行处理。比如说查询用户数据，那么就直接会定位到业务处理程序的用户查询的操作入口。
- 后台业务处理程序调用数据缓存。如果要查询的数据在缓存里已经存在，那么直接从缓存里返回需要的数据。如果没有则需要从数据库里查找。
以上是从前台调用到后台的整个单向流程。当需要的数据，或者需要的操作已经完成时，程序到这里并不是停止了。后台需要将查询到或者操作后的结构返回给前台。那么需要返回操作。直到前台展示页面把最终的数据展示给客户为止。
看上去整个流程非常复杂，有很多朋友会问如果这样的架构速度上怎么样？那么你可以去访问下携购网（http://www.xiegoo.com）试试看，总整理来说，携购网的速度已经是比较理想的了。
这样的架构如果单从小访问量来看，是看不出该构架的优点，因为目前传统的做法是直接访问数据库，在访问速度上看，还是相当可以的，但是如果有几万，几十万用户访问的时候，那怎么办呢？直接访问数据库，或者是单机版的架构我看只能是老牛推破车了呵呵。
接下来，我们来分析下当访问量非常大的时候，该架构如果应对？大家可以看到页面展示层，只接受用户的访问请求，所以无论从SOCKET连接压力，还是业务处理压力都是非常小的。因此，我们在这里暂时不考虑该层的减压方案。
压力最大的部分就是业务处理部分和数据库部分。因为我们的架构是分布式处理的，所以当你的程序写的不是非常好的情况下（当然不能直接影响到数据库的死锁等等），只要不断的增加服务器，就可以解决不断增加的用户访问量。数据库部分的优化，我相信很多朋友比我更加熟悉，有太多的数据库优化方案，大家可以去网上找找。
如果你的用户访问量真的非常大，那么软、硬件一起来吧，加上均衡处理机，再加上我们这套架构，相信已经能满足你的需求了。
很多朋友会说，前面讲的那么理论化，听的云里雾里，能不能讲点具体的，那下面我主要讲解下最关键的XML协议部分吧：
前台客户端：
<? XML version=”1.0” encoding=”UTF-8”?> <params> <busi> user.center</busi> <oper> user.query</oper> <queryType>id </queryType> <queryCondition>106</queryCondition> <sort> <key/>根据某个关键字排序 <direction/> 升序还是降序desc or asc </sort> <queryState> //分页参数 <pageCnt></pageCnt> //每页显示的记录条数 <pageNum></pageNum> //当前的页码 </queryState> </params>
后台处理完毕后，返回结构协议：
<? XML version=”1.0” encoding=”UTF-8”?> <result> <success/> <msg/> <queryState> <pageCnt/> <pageNum/> <totalRec/> //总共查询到的记录数 <curPageCnt/> //当前页码上的记录数 <totalPage/> //总共分几页 </queryState> <itemList> <item> <id> <name/> </item> …… </itemList> </result>
上面两个协议的操作是：查询ID=106的用户的信息。
当然，我们的协议不希望明文给人家SOCKET获取后破解，那么你可以对你的XML数据加密吧。具体的加密方法到网上找找，太多了。但是不要用不可逆的加密方法，否则请求发过去，后台服务程序要发火了。
XML协议可以做很多事情，并不仅局限于发送文本命令，类似于文件上传，下载，等等你都可以通过XML协议的命令来完成。 携购独立网店系统（ http://www.shopxg.com）上的所有上传，下载就是这样，全部是通过自己的协议格式完成的。
好了，讲了这么多不知道大家有没有理解，再认认真真，仔仔细细的看几遍架构图，相信你会明白起来的，另外大家也可以思考下，这样的部署，如何解决南北互通的问题？
转载至： http://www.qqgb.com/Program/VC/VCZH/Program_254800.html
