架构细节 | 看看 Medium 的开发团队用了哪些技术?

说到底,Medium是个社交网络,人们可以在这里分享有意思的故事和想法。据统计,目前累积的用户阅读时间已经超过14亿分钟,合两千六百年。

我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据,而是观点取胜。在Medium,文章的观点比作者的名头更重要。在这里,对话促进想法,并且很看重文字的力量。

我是Medium开发团队的负责人,此前在Google工作,负责开发Google+和Gmail,还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。

团队介绍 说起团队我非常自豪,这是一群富有好奇心而且想法丰富的天才,大家凑到一块是想做大事的。

团队以跨功能的任务驱动,这样每个人既可以专攻,又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多,对团队的锻炼越大。更多关于团队的理念见此。

在工作组织方面,我们有着很大的自由度,当然作为一个公司组成,我们还是有季度目标的,并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪,用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同,我们是Slack和slack机器人的重度用户。

原始架构 最开始的时候,Medium部署在EC2上,用Node.js实现,后来公测的时候迁移到了DynamoDB。

其中有个节点用来处理图片,负责将复杂的处理工作转向GraphicsMagick。还有一个节点用作后台的SQS队列处理。

我们用SES处理邮件,S3做静态元素服务器,CloudFront做CDN,nginx作为反向代理,Datadog用来监控,Pagerduty用来告警。

在线编辑器用了TinyMCE。上线之前我们已经开始使用Closure编译器以及部分的Closure库,但是模板还是用的Handlebars。

当前架构 虽然Medium表面看起来很简单,但是了解其后台的复杂性后,你会大吃一惊。有人会说,这就是个博客啊,用Rails之类的一周就能搞定了。

总之,闲话不多说,我们自底向上介绍以后再做判断。

运行环境 Medium目前运行在Amazon虚拟私有云,使用Ansible做系统管理,它支持配置文件模式,我们将文件纳入代码版本管理,这样就可以随时回滚随时掌控。

Medium的后台是个面向服务的架构,运行了大概二十几个产品服务。划分服务的依据取决于这部分功能的独立性,以及对资源的使用特性。

Medium的主体仍然是Node.js完成,方便前端和后端的代码共享,主要是文章编辑和发布这个过程。Node大部分时候不错,但阻塞event循环的时候会有性能问题。为了缓解,我们在每台机器上启动多个Node实例,将对性能要求比较高的任务分配给专门的实例。同时我们还深入V8运行时环境查看更加细节的耗时,基本上是JSON去串行化的时候的对象具体化耗时较多。

我们还用Go语言做了一些辅助服务。因为Go非常容易编译打包和发布。相比Java语言的冗长罗嗦和虚拟机,Go语言在类型安全方面做的很到位。就个人习惯来讲,我比较喜欢在团队内部推广强类型语言,因为这类语言能够提高项目的清晰度,不纠结。

目前静态元素大部分是通过CloudFlare提供的,还有5%通过Fastly,5%通过CloudFront,这么做是为了让两者的缓存得到更新,用于一些紧急的情况。最近我们在应用流量上也使用了CloudFlare,当时主要是为了防止DDOS攻击,但随之而来的性能提升也是我们愿意看到的。

我们使用Nginx和HAProxy做反向代理和负载均衡,来满足我们所需功能的维恩图。

我们仍然使用Datadog来监控,Pagerduty来告警。现在又增加了ELK(Elasticsearch、Logstash、Kibana)来进行产品问题调试。

数据库 DynamoDB仍然是我们的主力数据库,但是用起来也不是毫无问题。目前遇到的比较棘手的是大V用户展开和虚拟event过程中的热键问题。我们专门在数据库前面做了一个Redis缓存集群,来缓解这些问题。到底为开发者优化还是为产品稳定性优化的问题通常会引发争执,我们也一直在尝试中和两者的矛盾。

目前我们开始在存储新数据上使用Amazon Aurora,它可以提供更灵活的查询和过滤功能。

我们使用Neo4J存储Medium网络中实体之间的关系,运行在有两个副本的主节点上。用户、文章、标签和收藏都属于图中的节点。边则是在实体创建和用户进行推荐高亮等动作时生成。我们通过在图中游走来过滤和推荐文章。

数据平台 早期我们对数据非常渴望,不断尝试数据分析框架来辅助商业和产品决策。最近我们则是利用同样的框架来反馈产品系统,支持Explore等数据驱动功能。

