新闻动态

完善的7*24小时服务,携手共赢,共同成长

首页 新闻动态云计算文摘 正文

必读的16篇最新分布式系统论文

2016-01-15 15:01:14   
 
IT 技术领域一日千里,如果你不去读这个领域的最新论文,落后是迟早的事。今天就为大家推荐了16篇分布式计算领域的最新论文。从中可以发现该领域学术界和企业界的密切联系,多篇论文都来自 Facebook 和 Twitter。所以,本期还推荐了Twitter 华人高级工程师郭斯杰的 Twitter高性能分布式日志系统架构解析;其后是微博基于 Docker 实现的混合云架构,可以在5分钟内实现的业务水平扩容。Docker 是实现微服务的不二选择,我们还会带大家了解 Google 和 eBay 在微服务生态系统建设上的进展。最后,很多人都在好奇:神秘的 SpeedyCloud 创业团队到底都长啥样子?我们会带你跟他们面对面!
 
想了解分布式系统的最新发展?只需读完这16篇论文
在计算机科学和工程领域,学界和企业界常常互相促进,彼此学习。因此,阅读论文就成为了解学科发展和业界最新学术动态的最佳途径,很多知名 IT 公司的开源项目就来自于这些论文。

Murat Demirbas是美国水牛城大学计算机科学与工程学院的教授,主要研究分布式网络系统和容错系统。他列出了2016年春季学期学生应读的领域论文,一共16篇,分领域列表如下,其中多篇来自 Facebook。

分布式协调: 大数据: 监控: 形式化方法:
 
【精彩声音】:

