本文gtalk server架构介绍整理自视频 Seattle Conference on Scalability: Lessons In Building Scalable Systems 而得，加入Tim少量理解和补充。

演讲者 Reza Behforooz , 是 Google Talk servers的 team leader

1. Google talk server基于 java 平台实现，见视频23:50问答。

2. 关于系统设计与实现难点
和任何xmpp server一样，难点是处理Presence峰值流量，而不是用户数或并发用户数
峰值 total QPS > 10万
Presence = ConnectedUsers * BuddyListSize * OnlineStateChanges
系统在一夜之间通过 gmail/orkut用户突然增大，没有一个缓慢适应的过程。

3. 关于压力测试
1) 实验室式的压力测试只是一个开端;
2) 在正式上线之前，通过真实环境的试验平台，选取大约10%的用户，来做实际环境测试，在不显示UI的前提下，将google talk代码嵌入用户页面
这样在gtalk正式上线时候，所有功能已经是比较有把握的。

4. 数据和应用服务分布到多服务器
可以动态扩容，升级和更新，无须停机
但是 google talk server服务并不考虑跨 IDC, 因为作者认为在海量流量处理下，跨数据中心不利于系统处理。
分布包括数据分布，可参看以前文章MySQL 分表分数据库服务器的一种方案HSCALE, 基于MySQL proxy 另外还有请求和逻辑服务分布

5. abstraction, 抽象与分离
不将问题带入别的系统, gmail/gtalk单独出问题不影响另外一方使用。
gmail, orkut 与 google talk server 完全没有关系
如 gmail 无须关心 google talk 有哪些服务器，有多少，在哪里，怎样分布。
不同系统之间通过 gateway(logic name) 来访问, gateway 再映射到物理的服务器。

6. 避免客户端或服务器自动重连造成DoS问题，服务器瞬时访问过大而瘫痪

7. 在服务器增加profile/monitor机制，包括配置文件，资源状况, 日志, 可以做离线分析。
这样某个服务器发现问题，首先去看 monitor console
profile/monitor不是侵入式的，就是不是通过在服务器程序嵌入代码实现。

8. Google Talk Server其他一些开发经验
程序可以先前和向后兼容(协议/API兼容)，可以逐个或批量升级，新老系统可以共存
有良好的平台来试验新功能，就是上文中提到可以用gmail来试验gtalk，这个是很多公司不具备的
开发人员可以直接访问真实生产环境(production environment)，观察系统实际运行情况来调优和改进。