社交网站的功能架构 .docx

《社交网站的功能架构 .docx》由会员分享，可在线阅读，更多相关《社交网站的功能架构 .docx（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精品名师归纳总结架构设计.摘要：本篇文章会向读者展现几个架构设计的关键点，使一个社交应用能够成为真正的下一代社交产品。但这只是设计阶段，需要更深化的分析和明白系统的当前状态。本篇文章会向读者展现几个架构设计的关键点，使一个社交应用能够成为真正的下一代社交产品。以下几个属性将会影响到架构的设计：a可用性 b可扩展性c性能和敏捷性可扩展目标a确保用户的内容数据能够很便利的被其他用户发觉和猎取. b确保内容推送是相关的，不仅在语义上，也是从用户设备的角度。c确保实时更新生成、推送和分析。d尽可能的节约用户的资源。e不管服务器负载变化如何，用户体验应保持不变。f确保应用整体上是安全的总之，我们要处理一

2、个相当大的挑战，我们必需处理不断扩大的海量用户生成的内容数据，不断增长的用户， 和一个不断迭代的新项目，同时必需确保性能足够杰出。为了应对上述的挑战， 我们必需学习架构某些关键的元素，这将影响到系统的设计。 以下是一些关键的打算和分析。数据储备数据和数据模型的储备是一个好架构的关键设计之一。一个社交产品应当能够处理多种类型的数据，因此第一得充分分析数据并透彻懂得，之后再设计数据模型和数据储备。第一步， 我们要确定哪些数据是常常查询的热点数据，哪些不是常常需要的那些数据如归档数据用于分析 。对于高频拜访的数据，它必需总是可用，能够快速读写和水平可扩展。目前我们全部业务场景使用的都是MySQL，即

3、使我们的用例不肯定需要使用关系数据库系 统。随着我们数据的增长， 我们的读写将成为我们应用程序性能瓶颈。我们应当为每秒钟数可编辑资料 - - - 欢迎下载精品名师归纳总结十亿的查询做好预备。让我们对我们的数据进行分类：a主要的数据或静态形式的数据，如用户资料b语义数据c用户产生的内容数据d会话数据找到一个高效的数据储备方式，满意全部这些类型的数据，真的很难。因此， 我们将为每个数据类型挑选特定的数据储备方式。静态数据： 对于静态数据，最好是挑选基于文档的储备方式， 其中键和值都是可查询的。我们可以挑选如 MongoDB 这种文档型数据库，挑选 MongoDB 最大的优势是它供应了在文档级别的

4、ACID。MongoDB 可以在多个分布式数据中心的范畴内进行缩放。它将答应我们使用副本集来保持冗余，从而解决我们的可用性问题。数据分片是一个重要的考虑因素，数据分片可以确保数据的扩展与查询速度。幸运的是，MongoDB 透亮的支持了数据分片。关联的或关系数据核心数据 ：我们大部分数据本质上是关联的，例如，A 是 B 的伴侣， C是 A 和 B 的伴侣，这样高度语义的数据最适合图处理模型。我们应将这样的数据储备在图数据库，如 Neo4j 。这样做的优势很明显。我们可以储备全部关联数据的节点，从而节约了运算数据之间连接关系的额外步骤。图形数据模型也将有助于我们捕获到属性之间的关系。当试图探究关联

5、数据时，丰富的属性关系肯定是关键。图数据库支持ACID 规章以及自动索引。再次声明， 我们的要求是到达可用性和可扩展性。 我们可能会有成百上千的并发事务， 同时写入数据库， 同时会有数百和数千查询恳求。 它应当能够处理一个数据集上的很多字节， 超过十亿每秒的读取速度。我们将会需要一个系统，帮忙我们自动伸缩写入和读取。其他需要考虑的因素是数据分片， 这是系统可伸缩的关键。Neo4j 已经被设计为可水平扩展，并且有数据冗余功能来保证可用性。但到目前为止，它仍不支持数据分片。我们可能需要更多的分析，才能做出选择。其他可供挑选的图数据库有FlockDB、AllegroGraph 和 InfiniteG

