首页IT科技小米的工程师是啥(小米资深工程师瞿晋萍(男):米聊服务器的技术选型和架构设计)

小米的工程师是啥(小米资深工程师瞿晋萍(男):米聊服务器的技术选型和架构设计)

时间2025-09-17 03:10:39分类IT科技浏览5730
导读:小米资深工程师瞿晋萍:米聊服务器的技术选型和架构设计...

小米资深工程师瞿晋萍:米聊服务器的技术选型和架构设计

2012年技术嘉年华于7月7日-8日在杭州海外海皇冠假日酒店拉开序幕                 。会议现场以“开放&分享                 ”为主题                ,汇聚D2                 、iData                        、TCon        、TaoMobile         、aDev                        、iDeOps                、Ucan 为代表的专业品牌会议                         ,此外特色展区还将特设workshop          、创业展区两大创新部分                        。大会还邀请业界知名专家组成最强嘉宾阵容        ,内容覆盖放在“前端                        ”                         、“高性能网络服务        ”                、“海量数据存储和处理         ”、“互联网测试                        ”等热点技术主题领域                ,精彩不容错过        。 小米资深工程师 瞿晋萍 瞿晋萍于2010年加入小米至今                         ,曾参与开发米聊软件        ,是负责米聊服务端架构师        ,米聊消息系统技术带头人         。他发表《米聊服务器的技术选型和架构设计》主题演讲                         ,首先幽默的口吻形容了现在的时代:人多                 ,钱傻        ,速来;其背后寓意是“天下武功为快不败                ”                        ,想要在竞争如此激烈的时代中脱颖而出                 ,掌握自己命脉,需提高自身速度                        。 如何提升速度?瞿晋萍认为分为三个流程                        ,首先                         ,快速推出新功能,测试并找错                ,验证后快速改进;其次                         ,快速扩张研发队伍        ,加入大资源投入;最后                ,架构快速水平扩张                         ,扩张运营到位        ,增长互联网业务规模                。 众所周知        ,小米公司仅创业2年就取得了不菲的成绩                         ,对于技术选型                 ,其遵循3大纪律:大厂都在用;自己搞的定;项目输的起         。创业选型的成功是一种选择的艺术        ,创业最大成本——机会                        ,选型错了                 ,时间也随之浪费,丧失翻身机会                         。至此                        ,在快的同时也需要慢                         ,抓住机遇,保证质量与服务                ,就是所谓的“慢既是快         ”                。 在演讲中                         ,瞿晋萍从业务分而治之                         、服务/数据访问通过接口                        、接口/数据支持多版本化、数据说话                 、用哈希partition                        、服务无状态        、架构上要支持灰度升级和安全机制等八个方面具体介绍了米聊服务器构架的设计原则和构架演进。 1.业务分而治之 工程考虑:各个服务封装功能和数据        ,把借口以ip+port暴露出来 米聊技术实现:作为研发和部署的单位                ,独立研发演进                         ,降低复杂度                         。 —Zookeeper        ,命名树 各个服务注册成命名节点 客户端先去找Zookeeper查找        ,再调用 设计服务怎么把复杂性藏于后台                         ,这是技术需要解决的问题                 ,选择分布式        ,强移植性服务Zookeeper                        ,客户端通过名字找到相应调用的服务                        。一个服务失败Zookeeper会自动在命名树中摘掉服务                 ,团队可以节省人力,并专注于此                        ,开始后台服务分布式化。 2.服务/数据访问通过接口 接口要求:紧致(compact)                 、多版本支持(multi-version)                        、同步与异步 数据访问:DAL+DAO 工程考虑:评比变化和复杂性                         ,便于共享,使用和升级 米聊实现: 同步使用Thrift(服务使用HsHa) 异步使用Rabbitmq Rabbitmq是分布式的Actor 非阻塞                ,并发性好 事件驱动                         ,容错性好 Traffic shaping        ,容峰值流量好 数据库访问层DAL(data source) 3.接口/数据支持多版本化                ,可扩展 外部和内部所有接口要求:http api        、rpc         、data                        、xmpp连接协议 工程考量:灵活扩展又保持前后兼容 米聊实现: Http api:url版本化 Rpc/data:thrift Xmpp:增加了版本号 4.让数据说话 Measure测量统计:业务KPI和服务质量(吞吐量Throughput和时延latency) 米聊实现: 数据采集与统计(SCRIBE LOG+HADOOP+HIVE) Counter各个服务之间统计 Metrics(codahale) 5.用哈希partition所有东西 为海量用户提供服务的唯一途径 工程考量:机制越早建立越好                         ,业务爆发很快        ,另外开发一开始就要有scale的概念 米聊实现: 数据库:一开始就按UID分表分库        ,做垂直和水平分割                         ,用DAL屏蔽 服务用uid range分割 Memcached用一致性的hash 6.服务无状态 服务要设成无状态                 ,可以被“kill-9                         ” 工程考量:可以在线升级        , 可以提供多个实例作为冗余                        ,提高可用性和负载均衡 米聊实现: 服务内部无状态                 ,通过cache或者数据库共享状态 客户端通过Zookeeper 发现服务的多个实例,负载均衡                        ,并实现出错fallback机制 7.架构上要支持灰度升级 米聊实现: 前端快速介入                         ,不含少含业务逻辑 业务通过前端后,根据ip                、白名单         、参数里uid/cookie得到相应的服务partition Uid白名单定义preview partition给内部员工服务 基于uid range定义一些里的partition做灰度                ,诸层次的升级 8.一开始要考虑安全机制 用户身份认证                         、授权                、数据邪路、防篡改 工程考量:避免见光死 更多内容:阿里技术嘉年华直播页面

