社交网站的功能架构.pdf

-架构设计.摘要：本篇文章会向读者展示几个架构设计的关键点，使一个社交应用能够成为真正的下一代社交产品。但这只是设计阶段，需要更深入的分析和了解系统的当前状态。本篇文章会向读者展示几个架构设计的关键点，使一个社交应用能够成为真正的下一代社交产品。以下几个属性将会影响到架构的设计：a可用性 b可扩展性 c性能和灵活性可扩展 目标 a确保用户的容数据能够很方便的被其他用户发现和获取.b确保容推送是相关的，不仅在语义上，也是从用户设备的角度。c确保实时更新生成、推送和分析。d尽可能地节省用户的资源。e不管效劳器负载变化如何，用户体验应保持不变。f确保应用整体上是平安的 总之，我们要处理一个相当大的挑战，我们必须处理不断扩大的海量用户生成的容数据，不断增长的用户，和一个不断迭代的新工程，同时必须确保性能足够出色。为了应对上述的挑战，我们必须学习架构*些关键的元素，这将影响到系统的设计。以下是一些关键的决定和分析。数据存储 数据和数据模型的存储是一个好架构的关键设计之一。一个社交产品应该能够处理多种类型的数据，因此首先得充分分析数据并透彻理解，之后再设计数据模型和数据存储。第一步，我们要确定哪些数据是经常查询的热点数据，哪些不是经常需要的那些数据如归档数据用于分析。对于高频访问的数据，它必须总是可用，能够快速读写和水平可扩展。目前我们所有业务场景使用的都是 MySQL，即使我们的用例不一定需要使用关系数据库系统。随着我们数据的增长，我们的读写将成为我们应用程序性能瓶颈。我们应该为每秒钟数十亿的查询做好准备。让我们对我们的数据进展分类：a主要的数据或静态形式的数据，如用户资料 b语义数据 c用户产生的容数据 d会话数据 找到一个高效的数据存储方式，满足所有这些类型的数据，真的很难。因此，我们将为每个数据类型选择特定的数据存储方式。静态数据：对于静态数据，最好是选择基于文档的存储方式，其中键和值都是可查询的。我们可以选择如 MongoDB 这种文档型数据库，选择 MongoDB 最大的优势是它提供了在文档级别的 ACID。MongoDB 可以在多个分布式数据中心的围进展缩放。它将允许我们使用副本集来保持冗余，从而解决我们的可用性问题。数据分片是一个重要的考虑因素，数据分片可以确保数据的扩展与查询速度。幸运的是，MongoDB 透明的支持了数据分片。关联的或关系数据核心数据：我们大局部数据本质上是关联的，例如，A 是 B 的朋友，C是 A 和 B 的朋友，这样高度语义的数据最适合图处理模型。我们应将这样的数据存储在图数-据库，如 Neo4j。这样做的优势很明显；我们可以存储所有关联数据的节点，从而节省了计算数据之间连接关系的额外步骤。图形数据模型也将有助于我们捕捉到属性之间的关系。当试图探索关联数据时，丰富的属性关系绝对是关键。图数据库支持 ACID 规则以及自动索引。再次声明，我们的要到达可用性和可扩展性。我们可能会有成百上千的并发事务，同时写入数据库，同时会有数百和数千查询请求。它应该能够处理一个数据集上的许多字节，超过十亿每秒的读取速度。我们将会需要一个系统，帮助我们自动伸缩写入和读取。其他需要考虑的因素是数据分片，这是系统可伸缩的关键。Neo4j 已经被设计为可水平扩展，并且有数据冗余功能来保证可用性。但到目前为止，它还不支持数据分片。我们可能需要更多的分析，才能做出抉择。其他可供选择的图数据库有FlockDB、AllegroGraph 和 InfiniteGraph。二进制数据UGC：我们还必须处理大量的与用户相关的二进制数据。处理二进制数据不太容易，考虑到它们的规模。上面已经讨论过，我们需要一个系统可以运行相当高的性能，秒级别尖峰，当决定在哪里存储时，可伸缩和可用性是最关键的素。我们不能依靠磁盘文件系统来存储我们的二进制数据。我们必须考虑可用性和可扩展性，文件系统的缓存会消耗大量的 CPU。相反的，我们应该依靠一个现有的可用的系统，例如亚马逊 S3，S3 是非常流行的对象存储系统，具有可用性和弹性存储。我们也可以考虑谷歌云存储或 Rackspace 的云文件等，但 S3 似乎是明显的赢家，它提供更优质的效劳。S3 已经支持数据分区。S3 能够水平伸缩，冷热数据拆分，并根据 keys 分区。但是只实现存储数据是不够的，与这些容相关的元数据必须能够被搜索，并且搜索可伸缩，速度够快。我们也可以尝试一些新的东西，如图像的自动维度识别，基于容自动打标签等。这是一个潜在的知识产权领域。我们将在文章的索引局部讨论索引需求。但现在，让我们只需要注意，我们将用标识符存储容，并且在*个地方做了索引。似乎亚马逊的 S3 最适合这种情况。Session 数据 正确的认识和理解 session 数据是非常重要的。Session 数据将帮助我们保持用户的状态。Session 数据必须使用与效劳器无关的方式，方便我们效劳端可伸缩部署。这将有助于保持我们的设计灵活，确保 session 不会绑定到特定的节点或效劳器。我们得用一种新的方式来更新用户的实际 session，如果用户的 session 终止，我们仍然可以帮助用户从一个地方，他离开的地方重新恢复信息。这是特别重要的，在我们的场景中，连接是不可靠的，数据丢包是很正常的。数据必须能够被跨节点访问，因此需要可用性和可扩展性。我们可以很好的使用 MongoDB 本身来保存数据。后来，我们想转移到纯粹的键值存储，如 Redis。注：所有推荐和离线作业都应该只运行在非效劳节点上。索引 索引是我们系统的关键。用户可以搜索任何容，这是我们的主要用例之一。为了提升搜索性能，我们必须非常认真地对待索引。这里有两点需要考虑：首先是，创立索引本身，然后就是索引系统本身。为了做一个有意义的搜索系统，我们必须设计一个实时索引，针对一段时间窗口的实时数据进展处理。首先，我们可以写一个非常简单的系统，对产生的容数据做倒排索引。后来，随着输入数据的增加，我们可以方便地用实时数据处理引擎取代它，如 Apache 的 Storm，这是一个分布式的，容错和高度可扩展的系统。它可以负责生成索引的逻辑。索引系统：由于 Lucene 受欢送程度和其性能，因此，Lucene 是一个显而易见的好选择；它的性能是无与伦比的。我们可以使用 SolrCloud。它已经透明的支持分片，复制和读写方面-的容错。队列&消息推送 每次我们的应用程序被触发一个事件，我们将需要向他/她的追随者/朋友推送消息。重要的是，我们的系统不能错过任何这些信息，更重要的是，能够在发生故障时恢复这些事件。为了到达这些要求，我们必须寻找一个队列解决方案。我们可以使用 ActiveMQ，这是最可靠的队列软件。它支持集群的高可用性，支持分布式队列。消息推送是另一个领域，要把通知发送给我们的用户。在这里我们需要估计一下规模。我们应该准备好支持像 nps 这样上亿的规模。这里有许多项选择择，但也许 pyapns、mandIQ 和APP Booster 才是最流行的。我们需要自己管理一些事情，特别是要保证消息传递可靠性，即使用户的设备处于离线状态。我建议我们实现一个双向的系统，保持状态的通知，并在后台持久化到磁盘。所以每次一个通知失败时，它的状态都被处理并标上状态码，添加到重试队列中。最后，当通知被送达，移出重试出列。缓存策略 像我们这样的系统，我们的目标是使其支撑十亿 RPS，因此，好的缓存策略是极重要的。我们的业务逻辑会在多层缓存中，并且能够智能的去除失效缓存。让我们看看最顶层缓存。应用层缓存容缓存：为了最大限度地减少缓存未命中，并确保缓存始终是最新的数据，我们必须寻找一个从未过期的缓存，并始终保持数据。这根本上意味着在一般使用情况下，我们将永远不用查询我们的数据库，因此节省了大量的资源。我们还应该确保我们缓存的数据总是以一种不需要额外处理的格式，随时准备好呈现。这根本上意味着将我们的在线负载转换为离线负载，从而节省了延迟。要做到这一点，我们必须确保每一次的容被输入到系统中，我们要做两件事情:a原容是非规格化形式保存在缓存。为了平安起见，我们将永远设置一个有效的期限。b原容也写在我们的数据存储区中。我们使用 Redis 来做这个缓存，Redis 是一种具有良好故障恢复的存缓存。它具有高度的可扩展性，较新的版本透明的支持了数据分片。支持主从节点配置。最好的局部是，我们能够保存任何格式的数据，这使得它很容易做增量写，这是至关重要的，我们支持容 feeds 还值得指出的是，我们需要支持对大容对象进展大量的读-修改-写操作和少量读，Redis是的，对这些操作在性能方面是最好的。缓存代理：反向代理层的缓存也是至关重要的。它有助于减少直接请求我们效劳器的负载，从而减少延迟。为了使代理效劳器缓存更有效，需要正确设置响应头。代理效劳器有很多种，但最受欢送的是 ngin*和 ATS。二级缓存代码级缓存：这是一个实体数据的本地存储，用于提高应用程序的性能。它有助于通过减少昂贵的数据库调用以提高性能，保持实体数据的本地化。EhCache 是一个很受欢送的选择。客户端缓存：这实际上是设备或浏览器缓存。所有静态工程都应该尽可能地缓存。如果 API响应缓存头已经被合理设置，很多相关资源的容都会被缓存。我们应确保其如预期的那样工作。除此之外，我们应该尽可能缓存其他容，可以使用设备自己的存，或使用 SQLite。所有昂贵的对象都应该缓存。例如 NSDateFormatter 和 NSCalendar，初始化缓慢，应该尽可能多的重用。iOS Lot 可以调整和应用，但是在这里，它是超出我们的研究围。数据压缩 考虑到我们的用户主要是要处理大量的图像和视频，需要下载大量的数据，所以优化下载大小是非常重要的。它将节省用户的数据量，提高应用程序的性能体验。其他要考虑的方面，如我们的网络，我们的用户主要是在非 LTE 网络，使用 2.5G 或 3G，需-要考虑带宽，并且连接通常是不可靠的，数据使用本钱高。在这种情况下，智能压缩是一个关键的需求。但是实际上图像压缩和视频压缩并不是想象中则直接简单，往往需要进展深入的分析。我们所处理的图像和视频，可以无损和有损，这取决于用户的设备质量。所以我建议使用多个压缩技术来处理这种情况。在这种情况下，我们可以尝试帧压缩和帧间压缩技术。但总的来说我们可以采用 zpaq 和 fp8 来应对所有压缩需求。我们也可以尝试非常适合我们业务场景的 WebP。一般情况下，我们的 API 会使用 gzip，我们 API response 总是经过 gzip压缩过的。数据转码 考虑到我们需要处理多个设备，多个操作系统和屏幕分辨率，我们的容存储和处理时应与设备无关。但效劳层应该基于用户的设备，理解并调整响应的容。所以，图像和视频的转码是必不可少的。我们的应用程序需要收集设备的配置，如存、编码和屏幕分辨率，作为 API 的上下文。我们的 API 应该使用此上下文来修改/选择容版本。基于我们承受到的设备上下文，我们可以预先准备好一些最频繁被请求的版本的容。我们可以使用 FFMPEG 转码，FFMPEG 是最可靠和应用最广的转码框架。我们可以修改 FFMPEG，使其满足我们的需求。转码是在数据输入端完成的。传输协议 考虑到我们的网络场景非 LTE，不可靠的连接等，关键是要尽可能地节省资源，使通信尽可能地轻量。我建议我们所有的请求都使用 ok 客户端，ok 使用 SPDY 协议，能够弹性处理连接失败，透明恢复。我们所有的通讯需求，都应该切换到 MQTT，这是一个轻量级的机器对机器的连接协议。平安问题 保证我们应用程序的平安是非常重要的。我们整体架构都要有平安上的考虑。我在这里只谈架构为满足平安要求做出的改变，我们不谈实施过程的改变。这里是一些必须添加到架构里的：1.我们所有的用户数据必须加密。MongoDB 和 Neo4j 已经支持存储加密。在这根底上，我们可以决定加密哪些用户关键信息。所有与数据库相关的传输调用必须启用加密。2.平安套接字层：所有代理效劳器的访问都应该使用 SSLed。代理效劳器可以充当 SSL 终止点。3.我们所有的 API 端点应该运行在非默认端口，并且必须实现 OAuth。4.所有的 DB 读取都应该通过 Rest endpoints。5.有关密码的配置必须特殊处理。密码必须 hashed，文件应该被限制只能在应用启动时读取。这允许我们通过文件系统权限来控制应用程序身份实例。只有应用程序用户可以读，但不能写，其他用户不可以读取。所有类似的配置都要用 keydb 打包并需要密码。组件 以下是我们架构用到的组件:1.负载均衡器：这层是用来转发所有对代理效劳器的请求，基于定制的策略。这一层也将有助于我们通过基于容量重定向的方式来保障可用性。2.代理效劳器：所有即将到来的调用都必须以这里为入口。这也是我们 SSL 的终止点。它缓存所有基于策略定义的请求。FE 层：该层运行一个 node 效劳器。3.数据输入引擎：这个组件涉及所有容的输入，它做了一系列的工作:非规化模型，转码，缓存等。将来如果可以的话，所有容的处理，都可以在这里完成。4.Rest 效劳：这层负责与所有 DB 交互，并返回数据。它的访问是受 OAuth 保护的。这可-以用 Tomcat 容器以及 edge 缓存来实现。5.事件处理：这层处理所有的事件，主要负责分发的功能。它读取 ActiveMQ 并使用通知引擎生成通知。6.推荐引擎：这个组件通过分析所有收集到的用户动态来做推荐。根据实际收集到的动态，我们可以部署各种基于亲和力的算法。我们可以使用 Apache Mahout 提供的各种算法接口 系统的逻辑视图：结语 本篇文章更像是对关键组件高抽象层次的分析。如果需要实施的建议，可以做一个阶段性的方式，但如果我们需要扩展性并支持真正的用例，必须遵循我提出的这些规。我没有提起任何设计领域相关的容。这只是设计阶段，需要更深入的分析和了解系统的当前状态。来自 HackerNews 的评论：s:/news.ybinator./itemid=9930752 原文：Architecting Backend For A Social Product译者/施聪羽审校/朱正贵责编/仲浩 关于译者：施聪羽，浩渺科技效劳端研发工程师，修炼中的码农。