6、raph 。二进制数据 UGC：我们仍必需处理大量的与用户相关的二进制数据。处理二进制数据不可编辑资料 - - - 欢迎下载精品名师归纳总结太简洁，考虑到它们的规模。上面已经争论过，我们需要一个系统可以运行相当高的性能， 秒级别尖峰 ，当打算在哪里储备时，可伸缩和可用性是最关键的素。我们不能依靠磁盘文件系统来储备我们的二进制数据。我们必需考虑可用性和可扩展性，文件系统的缓存会消耗大量的 CPU。相反的，我们应当依靠一个现有的可用的系统，例如亚马逊S3， S3 是特别流行的对象储备系统，具有可用性和弹性储备。我们也可以考虑谷歌云储备或Rackspace 的云文件等，但 S3 好像是明显的赢家，它

7、供应更优质的服务。S3 已经支持数据分区。 S3 能够水平伸缩，冷热数据拆分，并依据keys 分区。但是只实现储备数据是不够的，与这些内容相关的元数据必需能够被搜寻，并且搜寻可伸缩，速度够快。我们也可以尝试一些新的东西，如图像的自动维度识别，基于内容自动打标签等。 这是一个潜在的学问产权领域。 我们将在文章的索引部分争论索引需求。但现在，让我们只需要留意， 我们将用标识符储备内容，并且在某个的方做了索引。好像亚马逊的S3 最适合这种情形。Session数据正确的熟悉和懂得session 数据是特别重要的。 Session 数据将帮忙我们保持用户的状态。Session 数据必需使用与服务器无关的

8、方式，便利我们服务端可伸缩部署。这将有助于保持我们的设计敏捷，确保session 不会绑定到特定的节点或服务器。我们得用一种新的方式来更新用户的实际session，假如用户的 session 终止，我们仍旧可以帮忙用户从一个的方，他离开的的方重新复原信息。这是特殊重要的，在我们的场景中，连接是不行靠的，数据丢包是很正常的。数据必需能够被跨节点拜访，因此需要可用性和可扩展性。我们可以很好的使用MongoDB 本身来储存数据。后来，我们想转移到纯粹的键值储备，如Redis。注：全部举荐和离线作业都应当只运行在非服务节点上。索引索引是我们系统的关键。用户可以搜寻任何内容， 这是我们的主要用例之一。为

9、了提升搜干脆能，我们必需特别仔细的对待索引。这里有两点需要考虑：第一是，创建索引本身，然后就是索引系统本身。为了做一个有意义的搜寻系统，我们必需设计一个实时索引，针对一段时间窗口的实时数据进行处理。第一，我们可以写一个特别简洁的系统，对产生的内容数据做倒排索引。后来，随着输入数据的增加，我们可以便利的用实时数据处理引擎取代它，如Apache 的 Storm ， 这是一个分布式的，容错和高度可扩展的系统。它可以负责生成索引的规律。索引系统：由于 Lucene 受欢送程度和其性能，因此，Lucene 是一个显而易见的好挑选。它的性能是无与伦比的。我们可以使用SolrCloud。它已经透亮的支持分片

10、，复制和读写方面的容错。可编辑资料 - - - 欢迎下载精品名师归纳总结队列 &消息推送每次我们的应用程序被触发一个大事，我们将需要向他/ 她的追随者 / 伴侣推送消息。重要的是，我们的系统不能错过任何这些信息，更重要的是，能够在发生故障时复原这些大事。为 了到达这些要求，我们必需查找一个队列解决方案。我们可以使用ActiveMQ ，这是最牢靠的队列软件。它支持集群的高可用性，支持分布式队列。消息推送是另一个领域， 要把通知发送给我们的用户。 在这里我们需要估量一下规模。 我们应当预备好支持像 nps 这样上亿的规模。 这里有很多项挑选择， 但或许 pyapns、CommandIQ 和 APP

