-
消息平台
技术话题：LinkedIn如何重新设计其长达17年的消息平台？
微软的LinkedIn的第一条消息是在2003年5月5日服务推出当天发出的。
现在，LinkedIn消息平台存储了17年的消息（用17年不同的产品功能创建的），而且发送的消息数量不断上升。在过去的四年里，它翻了四倍，但在4月份的第一周，消息比前一年增长了14%；3月底，同事之间发送的消息每周都在跳跃（增长21%），用户在消息中互相发送LinkedIn新闻源的内容（增长14%）。
原本这些消息看起来很像电子邮件，现在看起来更像聊天，有线程、群组对话、表情符号和没有主题行。为该消息系统提供动力的代码一直在更新，变得越来越复杂，但为所有不同的LinkedIn消息体验提供动力的通用基础设施多年来并没有发生那么大的变化。
"虽然很少的代码，还存留在2003年，但很多基础架构还是一样的。"消息平台基础架构团队的工程经理Manny Lavery告诉New Stack。
最初的基础架构是一个Oracle数据库，运行在一个数据中心，有两个表为两个服务提供动力：一个用于存储消息，其中包括多个LinkedIn产品的所有消息业务逻辑，另一个负责消息的不同传递方式--推送通知、不同的电子邮件格式，以及跟踪它们的接收情况。
随着时间的推移，LinkedIn增加了新的数据中心，并改用自己的NoSQL JSON数据库Espresso，采用碎片化架构的分布式数据存储。不过，扩展带来了自己的复杂性；不同的邮箱被划分在不同的碎片之间，由个人数据路由服务跟踪谁的收件箱在哪个碎片上，双向复制将每个碎片的副本放到不同的数据中心，以防出现可用性问题。
2016年有一次重大的产品重新设计，LinkedIn不断增加更多的功能，最终改名为Messaging。但它仍然建立在为两个人之间的电子邮件式对话设计的数据架构上，使用的代码库已经超过十年，这使得它很难正确地对数据进行碎片化扩展，关键的业务逻辑仍然嵌入在消息存储的代码中。
解铃还须系铃人 Untangling the Mess
当LinkedIn的任何一个产品团队想要为消息传递添加功能时，基础设施团队都会参与其中--有时为他们编写代码或与他们一起进行开发--并负责在生产中维护所有这些新代码。但虽然他们拥有代码，但不同的产品团队却拥有业务逻辑、背后的理由以及对其进行任何修改的决策。
消息平台支持五个不同的LinkedIn业务线：消费者网站、为人力资源和招聘团队提供一种电子邮件消息的 "人才解决方案"、提供另一种电子邮件的销售解决方案、LinkedIn的营销解决方案和拥有高级消息选项的高级服务（加上其他一些内部客户）。所有这些产品都有自己的业务规则，如何处理它们在消息传递中的特定功能。
"所有这些业务用例都存在于一个单一的代码库中，消息团队负责长期维护，"Lavery告诉我们。"随着公司的扩张，17年来我们增加了更多的业务线，用例变得越来越复杂，用例也越来越多，这对我们的工程师来说真的很困难。没有人能够完全理解平台中发生的每一个业务用例。" 在重新设计之前，大约有六十种不同的定制业务逻辑。
基础设施的设计使得编写新的代码变得比需要的更难、更慢，开发人员对最简单的变化变得过于谨慎，因为团队越来越多的时间只是在维持事情的运行。"维护成本消耗了大部分的工程时间。"
由于担心新的架构可能会随着时间的推移成为同样多的维护负担，新的平台不仅仅改变了数据架构，将重点放在对话和内容而不是单个消息上。它还被设计成一个插件式的基础设施，服务所有权分布在基础设施和产品团队之间。
"我们开始对内容进行拆分，这样可以共享的内容就会被共享，不需要共享的内容就会被隔离到一个服务上，我们围绕着责任的所有权来设计我们的系统，然后用提供这些数据的数据库来备份这些责任服务。"
"我们确保我们可以作为一个平台来运作，与在我们身上执行的业务逻辑不可知。从我们的角度来看，消息只是内容，一旦你做出这个决定，很容易说'我只是要获取内容并为你存储，我要以你给它的完全相同的条件检索给你'，然后他们就可以按照自己的意愿呈现。"
信息传递的基本单位不再是整个收件箱，而是对话，这使得它更容易提供快速的搜索和检索时间，因为对话和信息可以被分解并分布在数据库中。对话与其中的消息分开存储，并有对消息的引用，以避免非常活跃的数据库记录的 "热键 "问题，从而降低系统的速度。
"现在，当会员在获取他们的收件箱时，他们并不是在修复一个消息列表，他们是在获取一个对话列表，如果他们访问其中一个对话，我们就可以访问其中的消息，"Lavery解释说。最初，只检索最近的对话，而且只检索这些对话中的前几条消息，因为那是用户最有可能寻找的内容。而这些最近的对话都存储在数据库的同一个部分，以提高速度。
"现在你把搜索问题从'如何在数十亿对话中找到数据'降低到了'我只需要找到与一个人的前十条对话，对于每条对话，我只需要找到前几条消息'。现在，你的数据检索问题非常小，无论他们的对话列表有多大，都是完全一样的数据大小检索问题。"
这个列表可能很大：一个LinkedIn新会员可能只有几百条信息。其他人则有75万或100万条信息。"如果你是一个在这个平台上工作了十几年的招聘人员，你每天可能要发几百封邮件，一周五六天。不管你的收件箱有多大，你的检索时间应该是一样的。"
当用户通过对话进行回读时，更多的信息会被检索出来。"Espresso就是为了做这种分页式的检索而建立的，因为它是NoSQL，因为只有我们要存储到的引用，没有连接，所以这种数据库检索变得非常快。"
新的设计确实占用了大量的存储空间，因为它有多个表和多个索引，使检索速度更快。但性能和可靠性方面的改进超过了这一点，Lavery认为。
"工程时间是昂贵的。即使新系统在存储方面确实有一些额外的成本，但与你为非常困难的问题提出技术解决方案所花费的维护和工程时间相比，这相对较低。"
存在的问题 Owning the Problem
同样的决策也决定了平台服务，刻意保持较少的数量，而不是选择完整的微服务架构，以此来获得长期有效的团队结构。
消息平台的服务不到十几个，有的很小，但有的相当大，规模上，每个服务都可以由一个高级技术领导拥有。"我们将领导权分散在一些工程师身上，这确实让我们在开发过程中能够非常迅速地加速，因为我们可以把那些对整个平台不是很熟悉的工程师请来，并将他们组织在这些技术领导的周围，并且非常迅速地执行。" Lavery可以给开发人员更多的责任，而不会让团队中的两位专家之一成为瓶颈。
当平台最初的部署计划没有成功时，这就帮了大忙。团队原本计划让旧的消息留在现有系统中，当他们将成员转移到新系统时，新的消息会在新系统中被创建。然后他们意识到，他们意外地创建了一个最终具有一致性的分布式系统，因为对于没有被迁移到新服务的成员来说，消息必须复制到旧系统中。
"我们开始看到非常糟糕的会员体验，等待这些消息出现，并确保一切都同步。" 这意味着将1%已经迁移到新系统上的会员回滚，并从整个公司引入额外的工程师来重新制定部署计划。
通常在项目中增加更多的员工会使项目更加缓慢，同时他们会加快进度，但由于每个服务都由一个技术负责人拥有，他们能够指导额外的工程师，回到正轨，并将推出速度加快到每两周一次。
"你还见过多少其他系统，花了三年多时间建立的斜坡没有问题，每两周一次？在两个月内，现在每周服务于数亿条创建的消息，服务于数亿会员，数据库中存储了数十亿条消息。"
服务所有权的方法对于构建新功能也很有效。产品团队仍然与基础架构团队合作，但所有的定制业务逻辑都被迁移出消息存储，并封装到其功能的插件中，当他们需要帮助时，不同的服务所有者可以与他们合作。"我想，如果我们采用比如说，二十几个服务，今天要确保我们有那些技术负责人可以提供帮助，就会困难得多。"Lavery建议。
新的架构意味着产品团队可以试验和测试新的想法，而无需承诺几个月的开发。"如果你的用例在我们已经构建的插件式架构中工作，并且你不需要额外的改变，你应该能够在一个月内构建并让你的插件生产就绪，"他说。"如果不成功，我们可以很容易地把它拉出来，如果成功了，我们可以加倍努力。"
这也加快了一些长期以来要求的功能的工作，比如能够编辑和删除消息，虽然技术上不是不可能，但在旧系统上构建这些功能是非常困难的。给两个人发送一条消息，过去需要创建三条记录，一条是发件人的，一条是收件人的，这就意味着一致性问题。
"如果我想编辑那条消息，我必须编辑三次，并确保这三次编辑都成功。" 现在，这条消息是一个记录，三个人都能得到一个参考。
"这个参考告诉我们那条消息在哪里，它还包括诸如你是否读过它，是否设置了删除。这使得编辑和删除大大简化，因为我只是在编辑一条记录。我只需要确保这个编辑是成功的，我们有系统来确保这个编辑是以最快的速度传到世界各地，这样我们所有的数据中心都会更新。"
另一个有需求的功能已经开始推出，让同组的人发送消息请求，与还没有LinkedIn关系的人开始对话。"这是我们在很长一段时间内收到的最大的抱怨之一：为什么我必须要有连接才能与另一个成员进行对话？"
消息团队提出的设计原则帮助他们逐步提供功能。LinkedIn消息是加密的，它们在消息数据库中创建之前，就会被审查是否是垃圾邮件。但LinkedIn并没有阻止垃圾邮件，而是向用户显示一条消息可能是垃圾邮件的通知，让用户忽略或阅读。现在，如果以后有一个成员确认某条消息是垃圾邮件，就可以在整个服务中异步删除它。
由于系统是可扩展的，LinkedIn信任团队能够以与垃圾邮件检查相同的方式添加反性骚扰检查，现在这一点正在扩展到其他形式的骚扰，以及通知用户有关账户接管和密码重置等问题--旧系统不够灵活，无法发现这些问题。
采取这种更有条理的方式来设计平台，意味着用户将更快地获得新功能，而且对从事该项目的工程师的职业发展也更好。
"火灾确实会吸走房间里很多的氧气，所以如果你的系统经常出现这类问题，人们往往会退而求其次，选择几个众所周知能够解决这类问题的工程师，但这些工程师不断地解决问题并不是一个好的职业选择，而且对于一个团队来说，不断地解决这些问题也是不健康的。"
"我见过的所有工程师都是解决问题的人，但他们也有自己想要打造的东西，或者想要实现的东西，如果你的状态是可以真正专注于那些类型的问题，那么团队的整体士气就会提升。"
以上由AI翻译完成，仅供参考。
作者：Mary Branscombe 由会员推荐
扫一扫 加微信
hrtechchina
