💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
# 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=) >海藻