11、 Booster 才是最流行的。我们需要自己治理一些事情， 特殊是要保证消息传递牢靠性， 即使用户的设备处于离线状态。我建议我们实现一个双向的系统，保持状态的通知， 并在后台长久化到磁盘。所以每次一个通知失败时，它的状态都被处理并标上状态码，添加到重试队列中。最终，当通知被送达，移出重试出列。缓存策略像我们这样的系统，我们的目标是使其支撑十亿RPS，因此，好的缓存策略是极重要的。我们的业务规律会在多层缓存中，并且能够智能的清除失效缓存。让我们看看最顶层缓存。应用层缓存 内容缓存 ：为了最大限度的削减缓存未命中， 并确保缓存始终是最新的数据， 我们必需查找一个从未过期的缓存，并始终保持数据。这基

12、本上意味着在一般使用情形下，我们将永久不用查询我们的数据库， 因此节约了大量的资源。 我们仍应当确保我们缓存的数据总是以一种不需要额外处理的格式， 随时预备好出现。 这基本上意味着将我们的在线负载转换为离线负载， 从而节约了推迟。 要做到这一点， 我们必需确保每一次的内容被输入到系统中，我们要做两件事情 :a原内容是非规格化形式储存在缓存。为了安全起见，我们将永久设置一个有效的期限。b原内容也写在我们的数据储备区中。我们使用 Redis 来做这个缓存， Redis 是一种具有良好故障复原的内存缓存。它具有高度的可扩展性， 较新的版本透亮的支持了数据分片。支持主从节点配置。最好的部分是，我们能够

13、储存任何格式的数据，这使得它很简洁做增量写，这是至关重要的，我们支持内容feeds仍值得指出的是，我们需要支持对大内容对象进行大量的读- 修改 - 写操作和少量读，Redis 是已知的，对这些操作在性能方面是最好的。缓存代理：反向代理层的缓存也是至关重要的。它有助于削减直接恳求我们服务器的负载，从而削减推迟。 为了使代理服务器缓存更有效，需要正确设置响应头。 代理服务器有很多种，但最受欢送的是nginx 和 ATS。可编辑资料 - - - 欢迎下载精品名师归纳总结二级缓存代码级缓存 ：这是一个实体数据的本的储备，用于提高应用程序的性能。它有助于通过削减昂贵的数据库调用以提高性能，保持实体数据的

14、本的化。EhCache是一个很受欢送的挑选。客户端缓存：这实际上是设备或浏览器缓存。全部静态项目都应当尽可能的缓存。假如API 响应缓存头已经被合理设置， 很多相关资源的内容都会被缓存。我们应确保其如预期的 那样工作。除此之外，我们应当尽可能缓存其他内容，可以使用设备自己的内存，或使用SQLite。全部昂贵的对象都应当缓存。例如NSDateFormatter 和 NSCalendar，初始化缓慢， 应当尽可能多的重用。iOS Lot 可以调整和应用，但是在这里，它是超出我们的争论范畴。数据压缩考虑到我们的用户主要是要处理大量的图像和视频，需要下载大量的数据， 所以优化下载大小是特别重要的。它将

15、节约用户的数据量，提高应用程序的性能体验。其他要考虑的方面，如我们的网络，我们的用户主要是在非LTE 网络，使用或 3G，需要考虑带宽，并且连接通常是不行靠的，数据使用成本高。在这种情形下，智能压缩是一个关键的需求。但是实际上图像压缩和视频压缩并不是想象中那么直接简洁，往往需要进行深化的分析。我们所处理的图像和视频，可以无损和有损， 这取决于用户的设备质量。所以我建议使用多个 压缩技术来处理这种情形。在这种情形下，我们可以尝试帧内压缩和帧间压缩技术。但总的来说我们可以采纳zpaq 和 fp8 来应对全部压缩需求。我们也可以尝试特别适合我们业务场景的 WebP。一般情形下，我们的API 会使用

