|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
令人可喜的是java现在已经开源了,所以我想我上述的想法也许有一天会实现,因为java一直都是不断创新的语言,每次创新都会给我们惊喜,这也是我喜欢java的一个原因。Serendip.me的前首席架构师RotemHermon撰文先容了始创音乐服务Serendip.me在架构及扩大方面所思索的内容。
Serendip.me为人们供应交际音乐服务,匡助人们发明伴侣们分享的优异音乐,并为他们先容“知音”-那些接近他们的交际圈子,有类似音乐咀嚼的生疏人。
Serendip运转在AWS之上,接纳了以下这些手艺:scala(另有一些Java),akka(用来处置并发),Play框架(Web和API前端),MongoDB和Elasticsearch。
手艺栈的选择
Serendip的次要功效是从大众音乐服务中搜集Twitter上分享的一切音乐,以是它必要处置大批的数据,以是Serendip在选择言语和手艺时,起首要思索它们的扩大才能。
由于JVM久经磨练的功能和工具,而且另有良多接纳这门言语开辟的开源体系(好比Elasticsearch),以是他们选择JVM作为体系的基石。
而在JVM的系统中,scala又锋芒毕露,成了一个风趣的选择。Scala能够用古代的体例写代码,又能够跟Java周全互通。别的另有一个很主要的缘故原由,akkaactor框架长短常符合的流处置基本举措措施(相对是!)。方才入手下手盛行起来的Play框架看起来也很不错。Serendip入手下手于2011岁首,事先这些都长短常前沿的手艺。到了2011岁暮,scala和akka兼并成Typesafe,Play也在不久以后到场。
选择MongoDB是由于它对开辟者友爱,易用,功效集和大概的扩大才能(接纳了主动分片手艺)。但由于Serendip利用和查询数据的体例必要在MongoDB上创立良多年夜索引,而如许会很快激发功能和内存方面的成绩。以是他们次要是用MongoDB存储键-值文档,另有几个必要计数器的功效依附于它的原子增加。
现实证实,如许利用时MongoDB十分可靠。还简单操纵,但次要是由于只管制止利用分片,而且只要一个复制集(MongoDB的分片架构相称庞大)。
查询数据必要一个完整成熟的搜刮体系。在开源的搜刮办理计划中,Elasticsearch是扩大性最强,而且面向云真个体系。它有静态索引机制,还供应了良多搜刮和切面的大概性,能够在其上构建良多功效。因而,Elasticsearch成了serendip架构中的一其中心组件。
Serendip决意本人办理MongoDB和Elasticsearch,次要有两个缘故原由。第一,Serendip要完整把持两个体系。不想在软件的晋级/升级上依附于别的元素。第二,由于serendip要处置大批数据,接纳托管计划要比他们间接在EC2上本人办理高贵很多。
一些数字
Serendip的“抽水泵”(处置Twitter公家流和Facebook用户定阅源的那部分)天天要消化也许5,000,000条信息项。这些信息项要经由一系列的“过滤器”,对它们举行检测,并剖析出受撑持服务(YouTube、Soundcloud、Bandcamp等)上的音乐链接,还要增加一些元数据上往。抽水泵和过滤器是akka的actor,而且全部历程是用单个m1.largeEC2办理的。假如必要,能够用akka的远程actor将义务分发到集群中,轻松完成体系扩大。
从这些信息项中,Serendip天天也许能失掉850,000条无效的信息项(也就是真的包括相干音乐链接的信息项)。这些信息项在Elasticsearch中索引(还要在MongoDB中备份并延续计数)。由于每条无效的信息项都要更新几个对象,以是在Elasticsearch中的索引率约莫为40条/秒。
Serendip在Elasticsearch中保存一个月的信息项索引(微博和帖子)。每月的索引也许包括25M信息项,有3个分片。集群运转着4个节点,每一个都在m2.2xlarge实例上。这个设置有充足的内存运转Serendip所需的数据搜刮。
Serendip的MongoDB集群的操纵频次也许是100次写/秒和300次读/秒,由于它处置更多的数据范例、手艺和统计数据更新。复制集的主节点跑在一个m2.2xlarge实例上,副节点在一个m1.xlarge实例上。
构建定阅源
在计划Serendip主音乐定阅源的架构时,想让定阅源是静态的,而且能够依据用户的举措和输出作出反响。好比说,假如某位用户将一首歌标为“摇滚”,或将某位艺术家标为“趾高气昂”,那末这些举措应当即刻反响到定阅源上。假如用户“不喜好”一名艺术家,那今后就不该该再播放那些音乐。
而且这个定阅源应当是几个泉源的组合,好比伴侣分享的音乐,喜好的艺术家的音乐,和有不异音乐咀嚼的“倡议”用户分享的音乐。
这些需求意味着那种“fan-out-on-write”式的定阅源创立体例大概其实不符合。应当及时构建定阅源,把跟用户相干的一切旌旗灯号都用上。Elasticsearch的功效能够构建出这类及时的定阅源天生器。
定阅源算法有几种选择信息项的“战略”,在每次定阅源的猎取上都依据分歧的比率静态组合。每一个战略城市思索到用户比来的举措和旌旗灯号。战略的组合被转换成几种对新鲜数据的搜刮,这些数据是不休地由Elasticsearch索引的。由于这些数据是基于工夫的,而且索引每个月创立一次,以是只必要查询全体数据中的一小部份子集。
Elasticsearch十分擅于处置这些搜刮。它还供应了一种扩大这类架构的出名路径-经由过程增添分片数目扩大写操纵。经由过程增添更多的复制和物理节点扩大搜刮。
寻觅“知音”的历程(依据用户的音乐咀嚼举行婚配)充实使用了Elasticsearch的切面(聚合)才能。作为延续不休的交际流处置的一部分,体系经由过程盘算顶级分享的艺术家来为它碰到的交际收集用户筹办数据(在他们分享的音乐上利用切面搜刮)。
当Serendip用户给出一个旌旗灯号(播放音乐或跟定阅源交互)时,它能为那位用户从头触发一次知音盘算历程。这个算法依照喜好艺术家(这个是不休在更新的)列表来寻觅婚配水平最高的其他用户,并用一些分外的参数作为权重,好比盛行水平、分享次数等。然后再用另外一组算法过滤失落渣滓邮件发送者(是的,有音乐渣滓邮件发送者)和非常值。
理论证实,这类处置能得出很好的了局,其实不必要再用一套体系来运转加倍庞大的聚类或保举算法。
监测与部署
Serendip用ServerDensity做体系监测和报警。关于始创公司而言,它是一种易于利用的托管计划,有像样的功效集和公道的代价。ServerDensity原生供应了服务器和MongoDB的监测。Serendi还大批利用了它呈报定制目标的才能来呈报外部体系统计数据。
外部统计数据收罗机制卖力收罗体系内产生的一切举措,并把它们保存在一个MongoDB汇合内。一个按期义务每隔一分钟从MongoDB中读取一次这些统计数据,并呈报给ServerDensity。如许就能够用ServerDensity对Elasticsearch及运营数据举行监测和报警。
市场分额,java比asp高一点,因为C#是仿照java开发的,所以哦C#能做的java都能做到,但是java能做的,C#不一定都能做到。毕竟是抄袭吗。 |
|