# GoogleTalk 架构

> 原文： [http://highscalability.com/blog/2007/7/23/googletalk-architecture.html](http://highscalability.com/blog/2007/7/23/googletalk-architecture.html)

Google Talk 是 Google 的即时通讯服务。 有趣的是，IM 消息并不是主要的体系结构挑战，处理用户在场指示将主导设计。 他们还面临着处理小的低延迟消息并与许多其他系统集成的挑战。 他们是如何做到的呢？

网站：http：//www.google.com/talk

## 信息来源

*   [GoogleTalk Architecture](http://video.google.com/videoplay?docid=6202268628085731280)

    ## 平台

    *   的 Linux*   爪哇*   Google Stack*   Shard

    ## 里面有什么？

    ### 统计资料

    *   支持数百万用户的状态和消息。*   每天在 100 毫秒内处理数十亿个数据包。*   IM 与许多其他应用程序不同，因为请求是小的数据包。*   路由和应用逻辑适用于每个数据包的发送方和接收方。*   消息必须按顺序传递。*   Architecture extends to new clients and Google services.

    ## 得到教训

    *   衡量正确的事情。
    -人们问您要交付多少 IM 或有多少活跃用户。 事实证明这不是正确的工程问题。
    -IM 的难点是，由于增长是非线性的，因此如何向所有连接的用户显示正确的状态：ConnectedUsers * BuddyListSize * OnlineStateChanges
    -线性用户的增长可能意味着非常非线性的服务器增长，需要服务 每天有数十亿个状态数据包。
    -拥有大量的朋友，在线人数激增。 IM 的数量不是
    的大问题。

    *   实际负载测试
    -实验室测试虽然不错，但告诉您的信息还不够。
    -在实际产品发布之前进行了后端发布。
    -模拟状态请求，并在线和离线运行数周
    和几个月，即使未返回真实数据也是如此。 它可以解决网络，故障转移等方面的许多
    问题。

    *   动态重新分片
    -在分片上划分用户数据或加载。
    -Google Talk 后端服务器处理一部分用户的流量。
    -零停机时间轻松更改分片数量。
    -不要跨数据中心分片。 尝试使用户保持本地状态。
    -服务器可以关闭服务器，而备份可以接管。 然后，您可以启动新服务器并自动迁移数据，并且客户端会自动检测并转到新服务器。

    *   添加抽象以隐藏系统复杂性
    -不同的系统应该彼此之间几乎一无所知，尤其是当各个小组一起工作时。
    -Gmail 和 Orkut 不知道分片，负载平衡或故障转移，数据中心架构或服务器数量。 可以随时更改，而无需级联整个系统的更改。
    -将这些复杂性抽象到一组在运行时发现的网关。
    -RPC 基础结构应处理重新路由。

    *   了解下层库的语义
    -一切都是抽象的，但是您仍然必须对它们如何工作以构建系统有足够的了解。
    -您的 RPC 是否创建到所有或某些服务器的 TCP 连接？ 含义截然不同。
    -磁带库性能是否正常检查？ 这是体系结构的含义，因为您可以使单独的系统独立发生故障。
    -您应该使用哪个内核操作？ IM 需要大量的连接，但几乎没有任何活动。 使用 epoll 与民意测验/选择。

    *   再次保护操作问题
    -消除服务器活动图中的所有分支。
    -服务器在使用空缓存重新启动时会发生什么？
    -如果流量转移到新的数据中心会怎样？
    -限制级联问题。 从繁忙的服务器返回。 生病时不接受工作。
    -隔离紧急情况。 不要让您的问题感染他人。
    -提取智能重试逻辑策略。 例如，不要坐在 1 毫秒的重试循环中。

    *   任何可扩展系统都是分布式系统
    -为系统的每个组件添加容错功能。 一切都失败了。
    -增加了在不影响服务器的情况下分析活动服务器的功能。 允许持续改进。
    -从服务器收集指标以进行监视。 记录有关系统的所有内容，以便查看因果模式。
    -端到端记录，因此您可以在所有计算机上从头到尾重构整个操作。

    *   软件开发策略
    -确保二进制文件既向后又向前兼容，以便您可以让旧客户端使用新代码。
    -建立实验框架以尝试新功能。
    -使工程师可以使用产品机器。 赋予端到端所有权。 这与许多在其数据中心中拥有完全独立的 OP 团队的公司截然不同。 通常，开发人员无法接触生产机器。

嗨，您好，

我认识了 yahoo IM 团队的成员，而且开发人员还可以维护生产服务器。

Google：开发人员还能维护搜索，Gmail 和其他产品的生产服务器吗？

BR，
〜A

我从不厌倦研究 IM 协议，但是我一直认为状态包太小（可能只有几个字节），以致它们产生的流量完全少于确切的消息...现在我开始思考 是错误的，将在信息来源中观看该视频。

附注：我想知道我是否会停止不断在此网站上找到有趣的帖子……真的很棒！

当他们进入市场时，他们要晚于 msn 和 yahoo，但他们必须做很多工作才能将自己推向市场。
-----
[http://underwaterseaplants.awardspace.com“](<a rel=) >海洋植物
[http://underwaterseaplants.awardspace.com/seagrapes.htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/seaweed .htm”](<a rel=) >海藻