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

自我介绍瞿晋萍 2 0 1 0 /7月份加入小米至今从2 0 1 0年1 0月到现在一直开发米聊米聊服务器端架构师米聊消息系统技术带头人之前在Microsoft3年，开发Bing搜索引擎和windows phone 7云服务客户端之前在Lucent和Nortel开发电信软件 米聊服务器的技术选型与架构设计 我们生活在一个怎样的年代？人多，钱傻，速来 怎样办？天下武功，唯快不败 工程技术速度的考量 -要保证可持续的快快速推出新功能， 试错，验证后快速迭代改进快速扩张研发队伍， 模式初步验证后，加大资源投入架构快速水平扩张 当业务方向对，推广运营到位，互联网海量业务规模 3大纪律，8项注意如何保证可持续的快 技术选型的3大纪律大厂都在用自己搞得掂项目输得起 注意1：分治，SOA业务分而治之技术上：服务命名naming/自动发现register&discovery/治理（负载均衡，柔性服务）各个服务封装功能和数据，把接口以ip+port暴露出来工程考虑：作为研发和部署的单位，加人方便、独立研发演进、降低复杂度、米聊的技术实现： 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的概念，不会做比如join我们的实现:数据库：一开始就按uid分表分库，做垂直和水平分割，用DAL屏蔽服务用uid range分割 Memcached等用一致性hash 注意6： 服务无状态服务要设计成无状态，可以被”kill -9 ”工程考量：可以在线升级可以提供多个实例作为冗余，提高可用性和负载均衡我们的实现:服务内部无状态，通过cache或者数据库共享状态客户端通过zookeeper发现服务的多个实例，负载均衡，并且实现出错fallback机制 注意7： 架构上要支持灰度升级快速开发过程中，要有工程考量：快速开发，错误难免，避免全站影响可做业务比较，尤其让内部员工dogfood最新功能可打不同程度的流量和做dark launch我们的实现:前端快速接入，不含/少含业务逻辑业务通过前端后，根据ip/白名单/参数里uid/cookie得到相应的服务partition uid白名单定义preview partition给内部员工服务基于uid range定义一系列的partition做灰度，诸层次的升级 注意8： 一开始就要考虑安全机制用户身份认证/授权/数据泄露/防篡改工程考量：避免见光死 Q&A 我们正在招聘