从Java到Clojure,大量使用NoSQL和云,MixRadio只为高效

以下为译文

　　MixRadio提供了一个免费的音乐流服务，通过学习用户的收听习惯以交付一个定制化的电台，而用户需要做的只是去点击一些简单的按钮。通过极其简易的交互，MixRadio通过“移动优先”的方式提供了一个难以置信的定制化等级。它适用于任何人去发现新的音乐，不只是狂热的音乐发烧友。使用MixRadio就像打开一台收音机，但一切都在你的掌握之中——轻点Play Me，你的私人广播电台随之开启。基于地域流派和风格，MixRadio包括了数以百计的手工歌单、创建歌单功能，当然不能缺少保存喜爱的歌单并离线播放，这样即使没有互联网，美妙的音乐仍然可以继续。

　　当下服务已经在Windows Phone、Windows 8、Nokia Asha以及Web上可用，而支撑这些应用的后端系统则经过了数年的打磨，下面我们一起看看系统的架构概括。

架构综述

　　在2009年，我们如愿获得了重构后端系统的机会。而衍变到现在，后端系统已经由一系列RESTful服务组成，也就是大家经常说的“Microservices”。这些系统的功能、大小、开发语言、数据存储都各不相同，然而有一些共性是必不可少的，比如一些良好定义的RESTful API、独立扩展、监视能力。围绕这些核心服务，系统还拥有两个相似的代理服务，通过配置以提供RESTful资源的子集，它们被用于不同功能。“Internal Tooling API”代理服务器拥有内部API以提供客户服务、内容管理、歌单发布、监视以及其他场景使用的工具，客户端应用及第三方开发者使用的 RESTful API通过“External API auth layer”开放，这个服务同样负责执行适当的许可权限以及授权方案，比如OAuth2。

　　对于终端用户，通过API服务的应用程序范围非常广。我们提供了独立的HTML5网站、以及适用于Nokia电话和搭载Windows 8系统的设备应用，同时我们还开放部分相同的API给第三方开发者。下面我们不会公布过多的系统架构细节，如果想有更多详细了解可以查看我同事Nathan之前发布的文章。我们将对系统主要部分进行高度综述，下图显示了系统中由50多个Microservices构成的组件：

使用的技术

　　基于开源，我们务实地选择合适的工具以完成任务，下面一起看系统中重度使用的技术堆栈：

语言

• Microservices使用Clojure开发
• 设备应用和Media Delivery服务使用C#开发
• Web端则使用了HTML5、CSS和JavaScript

存储

• MySQL
• Solr
• MongoDB
• Redis
• Elasticsearch
• ZooKeeper
• SQLServer

基础设施

• Linux Microservices使用了AWS
• 媒体存储和运行在Windows上的媒体服务使用Azure
• GitHub Enterprise用于源码控制
• Packer用于建立机器镜像
• Puppet用于服务开通和主机镜像检查

监视

• Nagios
• Graphite
• Tasseo
• Seyren
• Campfire
• PagerDuty
• Keynote
• Logstash
• Kibana

架构原则

　　为了保持50多个Microservices API的一致性，我们在URL、结构、分页、排序、包装、语言代码等处理上都制定了标准；但是在一个开放的文化下，我们通常使用原则而非硬性规定来保持一致性。我们的服务需要遵循以下的条款：

• 松耦合、无状态，并且在HTTP上提供JSON RESTful接口。
• 独立部署并拥有自己的数据，也就是其他服务通过API访问数据，而不是数据库连接。这在持久性技术及数据结构改变时，服务仍然可以独立扩展。
• 不能太大，因为臃肿；不能太小，因为会浪费资源；我们为每个服务都使用了独立的主机实例。
• 实现健康检查API，用于监视和确定健康状态。
• 永远都不要破坏消费链。我们在早期就遵循在资源路径中添加版本号的标准（比如/1.x/products/12345/），这样一来，如果必须做破坏性改变，新的版本可以同时部署，并为上流消费者使用。尽管当下我们仍然保留了这个能力，但是已经数年未用。

　　遵循这些内部原则，对于外部公开API，我们有一些附加标准：

• API遵循移动优化：我们使用JOSN，因为在低性能设备上，对比XML，它只需要耗费很少的内存去解析；只要有可能，响应回应使用 GZIP编码，最重要的是，如果不需要，就不会返回数据。最后一点是对API一致性一个很好的平衡。
• 尽可能的使用缓存：API返回适当的缓存标头，这样一来，内容就可以在终端用户设备或浏览器上缓存，同时，我们还使用内容分发网络（CDN）来让内容离消费者尽可能的近。
• 尽可能多的在云中托管逻辑与数据，从而最大化减少应用中的逻辑副本并交付一个一致性体验。
• 第三方子集、Web、移动以及桌面客户端使用相同的API。然而，为了适应不同需求和屏幕大小，我们使用了大量的技术。举个例子，我们经常使用“itemsperpage”查询参数来调整返回内容数量；另一个关于RESTful API设计就是资源返回隔离的内容。内容经常被聚合到我们称为“views”的容器中，这样可以减少请求的数量。

　　使用视图API的一个例子就是应用中艺术家详情分页，数据从多个源中抽取——艺术家个人简介、图片、推特、gigs（混合了风格、热门歌曲、朋友听过的歌曲、相似的艺术家）。通过将这些集合到“view”中，应用每次都可以获得5千字节左右的数据。