Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

米聊服务器技术选型与架构

3,752 views

Published on

ADC 2012

Published in: Technology
  • thanks:)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

米聊服务器技术选型与架构

  1. 1. 自我介绍• 瞿晋萍• 2010/7月份加入小米至今 – 从2010年10月到现在一直开发米聊 – 米聊服务器端架构师 – 米聊消息系统技术带头人• 之前在Microsoft3年,开发Bing搜索引擎和 windows phone 7云服务客户端• 之前在Lucent和Nortel开发电信软件
  2. 2. 米聊服务器的技术选型与架构设计
  3. 3. 我们生活在一个怎样的年代? 人多,钱傻,速来
  4. 4. 怎样办?天下武功,唯快不败
  5. 5. 工程技术速度的考量 -要保证可持续的快• 快速推出新功能, 试错,验证后快速迭代改进• 快速扩张研发队伍, 模式初步验证后,加大资源投入• 架构快速水平扩张 当业务方向对,推广运营到位,互联网海 量业务规模
  6. 6. 如何保证可持续的快3大纪律,8项注意
  7. 7. 技术选型的3大纪律 大厂都在用 自己搞得掂 项目输得起
  8. 8. 注意1:分治,SOA• 业务分而治之• 技术上: – 服务命名naming/自动发现register&discovery/治理(负 载均衡,柔性服务) – 各个服务封装功能和数据,把接口以ip+port暴露出来• 工程考虑:作为研发和部署的单位,加人方便、独 立研发演进、降低复杂度、• 米聊的技术实现: – Zookeeper,命名树 – 各个服务注册成命名节点 – 客户端先去zookeeper查找,再调用
  9. 9. 注意2:服务/数据访问通过接口• 服务接口要求 – 紧致(compact) – 多版本支持(multi-version) – 同步与异步• 数据访问: – DAL+DAO• 工程考虑:屏蔽变化和复杂性,便于共享,使用和升级• 我们的选择 – 同步用thrift (服务使用HsHa) – 异步用rabbitmq • rabbitmq不就是分布式的actor吗 • 非阻塞,并发性好 • 事件驱动,容错性好 • Traffic shaping, 容峰值流量好 – 数据库访问层DAL(data source)
  10. 10. 注意3:接口/数据要支持多版本化,可扩展• 外部和内部所有接口 – http api – Rpc – Data – XMPP连接协议• 工程考量:灵活扩展又保持前后向兼容• 我们的实现 – http api: url版本化 – Rpc/data: thrift – Xmpp:增加了版本号
  11. 11. 注意4:数据说话• Measure 测量统计:业务和服务质量 – 业务(KPI) – 服务质量(吞吐量throughput和时延latency)• 我们的实现: – 数据采集与统计(scribe log+hadoop+hive) – Counter各个服务之间统计 – Metrics (Codahale)
  12. 12. 注意5: 用哈希partition 所有东西• 为海量用户提供服务的唯一途径• 工程考量:机制越早建立越好。因为业务 爆发很快。另外开发一开始就有scale的概 念,不会做比如join• 我们的实现: – 数据库:一开始就按uid分表分库,做垂直和水 平分割,用DAL屏蔽 – 服务用uid range分割 – Memcached等用一致性hash
  13. 13. 注意6: 服务无状态• 服务要设计成无状态,可以被”kill -9”• 工程考量: – 可以在线升级 – 可以提供多个实例作为冗余,提高可用性和负载均 衡• 我们的实现: – 服务内部无状态,通过cache或者数据库共享状态 – 客户端通过zookeeper发现服务的多个实例,负载 均衡,并且实现出错fallback机制
  14. 14. 注意7: 架构上要支持灰度升级• 快速开发过程中,要有• 工程考量: – 快速开发,错误难免,避免全站影响 – 可做业务比较,尤其让内部员工dogfood最新功能 – 可打不同程度的流量和做dark launch• 我们的实现: – 前端快速接入,不含/少含业务逻辑 – 业务通过前端后,根据ip/白名单/参数里uid/cookie得到 相应的服务partition – uid白名单定义preview partition给内部员工服务 – 基于uid range定义一系列的partition做灰度,诸层次的 升级
  15. 15. 注意8: 一开始就要考虑安全机制• 用户身份认证/授权/数据泄露/防篡改• 工程考量: – 避免见光死
  16. 16. Q&A
  17. 17. 我们正在招聘

×