用户中心与应用数据通信求解决方案

Question

借宝地人气，呵呵。产品结构示意图：
我目前的方法是 每个应用里面丢一个 API_Client，API_Client模拟浏览器访问API_Server发送Httpheader和POST相关数据，API_Server接收数据执行相关操作并显示结果数据，然后API_Client通过读取API_Server执行后显示的结果代码获取数据结果供应用使用。这样的话 每个请求都是模拟一个访问，如果应用中的某个页面有多个API请求，比方说是日志列表，每一篇存储了相关好友的ID，然后在页面列表显示简介的时候需要把ID对应的好友姓名显示出来（通过API获取）那这一页有30篇日志的话 就会有30个模拟访问 用户中心了。这个会不会对用户中心造成太大的压力。不过上面这个情况是页面上的 还可以用AJAX来解决这个问题，但是有的请求是程序中需要对结果进行处理的不能用JAVASCRIPT，比方说用户登录已验证（整站使用主域cookie：.abcde.com作为Cookie域），应用站点检测到存在登录的cookie但是不确定这个数据是否真实，便需要请求用户中心验证（cookie中加密存储了用户ID和密码），API_Client发出一个请求需要验证用户，API_Server接收到请求执行验证cookie的数据并显示结果（True or Flase），API_Client读取结果进行分析Flase的话提示需要登录，这个情况就不能用AJAX执行了。
我看了 UCenter 和 他旗下的应用通信 他的 uc_client 是可以直接访问Ucenter的数据库的，这种方式我感觉不大好，把数据库操作直接开放给应用。 烦恼中特来宝地求解决方案，或者我的理解有错 望指点，谢谢。

Answer 1

从逻辑上我看不出有什么问题。客户端有多个请求有什么问题呢？当qq或者msdn刚刚连上服务器的时候，仅仅在瞬间，可以监测到上百个请求，而你比较长时间才有30多个请求。不过，有些基本的架构确实有很大改进余地。你的服务器是什么技术呢？首先它应该优先提供tcp接入，只有当客户端以tcp/udp接入乌发连通时才应该访问服务器的http接入，好处是tcp通常会比http快好几倍（包括解析时间）。其次，服务器端对http接入的响应，既可以使用应用程序（console或者windows service）也可以使用asp.net+IIS网站作为宿主，自定义应用程序的好处就是比asp.net+IIS网站更快1、2倍。当然啦，这些都是成熟的技术，越是速度慢的那些东西反而越可靠和稳定，例如asp.net+IIS的方式可以在服务器和系统异常时自动重启。使用udp和tcp在服务器端基本上一样，但是对于客户端来说它又快了不少。我对c/s数据库编程有些“鄙夷”。早年间我做过一个上百台机器c/s方式访问数据库的系统，但是系统一上线就丢人现眼了，用户恨不得让我陪10万块钱（估计他们担心我会让他们半个月内都成为半个聋子瞎子），幸好我反应快，在24小时之内改为上百台机器分别跟服务器端独立的一个数据库访问（对于150个客户端，我使用程序一次性生成了150个独立的数据库），然后后台的一个进程再去不断地分别访问每一个独立的数据库收集汇总和下发数据。

Answer 2

感谢sp1234的答复。其实我的站点采用的是PHP技术（那边人气不佳）特来这边求教啦，因为产品访问量很可能非常高（在线1w的样子）那样页面上的30个请求也只是个比喻，如果是1W×30就变30W了。整个系统都是采用B/S模式的，API_Client发送请求是用fsockopen。本来网页的并发可能不高，但是在一个页面存在多次API请求就都变成并发了。目前测试服务器环境是采用 IIS+PHP+MySQL 上线后将采用Linux服务器。

Answer 3

服务器端主要是进行压力测试。一个服务器有时候每秒只能连续处理不到10个客户端请求，如果你尽可能并发处理，也许可以提高到50个，更多地则是在排队。提高服务器并行处理能力以及缓存能力是根本，而进行顺序处理的程序设计和测试往往会得到错误的结果。总的来说，我的印象是，基于web的技术都是为了稳定性、总体吞吐量而牺牲单个任务的响应速率。用web相关技术作为服务，不是首选方案。