linkedin解封_LinkedIn信号：Scala，JRuby和Voldemort的案例研究
linkedin解封
9月29日， LinkedIn Signal被宣布 ，它提供了一种社交搜索应用程序，用于LinkedIn股份和来自LinkedIn-Twitter受限帐户的推文。 本文旨在就这种规模的Scala，JRuby和Voldemort的组合的动机和技术挑战提供更多见解。
LinkedIn搜索架构师John Wang发布了整个系统的架构概述 ：
Scalatra后端是在Sinatra框架上用Scala编写的RESTful服务。 选择REST / JSON RPC模型可进行快速的临时数据处理，以实现快速迭代。
出于快速迭代的原因，也选择了使用JRuby前端 。
用于方面装饰的数据相当静态且很小，我们只是将BDB实例放在服务抽象的后面。
保存的搜索和关注是我们后来在开发中想到的功能。 我们想要立即运行的东西肯定具有可伸缩性和弹性。 由于我们的查询访问模式非常适合键值存储，因此Voldemort成为显而易见的选择。 此外，Voldemort的数据重新平衡和弹性功能在预期数据增长方面至为重要。
数据流是LinkedIn份额，来自受限帐户的推文，LinkedIn个人资料和会员衍生信息的集合。 这是建立在我们的分布式消息传递队列上的。
实际搜索系统的实施似乎是新服务最具挑战性的部分。 在那里，该团队不得不利用LinkedIn的Search，Network和Analytics团队的一部分产品，例如：
- Apache Lucene ，用于文本搜索，
- Zoie ，用于实时索引，
- Bobo ，用于多面搜索和
- Sensei ，具有动态聚类的分布式实时可搜索数据库
除了有关如何配置，集成和扩展自定义软件的这些产品的详细信息之外，John还描述了本文排名算法的工作原理：
经过几次迭代后，虽然系统在负载下似乎保持良好状态，但是那时候我们注意到我们受到了垃圾邮件发送者的影响。 一个简单的例子是，个人通过将给定网址“共享”数千次来进行自我提升。 当我们使用的计分方案过于强调股票数量时，它只是在影响着我们。 简而言之，仅基于共享的受欢迎程度指标不足以进行排名。
共享垃圾邮件的一种直观解决方法是尝试确定给定文章在整个共享池背后的唯一身份人数。 从某种意义上说，该算法还应该根据共享它的唯一个体的数量来推广文章，并降级被单个个体公开多次共享的文章。 现在的结果太棒了！
InfoQ与负责LinkedIn信号部署的人员联系，以获取有关其项目的更多信息：
InfoQ：您如何在前端使用JRuby？ 通过一些特定的框架？
Alejandro Crosa（JRuby / Scala专家@ LinkedIn）：当前，前端层非常薄，为我们提供了诸如会话状态，模板化以及后端服务和REST api的更高级别抽象之类的功能。 之所以选择JRuby，主要是因为它给了我们三点重要的东西：具有快速开发和测试时间的灵活表达代码，易于Java集成以及能够利用两个世界的库的能力。 我们正在使用的Web框架是Sinatra，因为我们要做的就是为应用程序提供一个非常简单的简约REST界面。
InfoQ：您的前端有多少是Scalatra，还有多少JRuby？ 为什么您发现它们的组合比仅使用其中之一更有价值？
Alejandro Crosa： JRuby仅用于公共API和前端功能。 另一方面，Scalatra用于以干净的RESTful方式公开后端API。 这就是我们为应用程序重复的模式，使用针对特定作业的最佳工具构建服务，并将其包装在干净的RESTful API中。
另外，由于后端完全与性能有关，我们不想对解释代码付出任何代价，因此迭代频率与前端不一样，而Scala的类型系统在构建后端服务时非常乐意使用。 通常，我们不考虑问题的范围（行业耻辱）而使用相同的工具，而是选择我们认为最适合该特定要求的内容，然后在上面添加一些REST构成。
InfoQ：在LinkedIn上积累了丰富的Scala经验之后，对于正在考虑采用Scala的团队，您有何建议？ 常见的陷阱是什么？它们如何将其融合到现有的Java基础结构中？
Alejandro Crosa：来自Ruby世界，我看到了该语言中的许多相似功能，其中一些确实很有吸引力。 Scala最近被认为过于复杂，但是实际上，该语言的核心非常简单，您可以选择要使用哪些功能，哪些不需要。 您可以编写非常简单的简约代码，也可以编写极其难以阅读的内容，这是开发人员的决定。 它确实可以在开发人员级别扩展。
对于常见的陷阱，我认为彻底拥抱它是一个错误，特别是在Java中有很多旧代码的情况下，而是找到令人信服的理由来说明为什么迁移到它，并将其应用于Scala擅长的特定领域问题，如果您像使用Java一样使用Scala，那么您将获得更简洁的语法，除此之外别无其他。 拥抱不变性，功能数据结构，模式匹配，Actor等，您将永不退缩。
克里斯·康拉德（Chris Conrad）（斯卡拉专家@ LinkedIn，诺伯特的创造者）：在很大程度上，我完全同意亚历杭德罗的观点。 Scala是一种出色的编程语言，可提供一些非常强大的构造。 但是，如果您只是要使用Scala语法编写Java，那么您就不会物有所值。
对于我来说， 诺伯特（Norbert）是一个很棒的项目，需要在Scala中实施。 由于它是一个很小的自包含项目，因此我能够花一些时间尝试使用Scala的各种功能，以找出表达所需的API的最佳方法。 而且由于Scala与Java紧密紧密地集成在一起，因此我能够提供一个干净的，特定于Java的API，允许Java开发人员使用Norbert。
对于其他希望开始使用Scala的人，我的建议是找到一个小的自包含功能，供他们在项目中进行试验。 学习如何有效利用Scala可能会花费一些时间，并且您不希望通过尝试在Scala中实现关键部分来破坏项目的稳定性，直到您了解了这一学习过程。 通过利用Scala / Java集成，您可以在Scala中实现这一部分，而组织的其余部分则无需学习Scala，直到他们准备好为止。
关于陷阱，我认为最常见的与Scala的面向对象/功能的混合特性有关。 程序员将需要花费时间，学习何时使用对象对程序进行建模，何时使用函数对程序进行建模以及如何将两者结合在一起。 就个人而言，在编写Norbert时，由于我对使用Scala变得更加自在，所以我不得不回头多次重新编写一些代码。
InfoQ：同样，对于正在考虑使用键值存储的团队，您有何建议？ 由于Voldemort是一个相当新的系统，可能会有一些粗糙的边缘，因此在采用之前应考虑哪些方面？
Jay Kreps（Voldemort的作者）：的确，按照数据库的标准来说，它是相当新的，我认为它大约需要5到10年才能成熟。 我认为，任何基础架构的可靠性实际上都是软件，工程师对其进行编程以及运行该软件的操作专业知识的结合。 新基础架构的一些问题是软件问题，但是许多（我会说最多）是用户和操作员缺乏知识。 MySQL的优点不是没有任何问题，而是使用它的人很好地理解（并避免了）这些问题。
在这方面，Voldemort在LinkedIn上并不是一个新事物，自2008年底以来，我们一直在生产中使用它。
但是，我认为对Oracle进行的任何更改都要经过的质量保证周期是如此完整和严格，以至于任何开源技术都不可能在软件可靠性上展开竞争。 新来者只能在性能，可扩展性和价格上竞争。 但是，扩展的常见解决方案是在数据库（无论是MySQL还是Oracle或其他任何数据库）之上引入一个自定义的分片层。 一旦执行此操作，您将在混合风险中拥有足够的自定义软件，您肯定处于同一风险区域。 因此，与自定义分片实现相比，我确实认为Voldemort的设计更好，测试更好并且总体上更稳定。
Alejandro Crosa： Jay回答得很好。
我可能会从用户角度补充说，从所有选项（大多数都是相当新的）来看，我认为Voldemort是在稳定性和功能集方面最强大的选项，我所看到的唯一问题是采用，因为在功能列表上，它堆叠得非常高。 例如，存储层是可插拔的，这意味着您仍然可以使用MySQL的存储和投资并获得Voldemort提供的所有功能。
您可以在InfoQ上找到有关JRuby ， Scala ， Voldemort和Scalatra的更多信息！
linkedin解封