我们采用Amazon Redshift作为数据仓库,为生产工具提供可变存储和处理系统。我们持续将诸如用户和文章等核心数据从Dynamo导入Redshift,还将诸如文章被浏览被滚动等event日志从S3导入Redshift。

任务通过一个内部调度和监控工具Conduit调度。我们用了一个基于断言的调度模型,只有条件满足的时候,任务才会执行。从产品角度来讲,这是不可或缺的:数据制造方应该与数据消费方隔离,还要简化配置,保持系统的可预见和可调试性。

Redshift的SQL检索目前运行不错,但我们时不时需要读取和存储数据,所以后期增加了Apache Spark作为ETL,Spark具有很好的灵活性和扩展能力。随着产品的推进,估计后面Spark会成为我们数据流水线的主要工具。

我们使用Protocol Buffers作为schema来确保分布式系统的各层次间保持同步,包括移动应用、web服务和数据仓库等。通过定制化的选项,我们将schema标记上更加细化的配置,如带有表名和索引,以及长度等校验约束。

用户也需要保持同步,这样移动端和网页端就可以保持日志的一致性了,同时方便产品科学家们用同样的方式解析字段。我们帮助项目成员从.proto文件中生成消息、字段和文档等内容,进而利用所得数据开展研究。

图片服务器 我们的图片服务器现在用Go语言实现,采用瀑布型策略来提供处理过的图片。服务器使用groupcache,是memcahce的替代品,可以帮助减轻服务器之间的重复工作。而内存级缓存则是用了一个S3的持续缓存。图片的处理是请求来触发的。这给了我们的架构设计师灵活改变图片展示的自由度,为不同平台优化,而且避免了大量的生成不同尺寸图片的操作。

目前Medium对图片主要支持放缩和裁剪,但原始版本中还支持颜色清洗和锐化等操作。处理动图很痛苦,具体后续可以写一篇文章来解释。

文本标注 文本标注是个有意思的功能,用了一个小型Go服务器,跟PhantomJS接口形成渲染进程。

我一直想要把渲染进程换到Pango,但是在实践过程中,能在HTML中摆放图片的能力的确更灵活。而从功能的使用频率来看,这意味着更容易开发和管控。

自定义域名 我们允许用户为其Medium文章设置个性化域名。我们想做成单点登录且HTTPS全覆盖,因此实现起来颇有难度。我们专门准备了一批HAProxy服务器用来管理证书,并向主要应用服务器引导流量。初始化一个域的时候需要一些手动的工作,但是通过与Namecheap的定制化整合,我们将其大部分转换为自动化。证书验证和发布链接由专门服务负责。

网站前端 网页端这块,我们有自主研发的单网页应用框架,使用Closure标准库。我们使用Closure模板渲染客户端和服务端,然后使用Closure编译器来缩减代码并划分模块。编辑器是我们网页端应用最复杂的部分,具体参见Nick此前的文章。

iOS 我们的两个应用都是原生的,尽量避免使用网页视图。

在iOS上,我们使用了一系列的自建框架,以及系统原生组件。在网络层,我们用NSURLSession发起请求,用Mantle解析JSON并映射到模型。我们还有一层基于NSKeyedArchiver的缓冲层。对于将条目渲染为共同主题的列表,我们有一个通用方法,这让我们能够快速为不同类型的内容构建新列表。文章界面是一个定制布局的UICollectionView。我们使用共享组件来渲染全文界面和预览界面。

应用代码的每一次提交都会编译后推送给Medium员工,这样我们能够很快尝试新版本。应用商店的版本是滞后于新版本的,但我们也一直在尝试更快的发布,虽然可能仅仅是几处小更新。

对于测试,我们使用XCTest和OCMock。

Android 在Android方面,我们与当前的SDK和支持库版本保持一致。我们并没有使用任何复杂的框架,而是倾向于为重复出现的问题构建持续性的模式。我们利用guava弥补Java中所有的缺失。另一方面来讲,我们也倾向于使用第三方库来解决特别的问题。我们还利用protocol buffers定义了API,用以生成应用中的对象。

我们利用mockito和robolectric。我们会开发一些高层测试来运转activity和poke:刚添加screen或要重构的时候,先创建一些基本的版本,随着我们复现bug它们也会进化。我们还会开发一些底层测试,来检测一个特定的类:随着新功能的增加我们会创建测试,这能够帮助我们思考和设计底层是如何交互的。

