Medium服务架构分析

  Medium 是一个轻量级内容发行平台，允许单一用户或多人协作，将自己创作的内容以主题的形式结集为专辑（Collection），分享给用户进行消费和阅读。

Medium目前累计的用户阅读时间已经超过14亿分钟，合连钱六百年。支持者每个月两千五百万的读者以及每周数以百万的文章发布，必定有一个强大而又完善的机构体系！下面我将就我个人观点谈一谈Medium所使用的架构的优缺点。

架构体系

原始架构

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

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

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

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

 由上述架构来看,Mdeium选择了最稳妥的架构，这个架构适合刚刚起步的互联网公司，基本所有互联网公司都能使用，也加上内容分发特有的多节点，特有的图片处理节点，不过变通一下，还是可以用到很多网站上的。

当前架构

  相对于原始架构，从上面的服务架构图你可以看出，要比之前的架构复杂得多，虽然Medium表面看起来很简单，但是了解其后台的复杂性后，你会大吃一惊。有人会说，**这就是个博客啊，用Rails之类的一周就能搞定了。**那你就大错特错了，闲话少说，一起来分析一下。

>当前运行环境

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

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

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

  没有仅仅使用**Node.js**还用**Go语言**做了一些辅助服务。

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

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

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

 相对于原始架构，一套通用架构来说，现有架构改动很大，可以说这个架构就是为了Medium量身定做的，而且在主体使用Node.js使用Go语言辅助来说，是一个很好的选择，相比Java语言的冗长罗嗦和虚拟机，Go语言在类型安全方面做的很到位。

>数据库

  DynamoDB仍然是主力数据库，但是用起来也不是毫无问题。目前遇到的比较棘手的是大V用户展开和虚拟event过程中的热键问题。Medium还专门在数据库前面做了一个Redis缓存集群，来缓解这些问题。
  目前开始在存储新数据上使用Amazon Aurora，它可以提供更灵活的查询和过滤功能。

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

 对于数据库来说，一开始就没有选用关系型数据库来做项目，开始就选用了非关系型数据库来做，一是因为项目本身来说，Amazon DynamoDB是一个完全托管的NoSQL数据库服务，可以提供快速的、可预期的性能，并且可以实现无缝扩展，可以更好的进行管理，二是非关系型数据库本身的有点，数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。但是在数据库协同的时候还是会出现一系列问题。

>数据平台

  采用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的持续缓存。图片的处理是请求来触发的。这给了我们的架构设计师灵活改变图片展示的自由度，为不同平台优化，而且避免了大量的生成不同尺寸图片的操作。文本标注是个有意思的功能，用了一个小型Go服务器，跟PhantomJS接口形成渲染进程。

我一直想要把渲染进程换到Pango，但是在实践过程中，能在HTML中摆放图片的能力的确更灵活。而从功能的使用频率来看，这意味着更容易开发和管控。允许用户为其Medium文章设置个性化域名。在网站前端来说，使用自主研发的单网页应用框架，使用Closure标准库。

总结：

Medium从最初的简单通用架构到现在非常细化的架构可以看出他为什么成功，这也离不开强大的IDC运营商支持，目前的架构来说，虽然还是出现了一定的问题，但相对来说，还是一个非常不错的架构，（适用于特定的内容分发平台）。