16、gzip，我们 API response 总是经过 gzip压缩过的。数据转码考虑到我们需要处理多个设备，多个操作系统和屏幕辨论率，我们的内容储备和处理时应与设备无关。 但服务层应当基于用户的设备，懂得并调整响应的内容。所以，图像和视频的转码是必不行少的。我们的应用程序需要收集设备的配置，如内存、编码和屏幕辨论率，作为API 的上下文。我们的 API 应当使用此上下文来修改/ 挑选内容版本。基于我们接受到的设备上下文，我们可以预先预备好一些最频繁被恳求的版本的内容。我们可以使用FFMPEG 转码， FFMPEG 是最牢靠和应用最广的转码框架。我们可以修改FFMPEG，使其满意我们的需求。转码是

17、在数据输入端完成的。传输协议考虑到我们的网络场景非LTE，不行靠的连接等 ，关键是要尽可能的节约资源，使通信尽可能的轻量。我建议我们全部的恳求都使用ok客户端， ok使用 SPDY协议，可编辑资料 - - - 欢迎下载精品名师归纳总结能够弹性处理连接失败，透亮复原。我们全部的通讯需求，都应当切换到MQTT，这是一个轻量级的机器对机器的连接协议。安全问题保证我们应用程序的安全是特别重要的。我们整体架构都要有安全上的考虑。我在这里只谈架构为满意安全要求做出的转变，我们不谈实施过程的转变。这里是一些必需添加到架构里的：1. 我们全部的用户数据必需加密。MongoDB 和 Neo4j 已经支持储备加密

18、。在这基础上，我们可以打算加密哪些用户关键信息。全部与数据库相关的传输调用必需启用加密。2. 安全套接字层：全部代理服务器的拜访都应当使用SSLed。代理服务器可以充当SSL终止点。3. 我们全部的 API 端点应当运行在非默认端口，并且必需实现OAuth。4. 全部的 DB 读取都应当通过 Rest endpoints 。5. 有关密码的配置必需特殊处理。密码必需hashed，文件应当被限制只能在应用启动时读取。这答应我们通过文件系统权限来掌握应用程序身份实例。只有应用程序用户可以读，但不能写，其他用户不行以读取。全部类似的配置都要用keydb 打包并需要密码。组件以下是我们架构用到的组件:

19、1. 负载均衡器：这层是用来转发全部对代理服务器的恳求，基于定制的策略。这一层也将有助于我们通过基于容量重定向的方式来保证可用性。2. 代理服务器：全部即将到来的调用都必需以这里为入口。这也是我们SSL的终止点。它缓存全部基于策略定义的恳求。 FE层：该层运行一个node 服务器。3. 数据输入引擎：这个组件涉及全部内容的输入，它做了一系列的工作: 非标准化模型，转码，缓存等。将来假如可以的话，全部内容的处理，都可以在这里完成。4. Rest 服务：这层负责与全部DB 交互，并返回数据。它的拜访是受OAuth 爱护的。这可以用 Tomcat 容器以及 edge 缓存来实现。5. 大事处理：这层

20、处理全部的大事，主要负责分发的功能。它读取ActiveMQ 并使用通知引擎生成通知。可编辑资料 - - - 欢迎下载精品名师归纳总结6. 举荐引擎： 这个组件通过分析全部收集到的用户动态来做举荐。依据实际收集到的动态， 我们可以部署各种基于亲和力的算法。我们可以使用Apache Mahout 供应的各种算法接口系统的规律视图：可编辑资料 - - - 欢迎下载精品名师归纳总结结语本篇文章更像是对关键组件高抽象层次的分析。假如需要实施的建议，可以做一个阶段性的方式， 但假如我们需要扩展性并支持真正的用例，必需遵循我提出的这些标准。我没有提起任何设计领域相关的内容。这只是设计阶段，需要更深化的分析和明白系统的当前状态。来自 HackerNews 的评论：/item.id=9930752原文链接：Architecting Backend For A Social Product 译者 / 施聪羽 审校 / 朱正贵 责编 / 仲浩 关于译者： 施聪羽，浩渺科技服务端研发工程师，修炼中的码农。可编辑资料 - - - 欢迎下载