每个提交都会作为alpha版本自动推送到play商店,然后到Medium员工(包括我们的Hatch,Medium内部版)。推送大部分发生在周五,我们会把alpha版本发送给测试小组,请他们用整个周末进行测试。然后,周一我们会从beta版推进至正式产品版。因为最近一批代码总是随时可以推送,因此一旦发现很严重的bug,我们就可以立即修复正式产品版。当我们怀疑某些新功能的时候,可以给测试小组更长的时间。开发比较亢奋的时候,也可能发布地更加频繁。

AB测试以及其他 我们所有的客户端都用了服务器端提供的功能标记,称为variants,用于A|B测试以及指导未完成功能的开发。

剩下还有一些框架相关的内容我没有提及:Algolia让我们在搜索相关功能上快速迭代,SendGrid处理邮件,Urban Airship用来发送提醒,SQS用来处理队列,Bloomd用作布隆过滤器,PubSubHubbub和Superfeedr用作提供RSS等等。

编译、测试和部署 我们积极拥抱持续集成技术,随时随地准备发布,使用Jenkins来负责相关事宜。

我们曾经使用Make作为编译系统,但是后来迁移到Pants。

测试方面我们采用单元测试和HTTP层面功能测试两者结合的方式。所有提交的代码都需要通过测试才能够合并。我们跟Box团队合作,利用Cluster Runner来分布式运行测试,保证效率,而且能够和GitHub很好的整合在一起。

我们大概不到15分钟就可以把某阶段的系统部署,顺利编译通过,留作正式产品的备选。主应用服务器通常一天要部署五次,多的时候十次。

我们采用蓝绿部署。正式产品版本的流量发送给一个canary实例,发布进程会监控部署过程的错误率,必要时候通过调整内部DNS回滚。

未来 到此,讲了足够多的干货!为了重构产品,获得更好的阅读体验,还有很长的路要走。我们仍然在努力为作者和发布者设计更多的功能。打比方来讲,线上阅读还是一片绿地,面对它有着无限可能,我们始终抱着开放的心态设计和实现功能。未来我们会努力用各种功能为用户提供高质量内容和价值。

原文发布于微信公众号 - 服务端技术杂谈(ITIBB2014)

原文发表时间:2016-01-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏水击三千

数据库设计(一) 需求分析

目前,大多数的应用系统都属于数据库应用程序,都离不开数据库的支持。数据库设计方案的优劣对于应用程序的运行至关重要。数据库设计过程就是针对具体的应用环境,设计优化...

343100
来自专栏腾讯Bugly的专栏

《广研Android卡顿监控系统》

实现背景 应用的使用流畅度,是衡量用户体验的重要标准之一。Android 由于机型配置和系统的不同,项目复杂App场景丰富,代码多人参与迭代历史较久,代码可能会...

1.3K40
来自专栏SDNLAB

网络可编程与验证

作者简介:唐昊,现就职于华为,从事云网络研发工作。本文所有观点仅代表作者个人观点,与作者现在或者之前所在的公司无关。

30520
来自专栏安智客

Frequently Asked Questions on seL4

形式化验证是近年来安全操作系统发展的热门!seL4在其官网上打出的口号就是:安全不是表现不佳的借口!

22150
来自专栏机器之心

机器学习为核心,DeepMind助力谷歌开发的安卓 9「Pie」今日上线

今年 5 月份,谷歌 I/O 大会宣布推出安卓 9,而后经过数月的测试,谷歌收获了大量的反馈。此外,还有小米、Oppo 等 7 家设备制造商也将测试版本放到了他...

12010
来自专栏Golang语言社区

在 Go 语言中,正确的使用并发

Glyph Lefkowitz最近写了一篇启蒙文章,其中他详细的说明了一些关于开发高并发软件的挑战,如果你开发软件但是没有阅读这篇问题,那么我建议你阅读一篇。这...

44480
来自专栏Sign

creator创建小游戏子域排行榜

cocos官方有对应的子域接入教程: ? https://github.com/cocos-creator/creator-docs/blob/master/z...

99880
来自专栏企鹅号快讯

Python 开源项目 Top30 值得收藏

编译 | AI科技大本营 参与 | SuiSui 继推出2017年机器学习开源项目Top 30榜单后,Mybridge AI又推出了一个Python开源项目To...

478100
来自专栏CSDN技术头条

荔枝FM架构师刘耀华:异地多活IDC机房架构

声明:本文首发于CSDN,禁止未经许可的任何形式转载,可咨询文末的责编。 多机房架构存在的原因 ? 单机房一旦死机,断电、维护根本无法挽回整个数据,想离线读取等...

51960
来自专栏Android 开发者

Android P 开发者预览版首发!

26020

扫码关注云+社区

领取腾讯云代金券