小米资深工程师瞿晋萍:米聊服务器的技术选型和架构设计

2012-07-07 11:04 | 238次阅读

|

来源:CSDN 【已有0条评论】发表评论

关键词:小米

|

作者:张祺

|

收藏这篇资讯

2012年技术嘉年华于7月7日-8日在杭州海外海皇冠假日酒店拉开序幕                 。会议现场以“开放&分享                ”为主题                         ,汇聚D2                         、iData                        、TCon、TaoMobile                 、aDev                        、iDeOps        、Ucan 为代表的专业品牌会议        ,此外特色展区还将特设workshop                  、创业展区两大创新部分                        。大会还邀请业界知名专家组成最强嘉宾阵容                ,内容覆盖放在“前端”                        、“高性能网络服务                         ”        、“海量数据存储和处理                        ”         、“互联网测试”等热点技术主题领域                         ,精彩不容错过        。

小米资深工程师 瞿晋萍

瞿晋萍于2010年加入小米至今        ,曾参与开发米聊软件        ,是负责米聊服务端架构师                         ,米聊消息系统技术带头人                 。他发表《米聊服务器的技术选型和架构设计》主题演讲                 ,首先幽默的口吻形容了现在的时代:人多        ,钱傻                        ,速来;其背后寓意是“天下武功为快不败                 ”                 ,想要在竞争如此激烈的时代中脱颖而出,掌握自己命脉                        ,需提高自身速度                        。

如何提升速度?瞿晋萍认为分为三个流程                         ,首先,快速推出新功能                ,测试并找错                         ,验证后快速改进;其次        ,快速扩张研发队伍                ,加入大资源投入;最后                         ,架构快速水平扩张        ,扩张运营到位        ,增长互联网业务规模        。

众所周知                         ,小米公司仅创业2年就取得了不菲的成绩                 ,对于技术选型        ,其遵循3大纪律:大厂都在用;自己搞的定;项目输的起         。创业选型的成功是一种选择的艺术                        ,创业最大成本——机会                 ,选型错了,时间也随之浪费                        ,丧失翻身机会                        。至此                         ,在快的同时也需要慢,抓住机遇                ,保证质量与服务                         ,就是所谓的“慢既是快                        ”                。

