LinkedIn 的扩展之旅
内容提要
Datadog分析了超过24亿个容器的遥测数据，以了解当前的容器景观。LinkedIn从一个名为Leo的单体架构开始。随着平台的发展，LinkedIn构建了一个分布式和分区的图形系统Cloud来管理会员之间的连接。他们还使用Lucene构建了一个搜索服务。为了扩展Leo，他们启动了多个实例并实施了数据库复制。然后，LinkedIn过渡到了面向服务的架构，将单体应用程序拆分为独立的服务。他们还引入了缓存、使用Kafka进行数据收集，并实施了Rest.li和Pinot等工具以实现可扩展性。LinkedIn通过ACLs管理了大规模的授权，并构建了一个授权客户端模块。
延伸解读
从单体到微服务：架构演进的驱动力
LinkedIn 的架构演进并非一蹴而就，而是由业务需求直接驱动。最初，单体应用 Leo 处理所有功能，但随着会员连接和搜索需求的增长，其局限性凸显。为此，LinkedIn 构建了独立的图服务 Cloud 和基于 Lucene 的搜索服务，这标志着从单体向面向服务架构（SOA）的转变。到 2015 年，LinkedIn 已拥有超过 750 个服务，这种架构提升了可扩展性和开发效率，但也带来了服务间通信和管理的复杂性。
数据基础设施：Kafka 与 Pinot 的关键角色
随着数据量激增，LinkedIn 开发了 Kafka 作为分布式消息平台，统一了数据管道，支持实时数据流和异步处理。Kafka 目前每天处理 7 万亿条消息，成为架构的核心。同时，为满足实时分析需求，LinkedIn 构建了 Pinot 引擎，支持低延迟、高并发的 OLAP 查询，用于“谁查看了你的个人资料”等产品。这些自研基础设施解决了大规模数据采集和分析的挑战，体现了 LinkedIn 在数据领域的创新。
规模化授权：ACL 管理系统的设计
在微服务架构下，LinkedIn 面临服务间授权管理的挑战。他们采用基于 ACL 的授权模型，每个服务内置授权客户端模块，在内存中维护 ACL 数据以实现快速检查。ACL 数据存储在 Espresso 数据库中，并通过 Couchbase 缓存和基于 Brooklin 的变更数据捕获系统保持更新。所有授权检查通过 Kafka 异步记录，用于监控和调试。这套系统支撑了超过 700 个服务间每秒数千万次的调用，确保了数据安全。
组织扩展：Inversion 倡议与开发者生产力
LinkedIn 认识到技术扩展离不开组织扩展。通过内部倡议 Inversion，他们暂停功能开发，集中提升开发者工具和基础设施。这期间诞生了 Rest.li 框架，统一了多语言服务的 API 通信，并引入了动态发现（D2）简化服务调用。Super Blocks 概念则通过聚合后端服务优化了调用图。这些举措提高了工程效率，为后续可扩展产品的快速开发奠定了基础。
Q&A
LinkedIn是如何从单体架构转向分布式架构的？
LinkedIn最初使用单体架构Leo，随着需求增长，逐步拆分为多个独立服务，采用面向服务的架构（SOA）。
LinkedIn在扩展过程中遇到了哪些主要挑战？
主要挑战包括管理会员之间的连接和提供搜索功能，这促使LinkedIn构建了分布式图形系统和搜索服务。
LinkedIn是如何实现高可用性的？
LinkedIn通过在多个数据中心提供服务，实施数据复制和负载均衡，确保高可用性并避免单点故障。
LinkedIn使用了哪些工具来支持数据收集和分析？
LinkedIn开发了Kafka作为分布式消息平台，并使用Pinot进行实时数据分析，以支持大规模数据处理需求。
LinkedIn是如何管理大规模授权的？
LinkedIn通过构建高效的ACL管理系统，确保每个微服务只能访问必要的数据，并快速处理授权检查和更新。
LinkedIn在扩展开发者生产力方面采取了哪些措施？
LinkedIn通过内部倡议Inversion，专注于提升开发者工具和基础设施，以提高开发效率和支持可扩展产品的开发。