当你查看基于容器的虚拟化带来的好处时,最大的好处,就是它可以把越来越多东西塞到一个硬件中,这样能降低成本。虽然这么做对预算有好处,但一旦出问题,事情就会变得不可收拾。(来自 Brian Kirsch
 
 
Twitter高性能分布式日志系统架构解析
本文来自 Twitter 高级工程师郭斯杰,他是 Twitter 分布式日志系统 DistributedLog/BookKeeper 的主要技术负责人,同时也是 Apache BookKeeper 项目的 PMC Chair。

文中,郭斯杰首先分析了为什么需要分布式日志——因为可以以之解决强一致性操作可能存在的冲突问题。接下来,他分享了 Twitter 对于分布式日志系统的处理方式——基于Apache BookKeeper构建DistributedLog。最后,他还讲述了相关的案例,并回答了与该分布式日志系统架构有关的常见问题。 

金句:  

日志已被证明是一种很有效的数据结构,可用来解决很多分布式系统的问题。
在一个“完美”的世界中,系统应该只有两种负载,writes 和 tailing reads。而且大部分现有系统对于这两种负载可以很好地应付。但是,在现实世界里,这基本不可能。尤其在一个多租户的环境里,catch-up reads 通常成为影响系统的重要因素。

标签:高性能、日志、Twitter、分布式
阅读原文
 
【精彩声音】:

为什么我需要更强大的 PC 来使用虚拟现实?比起 PC 游戏,虚拟现实提供的沉浸式体验需要强大7倍的处理能力。(来自Kyle Russell
 
5分钟内实现水平扩容——微博基于Docker的混合云平台设计与实践
虽然大家都说微博已经日薄西山,但根据微博研发中心运维架构师王关胜提供的最新数据,微博目前有 8 亿注册用户,单日活跃用户数达 1 亿多;每日超过 600 亿次 API 调用,超过万亿的 RPC 调用,产生的日志就达百 T+。如此庞大的系统,对于运维的要求极其严格:接口层SLA 必须达到 4 个 9,且接口平均响应时间不能高于 50ms。

此外,技术团队还面临如下挑战:
  • 产品功能迭代快,代码变更频繁
  • 业务模块多,且依赖关系复杂
  • 突发的热点事件,如典型的#周一见# #马航370# #刘翔摔倒# #明星丑闻#
  • 大型活动及春节、元旦保障,如红包飞
除了业务扩容的繁琐,公司内设备利用率也不均衡,主要表现在三个地方:
  1. 各个业务组的服务器利用率各不相同,大家对利用率的理解不一致,导致有些设备未能得到充分利用,这也会导致更大的成本压力。
  2. 各个业务模型不同,比如有的业务高峰是在晚 22 - 23 点,有的业务则在中午。
  3. 在线业务与离线业务完全分离,导致成本也高,对于离线业务,可在低峰继续跑在线业务。
为了应对这些挑战,微博技术团队基于 Docker及公有云构建了一套具有弹性伸缩的混合云系统。

接下来,王关胜提到了构建Docker Container 平台基础架构的 3 大关键模块:
  • Docker 在裸机上的部署架构
  • 改进版的 Docker Registry 
  • 负载均衡组件 Nginx Upsync 模块
王关胜还详细讲述了架构的设计思考和技术细节,最终实现的效果是:每次水平扩容时间低于5分钟。

金句:  

内部私有云设备安全性高,可控度也高,只要对硬件资源进行优化配置,用它来处理固定的工作负载。而公有云的设备则具有标准化,自动化的特性,可以快速因临时需求,在流量暴涨时,可以快速创建大量 ECS,扩容业务工作负载的能力。而对于公司,可以利用公有云这种按需付费的机制,减低硬件的运营成本。因此采用混合云架构,就可以兼具私有云及公有云的优点,可以同时拥有安全与弹性扩容能力,使业务工作负载可以在业务间进行漂移,低负载的业务就应该使用更少的设备,反之亦然。而基于 Docker 来做,对于上述情况来说,复杂度降低很多。

标签:Docker、混合云、业务扩容
阅读原文
 
【精彩声音】:

除非你开始真正尝试运行大量服务,否则你就无法体会到容器在效率方面难以置信的提升。(来自 Craig McLuckie
 
Google和eBay构建微服务生态系统的经验
2016年初,谷歌回归的呼声日益高涨,而越来越多的大型企业如亚马逊、Google和eBay等,其架构体系逐步演变为大规模多语言微服务生态系统。近日,曾任Google和eBay高级职务的RandyShoup分享了Google和eBay在构建微服务生态系统的经验,包括如何创造、使用和保护大型架构体系。

Randy首先介绍了大规模多语言微服务生态系统,并列举了eBay、Twitter及Amazon的架构演变史;其次讲述了如何构建服务生态系统,并指出没有架构师如何进行变革及定义标准是什么?还说明了创建新服务和弃用旧服务的情况;最后则介绍了服务负责人的目标、不同服务的合作模式及反模式服务。

全文围绕了去中心化的分布式微服务系统,提出了统一奖励机制的战略,并根据不同阶段提出了许多问题:如何进行多语言的协同合作?如何设计自下而上的大型架构体系?如何建立服务责任者的目标体系等.....值得大家借鉴与思考。

金句
  • 现代大型系统以关系图组合服务,而不是按层次体系或等级制度。 运行良好的系统是适应时代的不断变革的产物,
  • 处于变革的环境中,标准是强制执行的:编码、提交、代码审查和代码检索。
  • 鼓励实践的最好方式是用实际代码说话。
  • 不同服务之间独立运转又相互依赖。一个服务只有在不断的提供价值、不断被使用的情况下,才能避免被淘汰的命运
  • 在一个成熟的服务生态系统中,标准化的应该是图的弧度,而不是节点本身。
  • 服务责任者目标应以最小的代价和努力满足客户需求。
  • 操作大规模服务系统,性能的可预测性比平均性能重要得多。
标签:微服务、大型架构、服务、性能
阅读原文
 
SpeedyCloud创始团队神秘揭晓
不失江湖本色的销售女王、卖萌的销售VP、暖男代言人兼COO、睥睨众生的首席架构师、骨骼轻奇的研发总监、全程耍帅的 CEO……SpeedyCloud 创业团队首次公开亮相,进来看看吧。
 
阅读原文
 
关注SpeedyCloud官方微博
掌握最新动态和优惠
扫描SpeedyCloud官方微信
获取价值50元免费云主机
欢迎发送邮件到social@speedycloud.cn,聊聊你对于“SpeedyCloud云计算技术文摘”的想法和建议,也欢迎你说出对于SpeedyCloud迅达云成公司的意见和看法。

*|FORWARD|*