2022年社交网站的功能架构.docx

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