让Microservices更快近年内，我们一直进行Microservices从Java到Clojure的重写。Cloujure是个静态语言，仍然运行在Java Virtual Machine（JVM）之上，允许访问Java框架。后端团队之所以会选择Cloujure，大部分原因是速度——不管是开发还是运行时。Cloujure比Java来的更为简洁，举个例子，有一个使用Java编写的Microservices在使用Cloujure重编写后，代码量从44000减少到4000行（包括所有配置、测试及组件）。我们使用Leiningen来加速开发，Leiningen提供的一个特性就是自定义项目模板来加速开发，我们拥有一个被称为“cljskel”的模板作为所有服务的框架模板。在后续文章中我们将详细介绍这个模板，而在使用方面，我们可以运行下面的命令，并获得一个功能RESTful服务，它将具备监视API： lein new cljskel <project name> 如果你感兴趣我们为什么会深入Clojure，你可能会对2013年两个工程师在London的演讲感兴趣。 数据我们有两个最大的数据源，分别是3200万+音轨的内容元数据（包括相关的艺术家、专辑、混合等）和来自应用程序的分析数据（比如回放、顶/踩以及浏览事件）。 Catalogue服务为消费者体验提供了内容元数据和搜索能力，Master Catalogue则存储来自多个数据源中的元数据，比如唱片公司、公司内部内容团队、以及类似维基百科这样的互联网资源。一个配置驱动的数据模型指定如何合并资源（比如基于内容团队在其他源中的更改对指定字段进行更新），这里的字段都可以被搜索并返回调用者。针对不同的用例，我们可以返回不同的字段。比如，有时候在搜索结果中我们并不需要一个节目列表清单，但是在显示曲目列表详情时我们则需要这个字段。Master Catalogue服务不会直接支撑用户流量，取而代之，“Search and Query”API则是其余后端系统的接口。Search and Query服务基于Apache Solr建立，Index Daemon则会抓取Master Catalogue用以修改并推送给Solr搜索索引。 在定制化体验、进行A/B测试、CRM、计算业务指标过程中，收集常用和分析数据至关重要。随着连续不断的数据从各种应用中传到后端，许多服务都需要对相同的数据同时访问。举个例子，当某个用户踩某首歌曲时，这对当下播放的曲目列表有着重要的意义，有助于对一个用户品位的把握，再三的重复踩这个动作意味着这个艺术家可能并不为用户喜欢。为了能处理预期的数据，我们确定了预期中订阅/发布系统所具备的特性：
我们选择了LinkedIn出品的Apache Kafka，因为它近乎完美地迎合了我们的需求。作为一个稳定的消息系统，它被设计用于支撑不同状态（比如读取数据的位置）的用户，而不是所有用户都是一尘不变的存在，并且以同样速度消费数据。 监视系统的目标是主要用例延时不超过0.8秒，以及在90天周期内4个9的可用性，相当于每个月停机4.3分钟。因此当错误发生时，我们要快速的发现并处理问题。在这里，我们使用了多个监视层来提醒开发和运维工程师。 最底层，我们使用Nagios来检查虚拟机的健康状况，并通过PagerDuty来提醒运维工程师。系统中，每个Microservices都会实现健康检查API，让AWS负载均衡器来确定某个主机是否需要被重启（在之前的报告中，你可以了解更多关于AWS负载均衡器的配置信息）。Graphite被使用以收集操作系统级度量，比如CPU使用率、磁盘空间等。同时，每个Microservices都会根据工程师需求记录对应度量。服务度量会在不同等级上进行，比如低等级的HTTP 500错误计数，以及高等级的抽象（被激活订阅数量），我们测量一切需要的信息。下面是Graphite可视化界面的一个截图： 在Graphite之上我们使用了Tasseo，它会提供一个更友好的数据总结视图；同时，在阈值变化时，我们使用Seyren进行提醒。Tasseo最早是由几个工程师引进，它曾被用于2012年奥巴马再次竞选时的系统。 在最高等级中，我们通过Keynote测量用例和全世界范围内的响应时间： 最终，为了做更详细的监测，我们避免必须通过日志传输来连接到特定服务器的情况。通过Logstash集中收集系统、请求、错误和应用程序特有日志，并且使用Kibana配合定制仪表盘来追踪特殊错误或者趋势。下面这个例子是我们几年前定制的仪表盘，目的是减少应用程序错误噪声： |