在演讲中        ,瞿晋萍从业务分而治之                        、服务/数据访问通过接口                、接口/数据支持多版本化         、数据说话                         、用哈希partition                、服务无状态、架构上要支持灰度升级和安全机制等八个方面具体介绍了米聊服务器构架的设计原则和构架演进         。

1.业务分而治之

工程考虑:各个服务封装功能和数据                ,把借口以ip+port暴露出来

米聊技术实现:作为研发和部署的单位                         ,独立研发演进        ,降低复杂度                         。

—Zookeeper        ,命名树

各个服务注册成命名节点

客户端先去找Zookeeper查找                         ,再调用

设计服务怎么把复杂性藏于后台                 ,这是技术需要解决的问题        ,选择分布式                        ,强移植性服务Zookeeper                 ,客户端通过名字找到相应调用的服务                。一个服务失败Zookeeper会自动在命名树中摘掉服务,团队可以节省人力                        ,并专注于此                         ,开始后台服务分布式化。

2.服务/数据访问通过接口

接口要求:紧致(compact)                         、多版本支持(multi-version)                        、同步与异步

数据访问:DAL+DAO

工程考虑:评比变化和复杂性,便于共享                ,使用和升级

米聊实现:

同步使用Thrift(服务使用HsHa)

异步使用Rabbitmq

Rabbitmq是分布式的Actor

非阻塞                         ,并发性好

事件驱动        ,容错性好

Traffic shaping                ,容峰值流量好

数据库访问层DAL(data source)

3.接口/数据支持多版本化                         ,可扩展

外部和内部所有接口要求:http api、rpc                 、data                        、xmpp连接协议

工程考量:灵活扩展又保持前后兼容

米聊实现:

Http api:url版本化

Rpc/data:thrift

Xmpp:增加了版本号

4.让数据说话

Measure测量统计:业务KPI和服务质量(吞吐量Throughput和时延latency)

米聊实现:

数据采集与统计(SCRIBE LOG+HADOOP+HIVE)

Counter各个服务之间统计

Metrics(codahale)

5.用哈希partition所有东西

为海量用户提供服务的唯一途径

工程考量:机制越早建立越好        ,业务爆发很快        ,另外开发一开始就要有scale的概念

米聊实现:

数据库:一开始就按UID分表分库                         ,做垂直和水平分割                 ,用DAL屏蔽

服务用uid range分割

Memcached用一致性的hash

6.服务无状态

服务要设成无状态        ,可以被“kill-9        ”

工程考量:可以在线升级                        , 可以提供多个实例作为冗余                 ,提高可用性和负载均衡

米聊实现:

服务内部无状态,通过cache或者数据库共享状态

客户端通过Zookeeper 发现服务的多个实例                        ,负载均衡                         ,并实现出错fallback机制

7.架构上要支持灰度升级

米聊实现:

前端快速介入,不含少含业务逻辑

业务通过前端后                ,根据ip        、白名单                 、参数里uid/cookie得到相应的服务partition

Uid白名单定义preview partition给内部员工服务

基于uid range定义一些里的partition做灰度                         ,诸层次的升级

8.一开始要考虑安全机制

用户身份认证                        、授权        、数据邪路         、防篡改

工程考量:避免见光死

更多内容:阿里技术嘉年华直播页面

声明:本站所有文章        ,如无特殊说明或标注                ,均为本站原创发布                         。任何个人或组织                         ,在未征得本站同意时        ,禁止复制                        、盗用                、采集         、发布本站内容到任何网站                         、书籍等各类媒体平台                        。如若本站内容侵犯了原著者的合法权益        ,可联系我们进行处理。

创心域SEO版权声明:以上内容作者已申请原创保护,未经允许不得转载,侵权必究!授权事宜、对本内容有异议或投诉,敬请联系网站管理员,我们将尽快回复您,谢谢合作!

展开全文READ MORE
marcadores是什么意思(Marcel’s World Marcel Neuhausler) CSS 教程 网盘(【玩转CSS】这些高级技巧,你都会吗)